The state of math libraries

[Osspial]

The big math libraries are cgmath and nalgebra. Both of them have deal-breaking flaws for many, namely (imo):

• cgmath has a weird, idiosyncratic design that simultaneously does too much and too little, and tries to shoehorn in genericism with complex traits that are difficult to internalize.
• nalgebra stretches the type system so far that the documentation is nigh impossible to understand without extreme patience and a deep understanding of generics.

As a result, several people have gone and made their own math libraries that try and solve those problems, which don't get adoption because the ecosystem hasn't grown up around them. I'd like this issue to house discussion on how exactly we can go about designing a library that addresses those issues, while developing enough consensus that we can potentially replace both of the current libraries.

[bitshifter]

Ah ok, I guess it's changed since I last looked at it :)

[aclysma]

Still been thinking about this! :)

• glam looks like a really good solution for targetting f32 <=4 axis vectors. (Hektor looks promising too! but it doesn't look as far along yet.)
  • It looks like glam is using code from here (https://gitlab.com/kornelski/ffast-math/blob/master/src/lib.rs) marked as "No license. All rights reserved" in the project it's within. @bitshifter are you certain this can be shared as MIT/apache2?
  • it might be worth exposing the non-simd types in glam as a separate name, even if not disabling SSE via "scalar-math."
  • Glam (or something else) being f32 only doesn't preclude someone from making a "glam64" crate. (and it's possible getting the "best" implementation for f64 might not be just a matter of doubling widths and doing the same basic ops.. i.e. there could be fast paths f32 can take that f64 cannot)
• nalgebra still exists for the general case
• nalgebra and something like hektor/glam are different tools.. along the lines of what @lokathor said about HashMap/BTreeMap, [f32;4]/[T;n], and __m128 have completely different tradeoffs and some problems call for one and some the other. The OP mentioned "developing enough consensus that we can potentially replace both of the current libraries" and I think after reading everyone's comments and thinking about it, I don't think we should pursue that.
• But it may be possible to have similar APIs (i.e. glam/hektor could look like nalgebra_glm)
• If someone has a case where glam isn't general enough, and nalgebra isn't fast enough, likely their situation calls for a tailor-fit solution.

BTW in addition to glm as a reference, there is https://github.com/microsoft/DirectXMath as well. (MIT licensed) SIMD implementations there go beyond SSE2 which is a nice perk.

[bitshifter]

@aclysma that code is unused, it's something I wanted to play with but never got around to it. Sort of forgot about it but given the licence I should just remove it.

Glam could support f64, it's just far down my priority list.

[Lokathor]

So we talked about this issue a little at the meeting today, and @AlexEne wanted us to try and form some conclusions here so that we don't get long running issues that ramble too far away from what the issue was first about.

There has been quite a bit of discussion about this here and also in the Rust Community Discord, and perhaps other places too. I'll attempt to summarize the major points.

Big Conclusion

The issue started by asking if there's some way we can make a single, easy to use math library for everyone to rally around as a standard.

• No, this cannot be done. At least, not in the near term (eg: by the end of 2019).

Reasoning

Developing a complete math library is quite a bit of work. While it might be possible to some day unify the math world, the limiting factor is time.

• Some people want to design around "actual math" and generality of operations, with full, complete support for any numeric type and any dimension, covering every possible math situation that may arise. This is the path of nalgebra and nalgebra-glm.
• Some people want to focus on "common case" performance and design the library internals around what usual hardware will actually be able to perform as quickly as possible. This leads to intense focus on f32 and dimensions of 4 or less, and use of hand selected SIMD intrinsics in each particular method, checking micro-benchmarks, etc. This is the path of glam and hektor.
• Rust currently doesn't have any form of specialization, so if you want to have the individual intrinsics treatment then you must give up the generics. This sort of system will doubtless be added eventually in some form, but definitely not in 2019.

Smaller Conclusions

• If you're happy with the math library you're currently using, keep using it. No one is having their existing libraries taken away. No one has to switch to a new library.
• If you'd like to contribute to the development of any math library please do so! I'm sure that all of the math libraries have parts that can use some extra help regardless of your current math skill level.
• The gamedev-wg will revive the effort on the "ecosystem guide" in the next few weeks and we will attempt to make clear that some math libs are focusing on hardware optimizations while others are staying as general as possible. People can decide for themselves how they want to go.
• Some of us at the meeting were a little unhappy with a purely linear discussion presentation. Here's a reminder that, among the many ways to talk about this stuff, there's a rust gamedev reddit, which allows for "tree" style commenting and discussion. This fits some topics better than others. I'm sure most folks have heard of reddit, but maybe people didn't know that there's a dedicated rust gamedev reddit, so give that a look if you didn't know.

Bonus Reminder

The meetings are just a way to improve communication, they do not form binding decisions, decisions are reached in the github issues so that everyone has a chance to participate regardless of time zone.

Please feel free to continue to post in this issue, but please also attempt to keep it to new points, not just re-hashing the same points we've gone over.

If you'd like to have side discussions that aren't quite about how to unify (or not) the math ecosystem please open distinct issues for that.

[AlexEne]

I am closing this one with the idea that some sort of conclusion can be incorporated in the ecosystem page.