Less strong trait bounds for algorithms

[jbirnick]

Hello, I would like to use nalgebra for my project, however one thing that prevents me from that (and which also confuses me) is that all the e.g. matrix algorithms (QR, SVD, ...) require the base type to implement ComplexField.

But this trait is huge, requiring to implement sin, exp, acosh and what not. It also has a lot of supertraits. I guess those linear algebra algorithms never use those trigonometric methods, also also don't need all the supertraits, so why are the requirements so strong? Couldn't there be a trait with less strong requirements?

I want to use nalgebra together with arbitrary-precision floats, like the ones from rug. I would argue this is a quite common/important use case, but the huge trait ComplexField which is difficult to implement poses a significant barrier for that.

Other people had the same problem: https://stackoverflow.com/questions/73871027/use-nalgebra-with-float-types-from-rug

[Ralith]

Requiring only the exact operations used has other drawbacks: it leads to more complex trait bounds, slower compilation, and leaks implementation details in a way that is highly prone to breaking changes. Perhaps there's a sweet spot in between somewhere (promising not to use hyperbolic trigonometry in most algorithms probably isn't a maintenance hazard), but some careful analysis and design would be required to capitalize on that.

[jbirnick]

Yeah I think a sweet spot without trigonometry would be great.

[Gauthamastro]

I am also facing this issue, forcing me to implement the complex traits or look for other libraries. It would fantastic if nalgebra can reduce trait constraints. I believe it should be opt-in for these stronger guarantees. Maybe a feature flag?

[Gauthamastro]

Just in case, anyone wants a workaround: https://docs.rs/astro_nalgebra/0.1.1/astro_nalgebra/