Re: Are Floating Point Numbers still a Can of Worms?

On Mon, 24 Oct 2022 14:52:28 +, "Schachner, Joseph (US)" declaimed the following: >Floating point will always be a can of worms, as long as people expect it to >represent real numbers with more precision that float has. Usually this is >not an issue, but sometimes it is. And, although

RE: Are Floating Point Numbers still a Can of Worms?

precision. --- Joseph S. Teledyne Confidential; Commercially Sensitive Business Data -Original Message- From: Pieter van Oostrum Sent: Sunday, October 23, 2022 10:25 AM To: python-list@python.org Subject: Re: Are Floating Point Numbers still a Can of Worms? Mostowski Collapse writes: >

Re: Are Floating Point Numbers still a Can of Worms?

Mostowski Collapse writes: > I also get: > > Python 3.11.0rc1 (main, Aug 8 2022, 11:30:54) 2.718281828459045**0.8618974796837966 > 2.367649 > > Nice try, but isn't this one the more correct? > > ?- X is 2.718281828459045**0.8618974796837966. > X = 2.36764897. > That's probably the

[issue210627] Floating point numbers (PR#277)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210627] Floating point numbers (PR#277)

Change by admin : -- github: None -> 32698 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Mark Dickinson added the comment: > Closing this as out of date. SGTM. Thanks. -- ___ Python tracker ___ ___ Python-bugs-list

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Zachary Ware added the comment: I no longer have access to ICC, and the ICC buildbots have been mothballed some years ago. Closing this as out of date; the issue might not be, but the information about it here probably is :) -- resolution: -> out of date stage: -> resolved

Re: on floating-point numbers

On 2021-09-11, Chris Angelico wrote: > Once you accept that "perfectly representable numbers" aren't > necessarily the ones you expect them to be, 64-bit floats become > adequate for a huge number of tasks. Even 32-bit floats are pretty > reliable for most tasks, although I suspect that there's

Re: on floating-point numbers

Yes. I had explained that earlier in this thread. > The perceived inaccuracy of floating point numbers comes from an > assumption that a string of decimal digits is exact, and the > computer's representation of it is not. If I put this in my code: > > ONE_THIRD = 0.3 > > then

Re: on floating-point numbers

t; precision with most additions. That's an oversimplification, though - numbers like 12345.03125 can be perfectly accurately represented, since the fractional part is a (negative) power of two. The perceived inaccuracy of floating point numbers comes from an assumption that a string of d

Re: on floating-point numbers

On 2021-09-05 23:21:14 -0400, Richard Damon wrote: > > On Sep 5, 2021, at 6:22 PM, Peter J. Holzer wrote: > > On 2021-09-04 10:01:23 -0400, Richard Damon wrote: > >>> On 9/4/21 9:40 AM, Hope Rouselle wrote: > >>> Hm, I think I see what you're saying. You're saying multiplication and > >>>

Re: on floating-point numbers

On 2021-09-05 22:32:51 -, Grant Edwards wrote: > On 2021-09-05, Peter J. Holzer wrote: [on the representability of fractional numbers as floating point numbers] > And once you understand that, ignore it and write code under the > assumumption that nothing can be exactly re

Re: on floating-point numbers

Joe Pfeiffer writes: > Hope Rouselle writes: >> Christian Gollwitzer writes: >>> >>> I believe it is not commutativity, but associativity, that is >>> violated. >> >> Shall we take this seriously? (I will disagree, but that doesn't mean I >> am not grateful for your post. Quite the

Re: on floating-point numbers

Hope Rouselle writes: > Christian Gollwitzer writes: >> >> I believe it is not commutativity, but associativity, that is >> violated. > > Shall we take this seriously? (I will disagree, but that doesn't mean I > am not grateful for your post. Quite the contary.) It in general > violates

Re: on floating-point numbers

Chris Angelico writes: > On Sun, Sep 5, 2021 at 1:04 PM Hope Rouselle wrote: >> The same question in other words --- what's a trivial way for the REPL >> to show me such cycles occur? >> >> >> 7.23.as_integer_ratio() >> >>> (2035064081618043, 281474976710656) >> >> Here's what I did on this

Re: on floating-point numbers

"Peter J. Holzer" writes: > On 2021-09-05 03:38:55 +1200, Greg Ewing wrote: >> If 7.23 were exactly representable, you would have got >> 723/1000. >> >> Contrast this with something that *is* exactly representable: >> >> >>> 7.875.as_integer_ratio() >> (63, 8) >> >> and observe that 7875/1000

Re: on floating-point numbers

On 2021-09-05, Peter J. Holzer wrote: > On 2021-09-05 03:38:55 +1200, Greg Ewing wrote: >> If 7.23 were exactly representable, you would have got >> 723/1000. >> >> Contrast this with something that *is* exactly representable: >> >> >>> 7.875.as_integer_ratio() >> (63, 8) >> >> and observe

Re: on floating-point numbers

On Sat, 04 Sep 2021 10:40:35 -0300, Hope Rouselle declaimed the following: >course, I don't even have floats to worry about.) If I'm given 1.17, >say, I am not confident that I could turn this number into 117 by >multiplying it by 100. And that was the question. Can I always >multiply such

Re: on floating-point numbers

> On Sep 5, 2021, at 6:22 PM, Peter J. Holzer wrote: > > On 2021-09-04 10:01:23 -0400, Richard Damon wrote: >>> On 9/4/21 9:40 AM, Hope Rouselle wrote: >>> Hm, I think I see what you're saying. You're saying multiplication and >>> division in IEEE 754 is perfectly safe --- so long as the

Re: on floating-point numbers

On 2021-09-04 10:01:23 -0400, Richard Damon wrote: > On 9/4/21 9:40 AM, Hope Rouselle wrote: > > Hm, I think I see what you're saying. You're saying multiplication and > > division in IEEE 754 is perfectly safe --- so long as the numbers you > > start with are accurately representable in IEEE 754

Re: on floating-point numbers

On 2021-09-05 03:38:55 +1200, Greg Ewing wrote: > If 7.23 were exactly representable, you would have got > 723/1000. > > Contrast this with something that *is* exactly representable: > > >>> 7.875.as_integer_ratio() > (63, 8) > > and observe that 7875/1000 == 63/8: > > >>> from fractions

Re: on floating-point numbers

On 2021-09-04 09:48:40 -0300, Hope Rouselle wrote: > Christian Gollwitzer writes: > > Am 02.09.21 um 15:51 schrieb Hope Rouselle: > > ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77] > > sum(ls) > >> 39.594 > >> > > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23] > > sum(ls) > >>

Re: on floating-point numbers

On Sun, Sep 5, 2021 at 12:58 PM Greg Ewing wrote: > > On 5/09/21 2:42 am, Hope Rouselle wrote: > > Here's what I did on this case. The REPL is telling me that > > > >7.23 = 2035064081618043/281474976710656 > > If 7.23 were exactly representable, you would have got > 723/1000. > > Contrast

Re: on floating-point numbers

On Sun, Sep 5, 2021 at 12:55 PM Hope Rouselle wrote: > > Julio Di Egidio writes: > > > On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote: > >> Am 02.09.21 um 16:49 schrieb Julio Di Egidio: > >> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote: > >>

Re: on floating-point numbers

On Sun, Sep 5, 2021 at 12:44 PM Hope Rouselle wrote: > > Chris Angelico writes: > > > On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote: > >> > >> Just sharing a case of floating-point numbers. Nothing needed to be > >> solved or to be f

Re: on floating-point numbers

On Sun, Sep 5, 2021 at 1:04 PM Hope Rouselle wrote: > The same question in other words --- what's a trivial way for the REPL > to show me such cycles occur? > > >> 7.23.as_integer_ratio() > >>> (2035064081618043, 281474976710656) > > Here's what I did on this case. The REPL is telling me

Re: on floating-point numbers

On Sun, Sep 5, 2021 at 12:50 PM Hope Rouselle wrote: > > Christian Gollwitzer writes: > > > Am 02.09.21 um 15:51 schrieb Hope Rouselle: > >> Just sharing a case of floating-point numbers. Nothing needed to be > >> solved or to be figured ou

Re: on floating-point numbers

On Sun, Sep 5, 2021 at 12:48 PM Hope Rouselle wrote: > > Chris Angelico writes: > > > On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote: > >> > >> Hope Rouselle writes: > >> > >> > Just sharing a case of floating-point numbers. Nothing

Re: on floating-point numbers

Am 04.09.21 um 14:48 schrieb Hope Rouselle: Christian Gollwitzer writes: Am 02.09.21 um 15:51 schrieb Hope Rouselle: Just sharing a case of floating-point numbers. Nothing needed to be solved or to be figured out. Just bringing up conversation. (*) An introduction to me I don't understand

Re: on floating-point numbers

Christian Gollwitzer writes: > Am 04.09.21 um 14:48 schrieb Hope Rouselle: >> Christian Gollwitzer writes: >> >>> Am 02.09.21 um 15:51 schrieb Hope Rouselle: >>>> Just sharing a case of floating-point numbers. Nothing needed to be >>>>

Re: on floating-point numbers

Julio Di Egidio writes: [...] >> I, too, lost my patience there. :-) > > As if I didn't know who's trolling... I never trolled you. When we had our conversations in sci.logic, I was Boris Dorestand --- you would remember if you have very good memory. We talked for just a few days, I guess.

Re: on floating-point numbers

Hope Rouselle writes: > Greg Ewing writes: > >> On 5/09/21 2:42 am, Hope Rouselle wrote: >>> Here's what I did on this case. The REPL is telling me that >>>7.23 = 2035064081618043/281474976710656 >> >> If 7.23 were exactly representable, you would have got >> 723/1000. >> >> Contrast this

Re: on floating-point numbers

Richard Damon writes: > On 9/4/21 9:40 AM, Hope Rouselle wrote: >> Chris Angelico writes: >> >>> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote: >>>> >>>> Hope Rouselle writes: >>>> >>>>> Just sharing a case of

Re: on floating-point numbers

Greg Ewing writes: > On 5/09/21 2:42 am, Hope Rouselle wrote: >> Here's what I did on this case. The REPL is telling me that >>7.23 = 2035064081618043/281474976710656 > > If 7.23 were exactly representable, you would have got > 723/1000. > > Contrast this with something that *is* exactly

Re: on floating-point numbers

Julio Di Egidio writes: > On Thursday, 2 September 2021 at 15:52:02 UTC+2, Hope Rouselle wrote: > >> I don't understand floating-point numbers from the inside out, but I do >> know how to work with base 2 and scientific notation. So the idea of >> expressing a number as

Re: on floating-point numbers

On 5/09/21 2:42 am, Hope Rouselle wrote: Here's what I did on this case. The REPL is telling me that 7.23 = 2035064081618043/281474976710656 If 7.23 were exactly representable, you would have got 723/1000. Contrast this with something that *is* exactly representable: >>>

Re: on floating-point numbers

Julio Di Egidio writes: > On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote: >> Am 02.09.21 um 16:49 schrieb Julio Di Egidio: >> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote: >> >> On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote: >> >

Re: on floating-point numbers

On 9/4/21 9:40 AM, Hope Rouselle wrote: > Chris Angelico writes: > >> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote: >>> >>> Hope Rouselle writes: >>> >>>> Just sharing a case of floating-point numbers. Nothing needed to be >>>&

Re: on floating-point numbers

Christian Gollwitzer writes: > Am 02.09.21 um 15:51 schrieb Hope Rouselle: >> Just sharing a case of floating-point numbers. Nothing needed to be >> solved or to be figured out. Just bringing up conversation. >> (*) An introduction to me >> I don't understand

Re: on floating-point numbers

Chris Angelico writes: > On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote: >> >> Hope Rouselle writes: >> >> > Just sharing a case of floating-point numbers. Nothing needed to be >> > solved or to be figured out. Just bringing up conversati

Re: on floating-point numbers

Chris Angelico writes: > On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote: >> >> Just sharing a case of floating-point numbers. Nothing needed to be >> solved or to be figured out. Just bringing up conversation. >> >> (*) An introduction to me >> >&

Re: on floating-point numbers

On 3/09/21 8:11 pm, Christian Gollwitzer wrote: Unless you have special numbers like NaN or signed zeros etc., a+b=b+a and a*b=b*a holds also for floats. The only exception I'm aware of is for NaNs, and it's kind of pendantic: you can't say that x + NaN == NaN + x, but only because NaNs never

Re: on floating-point numbers

Il 03/09/2021 14:45, Chris Angelico ha scritto: I believe the definition of "accurate" here is that, if you take all of the real numbers represented by those floats, add them all together with mathematical accuracy, and then take the nearest representable float, that will be the exact value that

Re: on floating-point numbers

On Thu, 2 Sep 2021 07:54:27 -0700 (PDT), Julio Di Egidio wrote: > On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote: >> Am 02.09.21 um 16:49 schrieb Julio Di Egidio: >> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote: >> >> On Thu, 02 Sep 2021

RE: on floating-point numbers

er 2, 2021 9:51 AM To: python-list@python.org Subject: on floating-point numbers Just sharing a case of floating-point numbers. Nothing needed to be solved or to be figured out. Just bringing up conversation. (*) An introduction to me I don't understand floating-point numbers from the inside out,

RE: on floating-point numbers

Message- From: Hope Rouselle Sent: Thursday, September 2, 2021 9:51 AM To: python-list@python.org Subject: on floating-point numbers Just sharing a case of floating-point numbers. Nothing needed to be solved or to be figured out. Just bringing up conversation. (*) An introduction to me I

Re: on floating-point numbers

On 2021-09-03 16:13, Chris Angelico wrote: On Sat, Sep 4, 2021 at 12:08 AM o1bigtenor wrote: Hmmm - - - ZI would suggest that you haven't looked into taxation yet! In taxation you get a rational number that MUST be multiplied by the amount in currency. (You can, of course, multiply a

Re: on floating-point numbers

On Sat, Sep 4, 2021 at 12:08 AM o1bigtenor wrote: > Hmmm - - - ZI would suggest that you haven't looked into > taxation yet! > In taxation you get a rational number that MUST be multiplied by > the amount in currency. (You can, of course, multiply a currency amount by any scalar. Just not by

Re: on floating-point numbers

On Thu, Sep 2, 2021 at 2:27 PM Chris Angelico wrote: > On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote: > > > > Hope Rouselle writes: > > > > > Just sharing a case of floating-point numbers. Nothing needed to be > > > solved or to be figu

Re: on floating-point numbers

On Fri, 3 Sept 2021 at 13:48, Chris Angelico wrote: > > On Fri, Sep 3, 2021 at 10:42 PM jak wrote: > > > > Il 03/09/2021 09:07, Julio Di Egidio ha scritto: > > > On Friday, 3 September 2021 at 01:22:28 UTC+2, Chris Angelico wrote: > > >> On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber > > >>

Re: on floating-point numbers

On Fri, Sep 3, 2021 at 10:42 PM jak wrote: > > Il 03/09/2021 09:07, Julio Di Egidio ha scritto: > > On Friday, 3 September 2021 at 01:22:28 UTC+2, Chris Angelico wrote: > >> On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber > >> wrote: > >>> On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico >

Re: on floating-point numbers

Il 03/09/2021 09:07, Julio Di Egidio ha scritto: On Friday, 3 September 2021 at 01:22:28 UTC+2, Chris Angelico wrote: On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber wrote: On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico declaimed the following: The naive summation algorithm used by

Re: on floating-point numbers

Am 02.09.21 um 21:02 schrieb Julio Di Egidio: On Thursday, 2 September 2021 at 20:43:36 UTC+2, Chris Angelico wrote: On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote: All I did was to take the first number, 7.23, and move it to the last position in the list. (So we have a violation of the

Re: on floating-point numbers

Op 2/09/2021 om 17:08 schreef Hope Rouselle: ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77] sum(ls) > 39.594 > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23] sum(ls) > 39.61 > > All I did was to take the first number, 7.23, and move it to the last > position in

Re: on floating-point numbers

On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber wrote: > > On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico > declaimed the following: > > > > >The naive summation algorithm used by sum() is compatible with a > >variety of different data types - even lists, although it's documented > >as being

Re: on floating-point numbers

On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico declaimed the following: > >The naive summation algorithm used by sum() is compatible with a >variety of different data types - even lists, although it's documented >as being intended for numbers - but if you know for sure that you're >working

Re: on floating-point numbers

g with more resolution internally). Money should never be treated as a floating value. >I suppose that if I multiply it by a power of two, that would be an >operation that I can be sure will not bring about any precision loss >with floating-point numbers. Do you agree? Are

Re: on floating-point numbers

On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle declaimed the following: ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77] sum(ls) >39.594 > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23] sum(ls) >39.61 > >All I did was to take the first number, 7.23, and move

Re: on floating-point numbers

On 2021-09-02, Hope Rouselle wrote: > Suppose these numbers are prices in dollar, never going beyond cents. > Would it be safe to multiply each one of them by 100 and therefore work > with cents only? The _practical_ answer is that no, it's not safe to use floating point when doing normal

Re: on floating-point numbers

On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote: > > Hope Rouselle writes: > > > Just sharing a case of floating-point numbers. Nothing needed to be > > solved or to be figured out. Just bringing up conversation. > > > > (*) An introduction to me > >

Re: on floating-point numbers

On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote: > > Just sharing a case of floating-point numbers. Nothing needed to be > solved or to be figured out. Just bringing up conversation. > > (*) An introduction to me > > I don't understand floating-point numbers from the

Re: on floating-point numbers

Hope Rouselle writes: > Just sharing a case of floating-point numbers. Nothing needed to be > solved or to be figured out. Just bringing up conversation. > > (*) An introduction to me > > I don't understand floating-point numbers from the inside out, but I do > know ho

Re: on floating-point numbers

Am 02.09.21 um 15:51 schrieb Hope Rouselle: Just sharing a case of floating-point numbers. Nothing needed to be solved or to be figured out. Just bringing up conversation. (*) An introduction to me I don't understand floating-point numbers from the inside out, but I do know how to work

Re: on floating-point numbers

Am 02.09.21 um 16:49 schrieb Julio Di Egidio: On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote: On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote: 39.61 Welcome to the exciting world of roundoff error: Welcome to the exiting world of Usenet. *Plonk*

Re: on floating-point numbers

On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote: > import sys sys.version > '3.8.10 (tags/... > ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77] sum(ls) > 39.594 > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23] sum(ls) > 39.61 Welcome to the

on floating-point numbers

Just sharing a case of floating-point numbers. Nothing needed to be solved or to be figured out. Just bringing up conversation. (*) An introduction to me I don't understand floating-point numbers from the inside out, but I do know how to work with base 2 and scientific notation. So the idea

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Change by STINNER Victor : -- pull_requests: -10796 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Change by STINNER Victor : -- pull_requests: -10794 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Change by STINNER Victor : -- pull_requests: -10795 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Raymond Hettinger added the comment: I had thought that use a locales were deemed an anti-pattern (not easy-to-use, not thread-safe, etc). -- nosy: +rhettinger ___ Python tracker

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Change by Raymond Hettinger : -- versions: +Python 3.9 -Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Change by Karl Ove Hufthammer : -- nosy: +huftis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35638] Introduce fixed point locale aware format type for floating point numbers

STINNER Victor added the comment: > By the way, the decimal module doesn't support properly the following corner > case: LC_NUMERIC using an encoding different than LC_CTYPE encoding. I wrote > https://github.com/python/cpython/pull/5191 but I abandonned my change. FYI I opened bpo-35697 to

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Łukasz Stelmach added the comment: I'd appreciate, if we continued the discussion at python-ideas, where I posted the idea[1]. There has already been several valuable comments. [1] https://mail.python.org/pipermail/python-ideas/2019-January/054793.html --

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Stefan Krah added the comment: > Since it seems like we are still at the "idea" stage, would it make sense to > add a function which accept options to choose how to format a number? Maybe, but I think for format() Eric's latest proposal on python-ideas is great ("*f" for "f + LC_NUMERIC",

[issue35638] Introduce fixed point locale aware format type for floating point numbers

STINNER Victor added the comment: Łukasz Stelmach: > It is currently impossible to format floating point numbers with an arbitrary > number of decimal digits AND the decimal point matching locale settings. I would like to warn you that handling properly locales can be very tricky. I

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Łukasz Stelmach added the comment: Indeed. Thank you. I was sure I had tried this. However, this is still only a workaround and not the solution I need. I am working on a project now which uses pint https://pint.readthedocs.io/en/latest/ which uses format() and its relatives. With "n"

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Serhiy Storchaka added the comment: You can use locale.format_string() for locale aware formatting. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Stefan Krah added the comment: For reference, the (one of the?) other GitHub issue(s) is here: https://github.com/python/cpython/pull/8612 It actually proposes to use LC_MONETARY. -- ___ Python tracker

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Łukasz Stelmach added the comment: As much as I am open to any suggestions for naming and such (although I think 'm' together with 'n' are a good supplement for 'f' and 'g'), I really would like to introduce a method to format numbers with fixed number of decimal digits (it looks good in

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Stefan Krah added the comment: I think there's another open GitHub issue for this, and yes, probably it should be discussed on python-ideas, too. My main concern with 'm' for libmpdec is that I'd like to reserve it for LC_MONETARY. There was one OS X issue that would have been solved by

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Łukasz Stelmach added the comment: > I haven't looked at this closely yet, but you'll need to at least: > - add tests that the locale-aware formatting is happening Done. > - support decimal > - make sure it works with complex Good points. Done. Please note, that there is an inconsistency

[issue35638] Introduce fixed point locale aware format type for floating point numbers

this through python-ideas first. One thing I expect to come up there: why f and not g? Again, I haven't looked through the code yet, or really even given any thought to determining if this is a sound idea. -- title: Introduce fixed point locale awear format type for floating point numbers

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35638] Introduce fixed point locale awear format type for floating point numbers

steelman added the comment: I have created a new format "m" that is for "n", what "f" is for "g". The patch for string.rst says +-+--+ | ``'m'`` | Number. This is the same as ``'f'``, except that it uses | | |

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Change by Roundup Robot : -- keywords: +patch, patch, patch, patch pull_requests: +10793, 10794, 10795, 10796 stage: -> patch review ___ Python tracker ___

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Change by Roundup Robot : -- keywords: +patch, patch, patch pull_requests: +10793, 10794, 10796 stage: -> patch review ___ Python tracker ___

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Change by Roundup Robot : -- keywords: +patch, patch pull_requests: +10793, 10794 stage: -> patch review ___ Python tracker ___

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Change by Roundup Robot : -- keywords: +patch pull_requests: +10793 stage: -> patch review ___ Python tracker ___ ___

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Eric V. Smith added the comment: Of course, feel free to create a PR. But the correct place to discuss any new behavior is on the issue tracker, or maybe on python-ideas, not in a PR. -- ___ Python tracker

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Eric V. Smith added the comment: Before a patch is created, we should discuss the behavior that will be implemented and agree on it. What is your suggestion? -- ___ Python tracker

[issue35638] Introduce fixed point locale awear format type for floating point numbers

steelman added the comment: I've got the patch. I will push it to github as soon as I can (some technical issues). -- ___ Python tracker ___

[issue35638] Introduce fixed point locale awear format type for floating point numbers

Eric V. Smith added the comment: Since this is a new feature, it can only be added to 3.8. Adjusting versions accordingly. I suggest that if we add this at all, it only be added to __format__, not to %-formatting. Any suggestions on a specification for this? -- components:

[issue35638] Introduce fixed point locale awear format type for floating point numbers

New submission from steelman : It is currently impossible to format floating point numbers with an arbitrary number of decimal digits AND the decimal point matching locale settings. For example no current format allows to display numbers ranging from 1 to 1000 with exactly two decimal digits

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Zachary Ware added the comment: I closed this prematurely: I successfully added /fp:strict to ICC builds, but it didn't fix the underlying issue. -- resolution: fixed -> stage: resolved -> status: closed -> open ___ Python tracker

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Zachary Ware added the comment: With the buildbots not angry over this, I'm closing the issue. I opened #26262 to follow the possibility of changing the initializers to allow /fp:strict with MSVC. -- assignee: -> zach.ware resolution: -> fixed stage: -> resolved status: open ->

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Roundup Robot added the comment: New changeset 296fb7c10a7d by Zachary Ware in branch '2.7': Issue #25934: Default to /fp:strict for ICC builds https://hg.python.org/cpython/rev/296fb7c10a7d New changeset 747b415e96c4 by Zachary Ware in branch '3.5': Issue #25934: Default to /fp:strict for ICC

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Zachary Ware added the comment: Here's a patch that specifies /fp:strict if it looks like ICC is being used for the build. It also adds a convenient property for checking whether it's an ICC build ($(ICCBuild)). This doesn't change anything for MSVC builds but allows ICC builds to pass

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Mark Dickinson added the comment: The dtoa.c occurrence is also straightforward to fix. It's coming from this declaration: static const double tinytens[] = { 1e-16, 1e-32, 1e-64, 1e-128, 9007199254740992.*9007199254740992.e-256}; We need to be a tiny bit careful

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

Zachary Ware added the comment: Ah, it's been a while since I tested that, so my reporting was inaccurate. The problem is actually that the compile fails: ..\Modules\mathmodule.c(1924): error C2099: initializer is not a constant [C:\cpython\PCbuild\pythoncore.vcxproj]

  1   2   >