[diagrams] diagrams status

Brent Yorgey byorgey at seas.upenn.edu
Fri Aug 20 10:14:59 EDT 2010


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



More information about the diagrams mailing list