Add fixed-point sin/cos, to fix OOS errors
Description
Description
Details
Details
- Auditors
wraitii - Committed
philip Jul 4 2010, 7:15 PM - Parents
- rP7689: Use more precision in debug serialization, to help debugging of OOS errors
- Branches
- Unknown
- Tags
Event Timeline
Comment Actions
The precision is insufficient. Because of this, the obstruction squares have (u,v) vectors which aren't correct (not properly normalised and just plain incorrect), which down the line results in incoherences between PathGoal::RectContainsGoal and PathGoal::NavcellRectContainsGoal (among others I guess).
I've noticed this while trying to understand why D1835 sometimes returns different results from svn in cases where it ought not to.
We need a precise-enough™ version of this code to make sure these incoherences are removed. I'll update the tests later.
Comment Actions
An idea: why don't we rewrite the fixed types to wrap a floating-point number and code all functions modifying this number (like addition, multiplication, sin, cos, etc...) in assembly using the SSE(2) instruction set? All our target platforms should (currently) support SSE2 and we could probably provide software fallbacks for non x86 architectures if we where to ever support them. SSE should be fully specified and thus deterministic across processors, as far as I'm aware (and NEON on ARM may even be (mostly) consistent with it). Using assembly functions would ensure that the exact order of execution will be the same across compilers.
Comment Actions
IIRC Raspbian has a 0ad package, so even unwillingly we support ARM. I believe I remember someone talking about making it run on a RISC-V architecture. There is also a patch for ppc
Comment Actions
Yeah. Well. It seems that we could probably get it to be consistent across all these platforms, but it wouldn't solve this problem. And I doubt it would be worth the effort after reading a bit. Some links:
https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/
https://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html
Comment Actions
Er, while the sinus approximation could be improved, it would probably require a lookup table and won't be perfect as our fixed points have limited precision.
Anyways, my problem isn't actually with this code in this instance, but rather with PathGoal's geometry functions, I'll just update D1829.