Skip to content
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

FBig and other dashu types should implement num crate traits #31

Closed
TheQuantumPhysicist opened this issue Apr 12, 2023 · 7 comments
Closed

Comments

@TheQuantumPhysicist
Copy link

TheQuantumPhysicist commented Apr 12, 2023

The native, correct way to handle new types of floating point numbers (and integers, for that matter) is by implementing the de-facto traits of that: https://crates.io/crates/num

For example, instead of using fbig!(1), FBig should implement num::cast::FromPrimitive, where then this conversion can be done with something like FBig::from_u64(1).unwrap().

Also, FBig should implement num::Float.

It would be really nice to have these implemented, so that the crate types can be used like other floating-point numbers and integers in rust. Having special, isolated work for everything just makes it harder to integrate dashu into projects. Currently all my code that works with Float trait cannot be ported to dashu, so I have to duplicate things just for dashu to work.

@cmpute
Copy link
Owner

cmpute commented Apr 12, 2023

Thanks for the comments, support for FromPrimitive and ToPrimitive has been in plan for a long time and it is under development. It will probably be implemented after next major version bump, because I have to revisit the dependency structure (it's worth noting that num crates are all pre-1.0).

Regarding num::Float, I will argue that it's not the correct way to handle new types of floating point. It's not properly designed for arbitrary precision floats, it's not even satisfactory for normal floats (see the issues related to floats in num-traits, especially rust-num/num-traits#98 and rust-num/num-traits#178).

My advice will be creating your own traits if you want to generalize over floats. Only put the methods you need in the traits.

@cmpute
Copy link
Owner

cmpute commented Apr 12, 2023

Besides, I would also like to point out that the macro fbig!(1) is only intended for creating compile-time constants! It should not be used in exchange with runtime conversion methods (such as From::from() or FromPrimitive::from_u64).

@TheQuantumPhysicist
Copy link
Author

Thank you for the information.

@astrale-sharp
Copy link

Hi, does that mean they will implement traits in num_traits then?
Cause even with
dashu-float = { version = "0.3.2", default-features = false, features = ["num-traits","num-traits_v02"] } in my Cargo.toml, it seems that Fbig doesn't implement num-trait::Float for instance.
Am I doing something wrong?

@cmpute
Copy link
Owner

cmpute commented Apr 23, 2023

Hi, does that mean they will implement traits in num_traits then?
Cause even with
dashu-float = { version = "0.3.2", default-features = false, features = ["num-traits","num-traits_v02"] } in my Cargo.toml, it seems that Fbig doesn't implement num-trait::Float for instance.
Am I doing something wrong?

I won't implement num-trait::Float for thr FBig, since that trait is somewhat incompatible with arbitrary precision floats.

@astrale-sharp
Copy link

Interesting! How come? (is it because of the copy bound?)

@cmpute
Copy link
Owner

cmpute commented Sep 13, 2023

I would like to close the issue due to the reason I explained in #31 (comment). The FromPrimitive and ToPrimitive traits are implemented in v0.4. Feel free to reopen it if you have any further questions.

@cmpute cmpute closed this as completed Sep 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants