[diagrams] Great news!

[Ryan Yates]

Excellent!

On Wed, Nov 10, 2010 at 6:01 PM, Brent Yorgey <byorgey at seas.upenn.edu>wrote:

> I finally sat down to implement this, and after a few false starts and
> a few interesting bugs, I think I finally have it working!!  All the
> bounds tests in cairo/test/ now work.  Sometime soon I'll write up a
> more detailed explanation of how things work, but the executive
> summary is that we can now apply any affine transformation (which
> includes shears and non-uniform scales) to bounding regions.  I don't
> have a formal proof that it works, but I have a good intuition for why
> it works the way it does, and it seems to work empirically.  It relies
> crucially on the fact that although affine transformations don't
> preserve angles, they DO send preserve parallel lines (parallelity?
> parallelness?). We can't do general projective transformations, but
> I'm OK with that.
>
> Anyway, I have a couple of students who will be helping out with
> diagrams for their final project in my Haskell class, so expect more
> progress soon!
>
> -Brent
>
> On Sat, Sep 04, 2010 at 01:47:43PM -0400, Brent Yorgey wrote:
> > 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
> >
> > _______________________________________________
> > diagrams mailing list
> > diagrams at projects.haskell.org
> > http://projects.haskell.org/cgi-bin/mailman/listinfo/diagrams
>
> _______________________________________________
> diagrams mailing list
> diagrams at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/diagrams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.haskell.org/pipermail/diagrams/attachments/20101111/002d21cb/attachment.html