New stuff

[cchalmers]

Not ready to merge.

New Measure changes

• lineWidth and dashing attributes are no longer tied to V2 so they're moved to 'Diagrams.Attributes'
• Text is now wrapped in ScaleInv and gets scaled from FontSize by backends.

Generalised SizeSpec

• Moved to Diagrams.Size
• SizeSpec v n is now a wrapper over v n
• extracting a SizeSpec returns v (Maybe n) with only strictly positive values
• Diagrams.TwoD.Size has some specialised functions.

Intersections (unfinished)

• cubic - cubic using Bézier intersection, cubic - linear using Bernstein polynomials (adapted from @kuribas's cubicbezier package) and linear-linear using linear interpolation.
• would also like boolean path operations (kuribas mentioned it on irc)

Projections (unfinished)

• Only works on things like Path (projecting a Diagram would need special a backend)
• LinearMap v u n used for orthogonal projections
• Deformable v u n used for perspective projections

[kuribas]

Why not use cubicbezier directly? It would be easier for improvements and bugfixes.

[cchalmers]

I thought about it. I wasn't sure about using cubicbezier because of the overlap in functions and types and limiting everything to Double. But it could work. When I started I didn't realise how complicated the algorithm was :)

[kuribas]

I have used Double since I didn't think a typeclass would be necessary. But if using a typeclass makes it easier for diagrams, I can change it.

[kuribas]

However I wonder if for performance doing the conversion inside diagrams is better. Double precision should be good enough for any graphics need. Typeclasses will make the code slower.

[bergey]

We do periodically run into precision issues with Double. For example:
#142
diagrams/diagrams-cairo#38
diagrams/diagrams-cairo#39
and maybe: diagrams/diagrams-cairo#28

And some others on IRC.

I'm not sure how conversion to and from Double would work for automatic differentiation or intervals. Surprisingly, I expect. I'm thrilled to have path intersection of any sort, but if it can be polymorphic, that's better.

[kuribas]

Well, many numerical issue aren't solved by throwing in more precision, but by chosing different formulas, avoiding castrophic cancelation. How would using a type class instead of Double improve numerical stability in my library?

[cartazio]

would the generality allow for using eg http://hackage.haskell.org/package/compensated-0.6.1 ?

[cchalmers]

Not compensated but something like rounded should work but I think Double should be enough precision for most cases. (edit: actually, compensated should work.)

@kuribas I'm curious about boolean operations. Have you got any code yet? I'd like to see if diagrams could use it.

[kuribas]

@cchalmers the code for boolean operations and overlap removal isn't finished yet. But if you are interested I"ll work on it now. I don't see why diagrams couldn't use it...
Double should be good enough for CAD. With a high resolution 2880 dpi printer, and a huge A1 papersize, you only need 95357 points = 17 bits. Double has 52 bits precision, that's plenty for intermediate calculations. Any numerical issues that still occur should be solved algorithmically, not by trowing in more precision.

[cchalmers]

It's not just for higher precision numbers. Having native code makes it easier to integrate with other parts of diagrams. I also think it's kinda nice that all the geometry algorithms diagrams uses are in diagrams. I'm happy to port your code to diagrams so you can keep your module fast and I get learn how it works. We can still work together with bugs / improvements.

I would be very grateful if you could finish your code on boolean operations. :)

[jeffreyrosenbluth]

Cant we now get rid of GTAttributes, and the syb (actually the lens version) stuff, and Data constraints?

[cchalmers]

Yes. I don't see any need for it any more.

[jeffreyrosenbluth]

That's great, do you want to remove it and any constraints / packages dependencies.

[cchalmers]

Doing it now :)

[cchalmers]

Looks like I was a bit ambitious to try to do everything in one PR. It ended up being a lot more than I first thought. I'll split up intersections and projections in another request so just ignore them for now. The rest of it is almost ready to merge.

I'm pretty happy with how 'Measure' turned out. It's simpler on the backends and there's no more 'Data' constraints. I think I'll also be turn a 'Measured (Diagram B)' into a delayed leaf which I'll work on next.

The changes to 'SizeSpec' are almost done. Please have a look at it, I'm open to any suggestions on it. There's also lots of changes with cleaning up type signatures with 'InSpace'.

[jeffreyrosenbluth]

I'm happy with the way Measure turned out as well, in fact I think the whole PR
is a nice improvement.

[cchalmers]

There's probably a few bugs still loitering around but I'd like to merge this if there's no objections?

[jeffreyrosenbluth]

Agreed, I assume you want to merge all of the new-stuff branches?
Except for cairo?

[cchalmers]

Yes. We can still merge Cairo, I just haven't tested if the text is scaled properly.

[kuribas]

I am currently reading "Numerical methods" by Richard Hamming. I think part one is an excellent introduction to floating point and rounding issues. Also it's a dover publication, so it's cheap :-)