Closed jedbrown closed 9 months ago
I'd really appreciate a PR about this!
For the float methods, I'd be fine with any short term solution you choose, whether that is disabling the methods that are not available in no_std
altogether or pulling them in from num_traits
.
Long term, I'd have a look at how other libraries do this. Not every no_std
usecase will be able to / want to pull in a num_traits
dependency, so maybe having adding yet another feature gate for the additional float methods would be a good idea.
We'd like to use diman for material models that we compile both for the host and for use inside GPU kernels (e.g.,
--target nvptx64-nvidia-cuda
). Judging by the error messages, it looks like this mostly amounts to replacingstd::
withcore::
in the source and macro expansions and dealing with math (everything infloat_methods
is not inno_std
, though it can be accessed through various means using num-traits). I tried a blunt search/replace and now only have errors tracing tofloat_methods.rs
, and I could turn that into a PR with some feedback about what features to use to expose the features (e.g., disable those math operations or depend onnum_traits
for them).