Replies: 3 comments
-
You can use the I think this would probably be better as a discussion than an issue since there are a few different things being raised here and nothing to be actioned yet. I can convert it to a discussion if you don't have any objections. |
Beta Was this translation helpful? Give feedback.
-
Sounds good, please convert thanks. |
Beta Was this translation helpful? Give feedback.
-
You can now use libm overrides without needing to use no_std. |
Beta Was this translation helpful? Give feedback.
-
I don't fully know the best way to solve this just yet but figured some discussion would be a good first step.
The motivation is that sqrt, sin and cos intrinsics can return different values on different platforms.
I don't think it would be ideal to make glam implement these in software by default for the sake of cross platform determinism, as that is a large performance sacrifice. I don't even think glam should have built in software implementations of these.
Instead, I would like to see some way to allow these functions to be implemented externally by users and have a way to tell glam to use those implementations, perhaps with a feature flag. I'm not sure how much additional complexity this would be though.
Ideally, alternate implementations of trigonometry need not even be in radians: if the user wants to use degrees or sinpi/cospi natively, then there should be appropriate adjustments of PI constants used in glam for rotation construction etc.
Furthermore, there should be the possibility to provide vectorized implementations of these functions when possible/needed, as polynomial approximations are trivial to vectorize.
Finally, these alternate implementations should be easy to bundle up into a crate, and be mostly drop-in for projects.
We can use libm, as nalgebra does, for a good default cross-platform deterministic implementation.
I'd be happy to implement any solution we reach.
Beta Was this translation helpful? Give feedback.
All reactions