Make subcrates #![no_std]

[hauleth]

• num-traits
• num-integer
• num-complex
• num-iter

[cuviper]

I noticed in the 1.11 release notes that to_degrees and to_radians were just now stabilized in libcore. Things like this will constrain our rust version for going no_std. (But when we do make the breaking transition, we'll be choosing a new rust base anyway.)

[emberian]

Any timeline on when this will be done? Especially num-traits?

[Kixunil]

I'm interested in this too.

to_radians and to_degrees can be implemented easily without Rust support. It's simply self * PI / 180.0 and self * 180.0 / PI (with appropriate conversion).

[vks]

I started working on porting num-traits to no_std. However, I run into a very irritating problem:

error[E0308]: mismatched types
   --> src/sign.rs:116:38
    |
116 |                 <$t>::abs_sub(*self, *other)
    |                                      ^^^^^^ expected &f64, found f64
...
141 | signed_float_impl!(f64, f64::NAN, f64::INFINITY, f64::NEG_INFINITY);
    | -------------------------------------------------------------------- in this macro invocation
    |
    = note: expected type `&f64`
               found type `f64`
    = help: try with `&*other`

Removing the * does not work:

error[E0308]: mismatched types
   --> src/sign.rs:116:38
    |
116 |                 <$t>::abs_sub(*self, other)
    |                                      ^^^^^ expected f64, found &f64
...
141 | signed_float_impl!(f64, f64::NAN, f64::INFINITY, f64::NEG_INFINITY);
    | -------------------------------------------------------------------- in this macro invocation
    |
    = note: expected type `f64`
               found type `&f64`

So the compiler expects f64 and &f64 in the same place?

[vks]

Even fixing that problem by reimplementing abs_sub it still does not work:

error: no method named `is_finite` found for type `f64` in the current scope
   --> src/cast.rs:231:19
    |
231 |             if !n.is_finite() || (-max_value as f64 <= n && n <= max_value as f64) {
    |                   ^^^^^^^^^
...
273 | impl_to_primitive_float!(f32);
    | ------------------------------ in this macro invocation
    |
    = help: items from traits can only be used if the trait is in scope; the following traits are implemented but not in scope, perhaps add a `use` for one of them:
    = help: candidate #1: `use float::Float;`
    = help: candidate #2: `use core::num::Float;`

core::num::Float is not stable and float::Float seems to cause an infinite recursion.

[Kixunil]

Maybe .borrow() could help? (Just a guess, didn't see entire code)

[vks]

I backported is_finite from core::num::Float. It is just a few lines and does not use unstable intrinsics. However, now I'm getting infinite recursions in float.rs because it seems like almost all math functions are not implemented in core. This means we would have to depend on another crate to implement them.

[vks]

I think the best way forward is to split Float into the parts that require std and the parts that don't. This way it can be used by other crates for sorting floats (they don't need cos, sin, etc.).

[cuviper]

Given that #[lang = "f32"] and #[lang = "f64"] are in libstd, I'm tempted to say that we should just chop all floating point from num #![no_std]. But if you can reasonably hang on to some core-only pieces, then let's see what remains...

[vks]

But if you can reasonably hang on to some core-only pieces, then let's see what remains...

I think we should support everything in this file and the basic operations (Add, Sub, Mul, ...). That would be enough for e.g. sorting floats.

[cuviper]

I think it's fine to exclude core's unstable Float methods. Those are basically all the methods that are lang items in std, so we don't need to support them in no_std. That still leaves the constants and basic ops.

[vks]

Unfortunately they are required for sorting floats, it would be nice to still have `is_nan`, `is_finite` etc. They can be implemented in one line on stable using `core`.

…

On Tue, May 30, 2017, 19:32 Josh Stone ***@***.***> wrote: I think it's fine to exclude core's unstable Float methods. Those are basically all the methods that are lang items in std, so we don't need to support them in no_std. That still leaves the constants and basic ops. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#216 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACCtKsEuKDM9H5P6GDTalvSgtG9tKcfks5r_FLBgaJpZM4JgF8S> .

[cuviper]

Closing in favor of the separate issues:

• Make std a feature, using #![no_std] otherwise num-traits#16
• Make std a feature, using #![no_std] otherwise num-integer#4
• Make std a feature, using #![no_std] otherwise num-iter#1
• Make std a feature, using #![no_std] otherwise num-complex#6