search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.14k stars 12.69k forks source link

Add support for hexadecimal float literals #1433

Closed boggle closed 10 years ago

boggle commented 12 years ago

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)

lifthrasiir commented 11 years ago

I have played with this issue and concluded that this unfortunately revives issue #1306. The current lexer prohibits any alpha character after . because of it. We may choose selectively allow them when the pattern 0x<digits>. is found, but it seems too inconsistent and may require infinite lookahead if we want to elide an inconsistency.

graydon commented 11 years ago

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.

lifthrasiir commented 11 years ago

@graydon Or we can require only zeroes after the dot. (e.g. 0x1fffffffffffff.0p+972_f64 instead of 0x1.fffffffffffffp+1023_f64)

pcwalton commented 11 years ago

I don't believe this is backwards incompatible, renominating.

graydon commented 11 years ago

accepted for feature-complete milestone

pnkfelix commented 11 years ago

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.

graydon commented 11 years ago

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).

thestinger commented 11 years ago

This has yet to be implemented.

catamorphism commented 11 years ago

Not 1.0

anatol commented 7 years ago

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 rust-deprecated and fails to compile with nightly rust.

What is the future of this feature?

ColonelThirtyTwo commented 7 years ago

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".

lambda-fairy commented 7 years ago

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 hexfloat up-to-date while this is happening. But I don't know what the story will be after that.

lifthrasiir commented 7 years ago

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").

jameysharp commented 7 years ago

@lifthrasiir, sooner or later I'd like to fix https://github.com/jameysharp/corrode/issues/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.

lifthrasiir commented 7 years ago

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?

My belief is yes.

Can you recommend a reference I should read for an algorithm to do that conversion correctly?

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.

That said, I gather the exact decimal version of a hex float may take significantly more digits (right?), [...] If hex floats are the human-preferred form for these numbers, I'd argue that Rust should support them. [...]

Not exactly, for example, 0x1.999999999999bp-4 = 0.10000000000000002. I have no opinion on whether Rust should support hex floats or not.

lifthrasiir commented 7 years ago

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 identical almost same to C99 hexadecimal-floating-constant non-terminal sans optional floating-suffix.)

Edit: Aargh I missed one case. 0x1p1 should be valid but hexf doesn't recognize it; probably it is easy to account for, though.

katef commented 4 years ago

Similar use-case for me too; I would like to be able to generate rust code from a compiler, without loss of precision for float literals.

Font77 commented 3 years ago

Can we have rust branch for hexadecimal as default base for ascii810 . GitHub.com/font77/hpop

Any how 0 was invented for implementation of hexadecimal no system in India .

Hexadecimal is easy vith 3 good things

  1. Thumbs are counters , fingers are countables . So 8+8=10=4*4
  2. Hexadecimal is (8+8) / (8+8) % complete dizitization, decimal is incomplete dizitization (5+5)/(8+8) % .
  3. In hexadecimal 10 , 8 , 4, 2, 1, 0.8 , ... series remains even till 1. In decimal 10, 5, .. It is not even.
entropylost commented 3 years ago

I also need binary floats...

MultisampledNight commented 2 years ago

So I'm a bit confused by the status quo here. I'd like to use :literal as fragment specifier in a macro to filter NaNs (as you can't write out NaNs only with one literal), since writing out NotNan::new(...).unwrap() (with NotNan from the ordered_float crate) can be quite lengthy as a unit specifier in a GUI toolkit. But from this issue... will this ever be implemented?

cmpute commented 2 years ago

Is it possible to allow the hexadecimal literal in procedure macros? I want to allow uses to create arbitrary precision binary float number losslessly in dashu-macro , however the syntax is rejected by the lexer before proc macros are executed. If this could be done, then at least we can have proc macros libraries to support the hexadecimal literals. (Just like arbitrary postfixes for integer literals are permitted by lexer, but not allowed in the real code)

rvagg commented 11 months ago

For anyone (else) stumbling on this issue, wanting some tooling related to hex floats, if not literals: