-
Notifications
You must be signed in to change notification settings - Fork 324
No_std support for ndarray #864
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
Conversation
catch_unwind is implemented in std
It looks like core is not found in oper.rs
libcore cannot be used in blas-tests/oper.rs, which is a bit strange |
Hm, do we need to start it this way? I'd suggest using the extern crate core as std solution, as I mentioned in the issue. We need to figure out which tests to run in the no-std configuration. Crate test in itself depends on std, so we can keep using std in the test files. |
In that case, it means that all dependencies on std in ndarray must be handled at once. Well, I will try that method. |
@bluss It seems that we need to resolve the dependencies of external cretas next. Do you think we should do it together here or in a new pr? [Edit]They are mainly num-trait::Float and serde( and maybe others ). I can solve the former by using the limb feature in num-trait, while the latter is an optional package I haven’t changed for now. |
…space、var_axis、std_axis cannot use.
@bluss now it use FloatCore as Float in no_std environment. I think it will not affect the function under the std environment and can theoretically be used under no_std |
@SparrowLii That kind of solution (FloatCore as Float) is not someting we can use in our public interface, it will create incompatibilities between our dependencies (it's a non-additive change to our API depending on features, which is not allowed). crate features must be additive. When enabling |
src/lib.rs
Outdated
#[cfg(feature = "std")] | ||
pub use num_traits::Float; | ||
#[cfg(not(feature = "std"))] | ||
pub use num_traits::float::FloatCore as Float; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line must be deleted. Then we follow the consequence of that for not(feature="std")
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we need a creative solution, then we can "redirect" to support only f32, f64 on no-std (not general FloatCore!). Then we can feature-safely expand our methods bounded on A: Float
to support the full A: Float
range with std.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for my lack of experience. I will change it.
I think it is cool to expand for FloatCore under no_std, but if we don’t use libm, we might have to implement exp() and ln() functions ourselves. I doubt about that.
Apologies for my lack of experience. Have changed it. |
Replacing the libm feature is not a goal no, don't worry about that. |
Sorry for a little not understanding. So it means adding libm features or expand for FloatCore ourselves in ndarray?:) |
Added libm features, so we can use --no-defualt-features --features "libm" to use all Float functions under no_std |
@bluss any more advice? I think it can already be used under no_std. Maybe we should find a good way to verify? |
I think this is a hard task if we try to do the impossible (making FloatCore/Float fit together). Let's follow a simple recipe which means that std is an additive feature. When std is disabled, some API is going to be missing because of that. Anything else than that can be improved later. |
Okay then, it should be better. |
@bluss Now we avoid using the Float feature in the no_std environment. It can run under no_std. WDYT? |
Great work, looks like it works. That's all we need for now. Features can be added back later.
|
@bluss I updated the description of std feature and updated the pr description. But there are still two problems: |
README.rst
Outdated
default `std` feature. Use this in `Cargo.toml`: | ||
|
||
[dependencies] | ||
ndarray = { version = "0.14.0", default-features = false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example with the version is nice but we should not use a specific version. Just more places to update when we bump the version. So we don't make an explicit example like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we also need to put the same update about feature flags into src/lib.rs
- the module docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, has updated
Thanks! Finally done |
This pr enables ndarray to be used in the no_std environment, and maintains most of the functions. Fixes #708.
The
geomspace
linspace
logspace
range
var_axis
andstd_axis
methods are only available whenstd
is enabled at current. And 'blas''rayon''serde' features are not available without std too.