Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd support for hexadecimal float literals #1433
Comments
This comment has been minimized.
This comment has been minimized.
|
I have played with this issue and concluded that this unfortunately revives issue #1306. The current lexer prohibits any alpha character after |
lifthrasiir
referenced this issue
Feb 5, 2013
Closed
No error handling of binary/hexadecimal floating literals #4804
This comment has been minimized.
This comment has been minimized.
|
I suggest requiring a digit or 0x or 0b after the dot. This avoids the collision and (curiously) lets you switch radix mid-literal if you choose. And it is only slightly uglier than what C99 makes you write. |
This comment has been minimized.
This comment has been minimized.
|
@graydon Or we can require only zeroes after the dot. (e.g. |
This comment has been minimized.
This comment has been minimized.
|
I don't believe this is backwards incompatible, renominating. |
This comment has been minimized.
This comment has been minimized.
|
accepted for feature-complete milestone |
This comment has been minimized.
This comment has been minimized.
|
visited for triage dating from 2013-07-15. Have we actually settled on a syntax here? This seems like it might be a nice easy task for a new contributor if we can hand them a clear specification for the syntax; but if the syntax is still in the design phase, then that claim is less true. |
This comment has been minimized.
This comment has been minimized.
|
I think we haven't quite nailed the syntax but I should point out it'd be necessary to avoid colliding with suffixes (some of which start with f, a hex digit), so I think if we do this it should only work for specifying the mantissa, and only when combined with a full exponent (in decimal). |
This comment has been minimized.
This comment has been minimized.
|
This has yet to be implemented. |
This comment has been minimized.
This comment has been minimized.
|
Not 1.0 |
rcxdude
added a commit
to rcxdude/rust
that referenced
this issue
Feb 16, 2014
rcxdude
referenced this issue
Feb 16, 2014
Closed
Add support for non-decimal floating point literals. #12323
rcxdude
added a commit
to rcxdude/rust
that referenced
this issue
Mar 2, 2014
rcxdude
referenced this issue
Mar 2, 2014
Merged
Implement hexadecimal floating point literals via a syntax extension #12652
rcxdude
added a commit
to rcxdude/rust
that referenced
this issue
Mar 2, 2014
rcxdude
added a commit
to rcxdude/rust
that referenced
this issue
Mar 4, 2014
rcxdude
added a commit
to rcxdude/rust
that referenced
this issue
Mar 9, 2014
rcxdude
added a commit
to rcxdude/rust
that referenced
this issue
Mar 9, 2014
bors
added a commit
that referenced
this issue
Mar 10, 2014
bors
added a commit
that referenced
this issue
Mar 11, 2014
bors
added a commit
that referenced
this issue
Mar 11, 2014
bors
closed this
in
a38e148
Mar 11, 2014
jxs
added a commit
to jxs/rust
that referenced
this issue
Apr 2, 2014
This comment has been minimized.
This comment has been minimized.
|
Hexadecimal floats are quite popular among C math libraries. And I would love to use them in Rust as well. I see that hexadecimal float has been implemented in rust as an extension, then moved to a separate crate and now it is at the What is the future of this feature? |
This comment has been minimized.
This comment has been minimized.
ColonelThirtyTwo
commented
Mar 17, 2017
•
|
Also interested in this. I'm looking to implement a replayable physics system for a game, which requires consistent results across computers. Hex float literals would allow me to write bit-exact floating-point values in tests and constants. At the very least, a statement why this feature is being deprecated would be appreciated, as this thread is the first result I get for "rust hex float literal". |
This comment has been minimized.
This comment has been minimized.
|
The situation is a bit icky at the moment. Procedural macros are going through a revamp right now (#38356), and so it would at least be a waste of time to keep |
This comment has been minimized.
This comment has been minimized.
|
If my understanding is correct, hexadecimal floats in C/C++ are there because decimal floats are not guaranteed to round correctly [1]. In Rust, however, after #27307---I suspect this is not necessarily intentional though!---almost all decimal floats (#31407 describes edge cases that are practically irrelevant) should round to the nearest, so you can just give rustc an appropriate number (say, 30) of fractional digits and will get the correctly rounded number. This would be a "practical" answer for now. One thing for which I still think hexadecimal floats are relevant is a conversion from C/C++. You wouldn't want to convert all hexadecimal floats to decimal yourself :) I have recently written an experimental procedural macro that does exactly this, converting hexadecimal floats to decimal floats (that rustc can understand), but had been reluctant to release one because the status quo was not actually guaranteed so far---it's a pure luck in my opinion. If there is a way to construct a float with exact bit pattern only from constexprs I will adapt that. [1] For example, ISO C99 only requires that decimal floats should be converted to a representable number within ±1.5 ulps ("the result is either the nearest representable value, or the larger or smaller representable value immediately adjacent to the nearest representable value"). |
This comment has been minimized.
This comment has been minimized.
|
@lifthrasiir, sooner or later I'd like to fix jameysharp/corrode#73 by correctly translating C hex floats to Rust, so I'd like to understand your comment better. I haven't done enough reading on floating-point issues to understand what's involved here yet. Are you saying that, modulo Rust compiler bugs, every hex-float literal can be converted to a decimal float literal that the Rust compiler will convert to the same bit-pattern? If so, I'd be happy to have Corrode do that conversion. Can you recommend a reference I should read for an algorithm to do that conversion correctly? (A pointer to your procedural macro would be great, but ideally I'd like to have a paper or book to cite too.) That said, I gather the exact decimal version of a hex float may take significantly more digits (right?), so perhaps the hex-float version is easier to read and understand, at least for people who care enough about numeric precision to use them. If hex floats are the human-preferred form for these numbers, I'd argue that Rust should support them. So IMO, more feedback from people who have used hex floats would help here. |
This comment has been minimized.
This comment has been minimized.
My belief is yes.
You don't have to implement that, because the current Rust compiler and standard library implements all necessary algorithms (which is harder one :-). If you really need references see the following:
For the record, my implementation is lifthrasiir/hexf (published right now, not yet in crates.io). Feel free to pick up.
Not exactly, for example, |
This comment has been minimized.
This comment has been minimized.
|
I've now formally published hexf to crates.io. @jameysharp, I think you can probably use hexf-parse for your work? (The syntax without underscores should be Edit: Aargh I missed one case. |
boggle commentedJan 5, 2012
We need to be able to parse the output of printf's %a for proper support of mathematical constants without loss of precision
(i.e. 0x1.fffffffffffffp+1023_f64 syntax)