-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please unseal trait Dimension #1326
Comments
Unsealing Dimension is not realistic at this time, I'm sorry, it has been used to avoid a lot of breaking version bumps. Next step for dimensions is bringing them over to const generics, so they will be redesigned. I'm not available to help you with design right now, I'm sorry. Named dimensions would be great. I enjoy xarray (Python) a lot. |
I did get compile time bounds checking of named tensors working in rust but without type aliases the errors are unreadable HLists of TypeNum, const generics are an interesting approach to improve the comptime bounds checking, but without custom named dimensions (literally just a new type of integer which implements your Dimension) it's a crapshoot to remember which axis is which name, always indexing with integers instead of names and users will continue to struggle with runtime shape bugs. There might be a way for you to suitably control your Dimension trait using macros to define newtypes of Dimension to basically assign a 1-letter struct and a full name trait, then einsum looks extremely nice and readable and you can catch the bugs at compile time. Burn has a proto-version of this, but imho nobody has figured it out properly, and it's the difference between runtime crashes and not, I'd meekly suggest it's a good project, and I'm happy to share some code. Probably the answer (for me) is to quit rust and use zig, compile time functions could be dramatically more readable than the nonsense hoops we must jump through for type level rust right now. Alas, the rest of zig ecosystem doesn't seem to have what we need. it's tbh a tantalizingly close objective to eliminate runtime shape bugs with Rustc, but yeah, a lot of work |
Hi, today I wanted to impl Dimension in a macro so i could make custom dimensions; anyway, long story short, I couldn't make a custom newtype of (usize) axis by implementing Dimension because it has a
__private__
function. Could you please remove the__private__
function from trait Dimension or make some builder for new Dimensions or tell me how I'm being a noob and it's easy? I reckon users of the library can empower Rustc to catch shape bugs and wrong-axis-indexed bugs at compile time instead of with panics at runtime, and I always feel dumb when my code crashes at runtime for something I could theoretically have caught at compile time but didnt. (Like when you mix up the TickersAxis and the TimestampsAxis ... whoops)something like that, we could make named dimensions, maybe it's not really adding too much complexity, but we could be explicit about our axes, and prevent a lot of issues, just by moving information about shape variables from comments into the type system
vs
or (better with the parens imho)
Could you please tell me if something like this is already possible with Rust's ndarray, and if not, can we please enable it? I'm guessing I'm just a noob and it's in the docs somewhere? Maybe it belongs as a bullet point above the fold on the front page if it's doable because any time we can make Rustc check our work, it's helpful. Or, perhaps I'm just a tryhard and this isn't necessary or I'm not appreciating the downstream issues this might cause?
Anyway, thank you for the crate! I enjoy it!
The text was updated successfully, but these errors were encountered: