Support hexadecimal floating point literals #114667
Comments
This add hexadecimal floating point literals (IEEE 754-2008 §5.12.3) and
support construction of floats from hexadecimal strings. Note that the
syntax is more permissive: everything that is currently accepted by the
float.fromhex, but with a mandatory base specifier; it also allows
grouping digits with underscores.
Examples:
```pycon
>>> 0x1.1p-1
0.53125
>>> float('0x1.1')
1.0625
>>> 0x1.1
1.0625
>>> 0x1.1_1_1
1.066650390625
```
Minor changes:
* Py_ISDIGIT/ISXDIGIT macros were transformed to functions
This add hexadecimal floating point literals (IEEE 754-2008 §5.12.3) and
support construction of floats from hexadecimal strings. Note that the
syntax is more permissive: everything that is currently accepted by the
``float.fromhex()``, but with a mandatory base specifier; it also allows
grouping digits with underscores.
Examples:
```pycon
>>> 0x1.1p-1
0.53125
>>> float('0x1.1')
1.0625
>>> 0x1.1
1.0625
>>> 0x1.1_1_1
1.066650390625
```
Minor changes:
* Py_ISDIGIT/ISXDIGIT macros were transformed to functions
This add hexadecimal floating point literals (IEEE 754-2008 §5.12.3) and
support construction of floats from hexadecimal strings. Note that the
syntax is more permissive: everything that is currently accepted by the
``float.fromhex()``, but with a mandatory base specifier; it also allows
grouping digits with underscores.
Examples:
```pycon
>>> 0x1.1p-1
0.53125
>>> float('0x1.1')
1.0625
>>> 0x1.1
1.0625
>>> 0x1.1_1_1
1.066650390625
```
Minor changes:
* Py_ISDIGIT/ISXDIGIT macros were transformed to functions
|
#114668 is ready for review |
|
Hi @skirpichev and thanks for the proposal. Unfortunately a change of this magnitude needs a PEP. Please read about it https://devguide.python.org/developer-workflow/lang-changes/#suggesting-new-features-and-language-changes |
|
Normally, to reduce the noise PRs and issues are submitted after a PEP is approved. |
|
@pablogsal, perhaps I misunderstood suggestion in the discussion thread (that this change may require a PEP), i.e. "should" was interpreted per RFC2119. The PEP draft was presented in the discussion thread (though it not reflects now the shape of the pr, which uses more Should I close pr and issue? PS: Sorry for the noise. |
No, now that is open leave it. I have already mentioned in the PR that until a PEP is accepted it should not be merged. This is just a suggestion for the future. This is because the specification of the PR may change quite a lot before it's accepted, so reviewing it it's not super useful.
Not sure I understand what you mean by this. This change requires a PEP because it's changing the grammar, so you need to follow the PEP process before we can get it merged |
I meant reply by Mark Dickinson.
Perhaps, I misunderstood something in the above reference, but it doesn't have a strict requirement for a PEP in case of grammar changes. My guess was that it might be the case, if the feature could be implemented without backward incompatible changes. Sorry, and thank you for a clarification. |
|
Despite some support in the d.p.o thread, it seems this is not enough. I can interpret @tim-one comment as being against this idea (i.e. float.fromhex() syntax as more readable). I'm not sure if it's strong: hexadecimal literals are part of many contemporary languages (PEP draft lists some). One use-case outside of the CPython itself might be using new literals in the mpmath CLI, i.e. to wrap them with an appropriate multiple-precision type. That will be much easier and robust, but in principle it's doable now: Given that related issue (formatting as binary/hexadecimal float) was rejected, probably mentioned comment also enough to reject this as well. I will close issue and pr in few days, unless this proposal does make sense for someone. CC @rhettinger? (per discussion thread) |
|
Ok, nobody saved this :( |
skirpichev
removed
the
pending
Feature or enhancement
Proposal:
The Python supports only decimal floating point literals. But underlying hardware based floating point numbers are binary, not decimal, and conversion to and from decimal representation is delicate: it's not obvious which binary floating point number represent a given decimal literal.
Exact floating point representations are especially important for reproducible results --- for instance, while testing "borderline cases" in algorithms. Because of this, many contemporary languages (e.g. C, Go, Julia, Java) introduce hexadecimal floating point literals in source code. This format also common in the numerical analysis community (see e.g. this example or the MPFR library).
Lets accept exact floating point literals (beyond simple cases like
0.25) as first-class citizens in the language! Right now the Python include support for hexadecimal floats viafloat.fromhex()andfloat.hex()methods, which extensively used in it's test suite (e.g. to testmathandrandommodules). But using the class method to create exact floating point values much less convenient, especially doing interactive work:As it was noted in the discussion thread, this feature might require a PEP. In this case I'm looking for a sponsor. Meanwhile, I'll make a draft pr, to not trigger review requests.
PEP draft: skirpichev/peps#4
Related issue: #113804
Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
https://discuss.python.org/t/41848
Linked PRs
The text was updated successfully, but these errors were encountered: