normalization?

[pca006132]

It seems that some applications perform normalization which limits the range of floating point numbers to [-1, 1]. I think this can helps avoid precision loss due to magnitude. Do you think it is useful in our case after switching to double?
We can probably store the transform required in the Manifold::Impl node, transform it back when giving the mesh to the user, without any breaking changes.

[elalish]

I may be missing something, but how would that help? We could take the Clipper approach and do everything in integer coordinates, scaling the input to the right range, but floating-point basically does just that, except it's automatic. The only real tradeoff is you only get 24 bits of precision instead of 32. I don't see how normalized floats would help, unless you're talking about our Clipper conversions, which could certainly use some work.

Precision loss only happens when combining objects of different magnitudes, which I think is unavoidable regardless of how you scale.

[pca006132]

It can help when you work with things like subdivide, the coordinates will be more precise. So when you have the following case:

a = a.translate(some big coord).subdivide(4).translate(back to origin)
a = a.subdivide(4)

they have the same precision (though this is just a hypothetical example)

[elalish]

Oh, I see - by normalization you don't mean just multiplication, but also subtraction. The design of the precision is mostly concerning the Boolean ops, so intersections between edges of the two objects. Really floating-point isn't ideal for this, but it makes the math a lot more convenient than integer coordinates. But the fixed precision concept comes from the idea that really an intersection's precision is dictated by the worst precision a coordinate can have.

Maybe the key with your example (and others like it) is to not apply our lazy transformation, and simply stack them up in transform_ if they don't really affect the operation.

[pca006132]

Yes, that also works.