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

float::round doesn't #3281

Closed
jesse99 opened this issue Aug 25, 2012 · 4 comments
Closed

float::round doesn't #3281

jesse99 opened this issue Aug 25, 2012 · 4 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@jesse99
Copy link
Contributor

jesse99 commented Aug 25, 2012

Doesn't work as expected that is. Reasoning by analogy with the int modules I would expect that float::round(5.8) returns 6.0, but instead you get: error: mismatched types: expected core::libc::types::os::arch::c95::c_double but found float.

Looking at the code I expect that more that just round has this problem.

@brson
Copy link
Contributor

brson commented Aug 25, 2012

This is because c_double is a typedef for f64, and f64 and float are not type compatible (they used to be). Most of the float functions are just reexports of bindings to the C math libraries.

The easiest fix is to write wrapper functions in core::float that cast to the right type (will be a noop).

Beyond that it might be nice to think about how to get rid of the duplication between float/f32/f64.

@catamorphism
Copy link
Contributor

3e9c95e fixes the specific problem with round. @brson, I'm not sure if the other issues you pointed out still apply or not.

@catamorphism
Copy link
Contributor

(sorry, clicked close by mistake)

@alexcrichton
Copy link
Member

The specific code in question appears to have been fixed in d9c54f8, although
it turns out that std::float::round == std::f64::round always, so
std::float::round(2.3f) is actually a failure. I think this should be a
separate issue, however (one that probably wants removal of a number of
top-level functions in the numeric modules.

I believe the preferred method is now 3.2f.round(). This won't work for
literals (3.2.round() has multiple methods applicable in scope), but it would
work for any floating type which is inferred somewhere else (to be expected).

I'm going to close this saying that it's been fixed, but if others feel
differently I can definitely reopen.

RalfJung pushed a commit to RalfJung/rust that referenced this issue Jan 28, 2024
jaisnan pushed a commit to jaisnan/rust-dev that referenced this issue Jul 29, 2024
We believe the `--visualize` is much harder to use than concrete
playback. In the rare cases where a trace might be relevant, users can
still use CBMC trace.

For most users, this will simplify installation since Kani will no
longer depend on Python3.

Note: As opposed to `--function` which was purely an internal feature, I
believe we have mentioned `--visualize` to users before, so I think it's
important to have a deprecation period.

Related rust-lang#2832
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

4 participants