search

akern40 / ndarray-design

Design concepts for `ndarray`'s core.
4 stars 0 forks source link

subcrate strictly for nd-traits? #2

Open skewballfox opened 2 days ago

skewballfox commented 2 days ago

I apologize if this is misguided. Something that might be useful is to have a crate that functions as an ndimensional equivalent to num_traits completely divorced from assumptions about the implementation in ndarray.

My rationale is a lot of scientific computing libraries (in rust and elsewhere) seem to be one-off herculean efforts that then just continue to be used so long as the library is usable with the other libraries the end developer is using, and there are only so many ways to represent an ndimensional data structure in terms of actual data layout. The Nd traits could be generic enough to account for each of representations. If they are implemented for other nd/tensor types (for example candle's cpu tensors or rapl's Ndarr), either directly or with a wrapper type, then they provide a better target for authors of single purpose libraries (such as an ND fft, or a perlin noise generator): They can write something that uses the traits that ensure the implementor has the properties/functions they need, use one of the implementors for testing (such as ndarray), and then barely touch it afterwards.

akern40 commented 2 days ago

Thanks for asking! I mostly agree. There was even talk in the original ndarray reference type RFC of moving to a trait-based design. However, to go beyond ndarray would probably have to come from a larger consortium or committee, probably including the nalgebra and faer authors, at least. However, I don't think ndarray is in shape yet to contribute to this kind of work.

I do think the question of types vs traits for unifying arrays is interesting. I have played around with the idea of creating an underlying type that could serve multiple libraries, and I think it could be done. Whether it should be, I'm not sure.