Added a natural inhabitant to Diagrams.TwoD.Transform

[sattlerc]

I added a smart constructor for linear conformal maps, basically rotateTo (dir v) followed by scale (norm v) in one go, but without the rounding errors introduced by the use of avoidable trigonometric functions.

I tried to follow the conventions of the library, but am happy for any feedback.

[byorgey]

Thanks! This is great. We should also (1) re-export the new functions from Diagrams.TwoD, and (2) mention them in appropriate place(s) in the user manual. Are those things you would be interested in tackling? (Feel free to say no!) I have given you push access to this repository as well as diagrams-doc.

[sattlerc]

I re-exported the functions, but before I update the manual, I have another question.

It would be nice to have a function also for affine conformal maps that incorporates translation. For example, given points a, b, a', b', there is a unique angle-preserving affine map that sends a to a' and b to b' (i.e. we can specify the image of a segment). But I noticed you tend to avoid talking about points in Diagrams.TwoD, so I am not sure whether such a thing is appropriate.

[byorgey]

Affine conformal maps with translation sounds great. I'm curious how you got the impression that we avoid talking about points in Diagrams.TwoD? But in any case there is no such restriction. We talk about points whenever it makes sense to talk about points.

[sattlerc]

I'm afraid to add too much. Let me outline possible variants and you tell me were you want to draw the line.

In the style of rotateTo and scaleRotate to, one could have further variants such as:

• mapConformallyTo/scaleRotateMoveTo for constructing an angle-preserving affine map by specifying the image of the x-axis unit segment (0,0)--(1,0),
• mapAffinelyTo for constructing an affine map by specifying the image of (0,0), (1,0), (0,1),
• mapProjectivelyTo for constructing a projective map by specifying the image of (0,0), (1,0), (0,1), (1,1).

But the first one is just a composites of two more elementary transformations and the second is just specifying the columns of the corresponding 2x3-matrix.

Then one could imagine variants that do not start with the unit x-axis, but with an arbitrary source (of the same form as the target). For example:

• moveBetween taking two points,
• rotateBetween taking two directions,
• scaleRotateBetween taking two vectors,
• mapConformallyBetween taking two points (a segment) for source and target each
• mapAffinelyBetween taking three points (a triangle) for source and target each
• mapProjectivelyBetween taking four points (a quadrangle) for source and target each

But these are each just composites of a 'To' variant and its inverse.

I'm also not sure how concerned you are about performance. Building a transformation out of many elementary building blocks has the potential to be quite inefficient (since the sequence of transformation functions is not "normalized" to just application of a single matrix). I see some thoughts in the dev wiki about that, so I don't want to infringe.

[byorgey]

Hi @sattlerc, I think all of this sounds great. Since there are a lot of things, maybe it should all go in a new module which is re-exported from Diagrams.TwoD.Transform? I'm not sure what it should be called. But I think it would be fine to stick it all in Diagrams.TwoD.Transform too.

You're right that most of these functions are just simple compositions of other functions; but it's unreasonable to expect users of diagrams to know that. When making DSLs I definitely lean in the direction of adding more stuff for convenience of the user. Once they have found the function that does what they want (e.g. mapAffinelyBetween) they can, if they want, look at the implementation to understand the simpler building blocks it is built out of. But if you don't spend all day thinking about affine transformations and matrices and whatnot, it might be hard to discover how to compose the simple building blocks to make what you want.

We are not super concerned with performance. Maybe we may get more serious about it in the future. But the philosophy of diagrams has always been to prefer power/functionality over performance.