[diagrams] diagrams status

[Brent Yorgey]

I've added some material to the wiki page:

  http://trac.haskell.org/diagrams/wiki/BoundingRegionTransformation

In particular I think I've finally understood what Ryan was doing many
months ago [1] and made some progress on understanding it a bit
better.  In short, modulo working out some details, I think I have a
solution that will work as long as we restrict ourselves to affine
transformations, which have the nice property that they preserve
parallel lines (although they may not preserve angles).  Please take a
look and edit it to make things clearer or add questions or examples
or whatever.

-Brent

[1] http://projects.haskell.org/pipermail/diagrams/2010-June/000005.html

On Fri, Aug 20, 2010 at 03:14:59PM +0100, Brent Yorgey wrote:
> My responses to Scott and Ryan below.
> 
> On Mon, Aug 16, 2010 at 10:54 AM, Scott N. Walck <walck at lvc.edu>
> wrote:
> 
> > I could live without shears and projective transformations, but
> > non-uniform
> > scaling seems a very basic and natural thing to want to do.
> > "I want this diagram to be the same height but twice as wide."
> > This is just the kind of thinking that makes the combinator-based
> > drawing approach so powerful.  I would give up three and higher
> > dimensions
> > before I'd give up horizontal scaling.
> 
> Hmm, I guess you're right.  And I'd rather not have to give up higher
> dimensions: so let's see if we can push a bit harder on the problem.
> 
> 
> On Mon, 16 Aug 2010 at 11:02 AM, Ryan Yates <fryguybob at gmail.com>
> wrote:
> 
> > I'll all for option 1, but there might be a compromise with 1 and 3
> > that allow us to add some more information to transformations that
> > aid in getting 1 (i.e. something easy to calculate when you have the
> > parameters to the transformation, but hard when the transformation
> > is opaque).
> >
> > Ryan
> 
> Hmm, interesting idea.  Sort of like what we currently do to keep
> track of inverse transformations.
> 
> Here's a somewhat related idea I just had.  Currently we represent
> bounding regions by a function which given a vector, tells you how far
> you have to go in that direction to reach an enclosing hyperplane
> (call this function h, for Hyperplane).  Consider instead a function e
> (for Envelope) which given a vector, tells you how far you have to go
> in that direction to reach the edge of the bounding region itself.
> 
> e should be much easier to transform under any sort of transformation
> at all.  But h is rather nice for other reasons (placing diagrams next
> to one another using e seems very difficult; using h it is a snap).
> However, given e (or e plus some extra information which is also easy
> to maintain under transformations) can we easily recover h?  Perhaps
> using some sort of automatic differentiation?  Essentially to compute
> h from e we are doing some sort of maximization I think.
> 
> Anyway, I've also created a wiki page where we can organize some of
> these thoughts: 
> 
>   http://trac.haskell.org/diagrams/wiki/BoundingRegionTransformation
> 
> There's nothing there yet.  Feel free to add things, or I will add
> some things as I have the time.
> 
> -Brent
> 
> _______________________________________________
> diagrams mailing list
> diagrams at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/diagrams