Add property-based tests for cross-products

[nicoonoclaste]

PR targetting the branch for #65

• Add linearity and anti-symmetry test
• Document that cross-products may overflow on large vectors
• Restrict the generated vectors to avoid overflow (pulled in tests.utils.vectors: Make the max. magnitude configurable #69)
• Fix the exposed numerical instabilities in cross-products.

[nicoonoclaste]

@astronouth7303 The numerical instability revealed by the tests has been recently studied by W. Kahan (yes, the same one who had useful information about the instabilities in angle computations).

[AstraLuma]

Is there a way to test around the instability? If this is an on-going area of study, I think we should just accept it and work with/around it.

[nicoonoclaste]

PS: #65 was merged without this, so it should be re-targetted against master

[AstraLuma]

There is a failure of the linearity test, as well. I assume this is the instability you've referred to before?

[nicoonoclaste]

@astronouth7303 @pathunstrom I was poking at making the cross-product more numerically stable, when I realised that there's nothing that uses it anymore since #68 was merged.

I kinda feel like removing the feature outright might be sensible, since providing a well-behaved cross-product is pretty hard. What do you think?

[AstraLuma]

This seems reasonable, since this only exists because you needed it for some algorithm.

Is there something external that you'd want it for? Intersections? Sidedness?

[nicoonoclaste]

It can be used for sidedness, yes. If someone decides they need it, it would be pretty easy to bring it back, but AFAIK it never was in any release, so it should be fine to drop it?

And yes, I initially added it for implementing Vector2.angle but the current implementation doesn't use it anymore (the asin( a.normalize() ^ b.normalize() ) implementation had stability issues, and there were quadrant ambiguities)

[nicoonoclaste]

PS: Just pushed some local changes I had, for the record, but if you confirm we can remove the feature, I would rather do that.

[nicoonoclaste]

@astronouth7303 Mmmh, cross-product is also nice to check if vectors are aligned.
(x and y are aligned iff x ^ y ≃ 0)

[pathunstrom]

Pretty sure dot product can be used for the same purpose? At least all the math for game dev tutorials I've read use the dot product.

[nicoonoclaste]

@pathunstrom The dot product is a bit more annoying to use for that purpose, IMO (you have to normalize & such). OTOH, I just realised this makes no sense, we have a perfectly fine Vector2.angle method, which is probably the better way to check whether things are aligned.

[nicoonoclaste]

Replying to @astronouth7303's comments on #80 (I think it would be better to keep the conversation here) :

What algorithms depend on (or significantly benefit from) cross product, even ones not included in this library?

Nothing in the library use cross-product, and I can't think of anything I would want in a game that benefits from it; for general geometry, cross-product is pretty convenient for computing the area of triangles or parallelograms between 2 vectors (area_plg = 2*area_triangle = abs(a ^ b)).

Can we characterize the instability? Is it something that only appears at extremes or are there perfectly reasonable vectors that have major problems?

Yes, the instability occurs when there are near-parallel near-perpendicular vectors, IIRC.
It keeps occurring even if I crank up the relative tolerance to 0.01 (i.e. tolerate 10% error) and with small (but not ludicruously-small) vectors.

[AstraLuma]

That's a pretty significant instability (10% will probably have noticeable effects in a game) for normal vectors. I think that qualifies cross product as a foot-gun and it should probably be removed on that premise.

[AstraLuma]

@pathunstrom your vote?

[pathunstrom]

I'm all for keeping foot guns out of the ppb name space.

[nicoonoclaste]

❤️