Jakub Hampl

Just wondering if a more transformation oriented API would make sense? Since the reason for using these is to compose transformations (otherwise you might as well use the functions in...

Perhaps, but they compose quite nicely. ```elm myTransformation : Transformation2d units coordinates -> Transformation2d units coordinates myTransformation = Transformation2d.scale 2 >> Transformation2d.translateBy (Vector2d.fromComponents 200 -400) >> Transformation2d.rotate (Angle.degrees 40) >>...

It seems the code is rather slow. I've implemented a few improvements (namely fixing an off-by-one error that caused some unnecessary retries and a faster array delete function which is...

Makes sense, will do in a couple of weeks. Regarding the tolerances: It's possible neither may be necessary. The area check is just checking if all three points lie on...

That might indeed warrant a weighted voronoi 😈

Regarding representation: elm-explorations/linear-algebra doesn't really have a Mat3 type. I agree that for Transformation3d using that record based representation makes sense, but using 16 Floats for 2d transforms seems wasteful...

OK, I've changed the types to be as you suggested. I think it's a good improvement, as the function types intuitively communicate the idea of transformation better than the input/output...

For example running on a file where parsing seems to fail (not sure why in my case) or an empty file, I get this output: ``` module Doc.Visualization.ScaleSpec exposing (spec)...

That is slightly better, although I think it would make sense for elm-verify-examples to report an error if a file doesn't have any examples, rather than leaving this to elm-test...

This seems to not generate any examples: ```elm module Visualization.Scale exposing (nice) {-| Returns a new scale which extends the domain so that it lands on round values. The second...