You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the simplest way is to add dynamic rank as a new shape type and keep the existing layout types. The shape types for static rank are tuples of dimensions (each static or dynamic), and the new type will instead consist of a Box/Vec. The resulting layout mapping will then use Box/Vec for both shape and strides.
There can be limitations and for some operations like creating array views and permuting dimensions the rank must be static. But yes you can always convert to static rank for calculations.
Please correct me if I'm wrong, but with today's mdarray it is simply not possible to have arrays beyond a certain rank.
Of course there is no way around this with today's Rust given that macros need to be instantiated for each supported number of dimensions. And also the value of supporting static shapes beyond, say, 10 dimensions, seems marginal.
But for completeness and interfacing with other general array libraries, I think that supporting a fully generic layout would be very valuable.
The text was updated successfully, but these errors were encountered:
I think that mdarray could be ideal as the dense array backend for my library, but the one crucial missing feature is support for dynamic number of dimensions.
Would you be open to adding support for dynamic number of dimensions (following the idea you sketch out above) to mdarray?
I reference a discussion from rust-ndarray/ndarray#1272 (comment):
@fre-hu wrote:
Please correct me if I'm wrong, but with today's mdarray it is simply not possible to have arrays beyond a certain rank.
Of course there is no way around this with today's Rust given that macros need to be instantiated for each supported number of dimensions. And also the value of supporting static shapes beyond, say, 10 dimensions, seems marginal.
But for completeness and interfacing with other general array libraries, I think that supporting a fully generic layout would be very valuable.
The text was updated successfully, but these errors were encountered: