### Re: python 3.44 float addition bug?

On Thu, Jun 26, 2014 at 9:24 PM, Chris Angelico ros...@gmail.com wrote: But you're right that this can be very surprising. And it's inherent to the concept of digits having more range than just high or low, so there's no way you can get this with binary floats. For an average of two numbers, I think that's true. For an average of more than two numbers, it's possible. a = 2.0 ** 53 - 1 b = 2.0 ** 53 - 2 a 9007199254740991.0 b 9007199254740990.0 (a + b + b) / 3 9007199254740989.0 -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Thu, 26 Jun 2014 13:39:23 +1000, Ben Finney wrote: Steven D'Aprano st...@pearwood.info writes: On Wed, 25 Jun 2014 14:12:31 -0700, Maciej Dziardziel wrote: Floating points values use finite amount of memory, and cannot accurately represent infinite amount of numbers, they are only approximations. This is limitation of float type and applies to any languages that uses types supported directly by cpu. To deal with it you can either use decimal.Decimal type that operates using decimal system and saves you from such surprises That's a myth. decimal.Decimal *is* a floating point value That's misleading: Decimal uses *a* floating-point representation, but not the one commonly referred to. That is, Decimal does not use IEEE-754 floating point. You're technically correct, but only by accident. IEEE-754 covers both binary and decimal floating point numbers: http://en.wikipedia.org/wiki/IEEE_floating_point but Python's decimal module is based on IEEE-854, not 754. http://en.wikipedia.org/wiki/IEEE_854-1987 So you're right on a technicality, but wrong in the sense of knowing what you're talking about *wink* and is subject to *exactly* the same surprises as binary floats, Since those “surprises” are the ones inherent to *decimal*, not binary, floating point, I'd say it's also misleading to refer to them as “exactly the same surprises”. They're barely surprises at all, to someone raised on decimal notation. Not at all. They are surprises to people who are used to *mathematics*, fractions, rational numbers, the real numbers, etc. It is surprising that the rational number one third added together three times should fail to equal one. Ironically, binary float gets this one right: py 1/3 + 1/3 + 1/3 == 1 True py Decimal(1)/3 + Decimal(1)/3 + Decimal(1)/3 == 1 False but for other rationals, that is not necessarily the case. It is surprising when x*(y+z) fails to equal x*y + x*z, but that can occur with both binary floats and Decimals. It is surprising when (x + y) + z fails to equal x + (y + z), but that can occur with both binary floats and Decimals. It is surprising when x != 0 and y != 0 but x*y == 0, but that too can occur with both binary floats and Decimals. And likewise for most other properties of the rationals and reals, which people learn in school, or come to intuitively expect. People are surprised when floating-point arithmetic fails to obey the rules of mathematical arithmetic. If anyone is aware of a category of surprise which binary floats are prone to, but Decimal floats are not, apart from the decimal- representation issue I've already mentioned, I'd love to hear of it. But I doubt such a thing exists. Decimal in the Python standard library has another advantage, it supports user-configurable precisions. But that doesn't avoid any category of surprise, it just mitigates against being surprised as often. This makes the Decimal functionality starkly different from the built-in ‘float’ type, and it *does* save you from the rather-more-surprising behaviour of the ‘float’ type. This is not mythical. It simply is not true that Decimal avoids the floating point issues that What Every Computer Scientist Needs To Know About Floating Point warns about: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html It *cannot* avoid them, because Decimal is itself a floating point format, it is not an infinite precision number type like fractions.Fraction. Since Decimal cannot avoid these issues, all we can do is push the surprises around, and hope to have less of them, or shift them to parts of the calculation we don't care about. (Good luck with that.) Decimal, by default, uses 28 decimal digits of precision, about 11 or 12 more digits than Python floats are able to provide. So right away, by shifting to Decimal you gain precision and hence might expect fewer surprises, all else being equal. But all else isn't equal. The larger the base, the larger the wobble. See Goldberg above for the definition of wobble, but it's a bad thing. Binary floats have the smallest wobble, which is to their advantage. If you stick to trivial calculations using nothing but trivially neat decimal numbers, like 0.1, you may never notice that Decimal is subject to the same problems as float (only worse, in some ways -- Decimal calculations can fail in some spectacularly horrid ways that binary floats cannot). But as soon as you start doing arbitrary calculations, particularly if they involve divisions and square roots, things are no longer as neat and tidy. Here's an error that *cannot* occur with binary floats: the average of two numbers x and y is not guaranteed to lie between x and y! py from decimal import * py getcontext().prec = 3 py x = Decimal('0.516') py y = Decimal('0.518') py (x + y) / 2 Decimal('0.515') Ouch! -- Steven -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Thu, Jun 26, 2014 at 7:15 PM, Steven D'Aprano st...@pearwood.info wrote: Here's an error that *cannot* occur with binary floats: the average of two numbers x and y is not guaranteed to lie between x and y! py from decimal import * py getcontext().prec = 3 py x = Decimal('0.516') py y = Decimal('0.518') py (x + y) / 2 Decimal('0.515') Ouch! But what you're looking at is also a problem with intermediate rounding, as the sum of .516 and .518 can't be represented in 3 digits. One rule of thumb that I learned back in my earliest coding days was that your intermediate steps should have significantly more precision than your end result; so if you want an end result with a certain precision (say, 3 decimal digits), you should calculate with a bit more. Of course, a bit is nearly impossible to define [1], but if you're mostly adding and subtracting, or multiplying by smallish constants, 1-2 extra digits' worth of precision is generally enough. Or just give yourself lots of room, like using double-precision for something like the above example. Compare this: from decimal import * getcontext().prec = 4 x = Decimal('0.516') y = Decimal('0.519') avg = (x + y) / 2 getcontext().prec = 3 avg + 0 Decimal('0.518') (x + y) / 2 Decimal('0.52') Doing the intermediate calculation with precision 3 exhibits the same oddity Steven mentioned (only the other way around - result is too high), but having a little extra room in the middle means the result is as close to the correct answer as can be represented (0.517 would be equally correct). With floating point on an 80x87, you can do this with 80-bit FPU registers; I don't know of a way to do so with Python floats, but (obviously) it's pretty easy with Decimal. ChrisA [1] Thank you, smart-aleck up the back, I am fully aware that a bit is exactly one binary digit. That's not enough for a decimal float. You've made your point, now shut up. :) -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Thu, 26 Jun 2014 19:38:45 +1000, Chris Angelico wrote: On Thu, Jun 26, 2014 at 7:15 PM, Steven D'Aprano st...@pearwood.info wrote: Here's an error that *cannot* occur with binary floats: the average of two numbers x and y is not guaranteed to lie between x and y! py from decimal import * py getcontext().prec = 3 py x = Decimal('0.516') py y = Decimal('0.518') py (x + y) / 2 Decimal('0.515') Ouch! But what you're looking at is also a problem with intermediate rounding, as the sum of .516 and .518 can't be represented in 3 digits. Exactly. I picked 3 digits because it's much easier to write, and read, a 3 digit example than a 28 digit example. But the failure here is not a property of too few digits, to be fixed by adding more significant digits. No matter how many digits you have, there are some calculations which cannot be performed exactly in that many digits. Although you seem to have missed the critical issue: this is a failure mode which *binary floats cannot exhibit*, but decimal floats can. The failure being that assert x = (x+y)/2 = y may fail if x and y are base 10 floats. I'm afraid my computational-mathematics skills are not good enough to prove this assertion, but Mark Dickinson on the Python-Dev mailing list made this claim, and I believe he knows what he is talking about. https://mail.python.org/pipermail/python-ideas/2014-March/026851.html If anyone can demonstrate such a failed assertion using floats, I'd love to see it. -- Steven -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Fri, Jun 27, 2014 at 12:51 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Although you seem to have missed the critical issue: this is a failure mode which *binary floats cannot exhibit*, but decimal floats can. The failure being that assert x = (x+y)/2 = y may fail if x and y are base 10 floats. No, I didn't miss that; I said that what you were looking at was *also* caused by intermediate rounding. It happens because .516 + .518 = 1.034, which rounds to 1.03; half of that is .515, which is outside of your original range - but the intermediate rounding really reduced the effective precision to two digits, by discarding some of the information in the original. If you accept that your result is now accurate to only two digits of precision, then that result is within one ULP of correct (you'll record the average as either .51 or .52, and your two original inputs are both .52, and the average of .52 and .52 is clearly .52). But you're right that this can be very surprising. And it's inherent to the concept of digits having more range than just high or low, so there's no way you can get this with binary floats. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Saturday, June 21, 2014 1:57:19 AM UTC+1, FraserL wrote: I'm not hugely accustomed to Python, but this seems crazy to me. Floating points values use finite amount of memory, and cannot accurately represent infinite amount of numbers, they are only approximations. This is limitation of float type and applies to any languages that uses types supported directly by cpu. To deal with it you can either use decimal.Decimal type that operates using decimal system and saves you from such surprises (but it will be much slower and incompatible with c code that doesn't handle decimals or converts them to floats) or use epsilon for every comparison and rounding/formatting with limited precision for displaying. Few more details are here: http://floating-point-gui.de/errors/comparison/ -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Wed, 25 Jun 2014 14:12:31 -0700, Maciej Dziardziel wrote: Floating points values use finite amount of memory, and cannot accurately represent infinite amount of numbers, they are only approximations. This is limitation of float type and applies to any languages that uses types supported directly by cpu. To deal with it you can either use decimal.Decimal type that operates using decimal system and saves you from such surprises That's a myth. decimal.Decimal *is* a floating point value, and is subject to *exactly* the same surprises as binary floats, except for one: which Decimal, you can guarantee that any decimal string you enter will appear exactly the same (up to the limit of the current precision). For example: py x = Decimal(1)/Decimal(23) py x Decimal('0.04347826086956521739130434783') py x*23 == 1 True py sum( [x]*23 ) == 1 # Surprise! False py (Decimal(19)/Decimal(17))*Decimal(17) == 19 # Surprise! False -- Steven -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Thu, Jun 26, 2014 at 12:56 PM, Steven D'Aprano st...@pearwood.info wrote: That's a myth. decimal.Decimal *is* a floating point value, and is subject to *exactly* the same surprises as binary floats, except for one: which Decimal, you can guarantee that any decimal string you enter will appear exactly the same (up to the limit of the current precision). The important difference is that the issues with decimal floats come where humans are comfortable seeing them. If you divide 1 by 3, you get 0.3 and can understand that adding three of those together won't quite make 1.0, because you can see that you shortened it. If you divide 11 by 10, it's not obvious that that repeats. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

Steven D'Aprano st...@pearwood.info writes: On Wed, 25 Jun 2014 14:12:31 -0700, Maciej Dziardziel wrote: Floating points values use finite amount of memory, and cannot accurately represent infinite amount of numbers, they are only approximations. This is limitation of float type and applies to any languages that uses types supported directly by cpu. To deal with it you can either use decimal.Decimal type that operates using decimal system and saves you from such surprises That's a myth. decimal.Decimal *is* a floating point value That's misleading: Decimal uses *a* floating-point representation, but not the one commonly referred to. That is, Decimal does not use IEEE-754 floating point. and is subject to *exactly* the same surprises as binary floats, Since those “surprises” are the ones inherent to *decimal*, not binary, floating point, I'd say it's also misleading to refer to them as “exactly the same surprises”. They're barely surprises at all, to someone raised on decimal notation. This makes the Decimal functionality starkly different from the built-in ‘float’ type, and it *does* save you from the rather-more-surprising behaviour of the ‘float’ type. This is not mythical. -- \ “Guaranteed to work throughout its useful life.” —packaging for | `\ clockwork toy, Hong Kong | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Thu, 26 Jun 2014 13:13:45 +1000, Chris Angelico wrote: On Thu, Jun 26, 2014 at 12:56 PM, Steven D'Aprano st...@pearwood.info wrote: That's a myth. decimal.Decimal *is* a floating point value, and is subject to *exactly* the same surprises as binary floats, except for one: which Decimal, you can guarantee that any decimal string you enter will appear exactly the same (up to the limit of the current precision). The important difference is that the issues with decimal floats come where humans are comfortable seeing them. If you divide 1 by 3, you get 0.3 and can understand that adding three of those together won't quite make 1.0, because you can see that you shortened it. If you divide 11 by 10, it's not obvious that that repeats. I'm not sure if you're agreeing with me or disagreeing with me. Repeats is a property of a number *in a specific base*, not of the number itself. So 1/3 does not repeat in base 3, where it would be written as the terminating trinary number 0.1. Likewise, 11/10 repeats in base 2, but not in base 10. What I am I saying is that regardless of whether you use binary floats or base-10 Decimals, not all rational numbers x/y can be represented exactly. I certainly wasn't saying that the same rationals are inexact in both bases, just that the surprise x/y is not exact occurs whether you have binary or decimal floating point numbers. Likewise for all other floating point issues, except the surprise this base-2 float is not exactly equal to the base-10 number I typed. Because Decimal is base-10, what you type is what you get. -- Steven -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Thu, Jun 26, 2014 at 2:17 PM, Steven D'Aprano st...@pearwood.info wrote: I'm not sure if you're agreeing with me or disagreeing with me. Repeats is a property of a number *in a specific base*, not of the number itself. So 1/3 does not repeat in base 3, where it would be written as the terminating trinary number 0.1. Likewise, 11/10 repeats in base 2, but not in base 10. What I am I saying is that regardless of whether you use binary floats or base-10 Decimals, not all rational numbers x/y can be represented exactly. I certainly wasn't saying that the same rationals are inexact in both bases, just that the surprise x/y is not exact occurs whether you have binary or decimal floating point numbers. Likewise for all other floating point issues, except the surprise this base-2 float is not exactly equal to the base-10 number I typed. Because Decimal is base-10, what you type is what you get. Broadly agreeing, but with the caveat that, as you say, repeats depends on the base - and there's one base that most humans use, and it's not the base that IEEE floats use. So when I said that 11/10 repeats, I mean that it repeats in binary, which causes precision problems with binary floats; but everyone who's done basic work with vulgar and decimal fractions understands that 1/3 can't be perfectly represented in decimal. So the problems with floating point representations are indeed common to float and decimal.Decimal, but they're more surprising with float because humans aren't used to tenths repeating. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

Steven D'Aprano, 26.06.2014 04:56: On Wed, 25 Jun 2014 14:12:31 -0700, Maciej Dziardziel wrote: Floating points values use finite amount of memory, and cannot accurately represent infinite amount of numbers, they are only approximations. This is limitation of float type and applies to any languages that uses types supported directly by cpu. To deal with it you can either use decimal.Decimal type that operates using decimal system and saves you from such surprises That's a myth. decimal.Decimal *is* a floating point value, and is subject to *exactly* the same surprises as binary floats, except for one: which Decimal, you can guarantee that any decimal string you enter will appear exactly the same (up to the limit of the current precision). For example: py x = Decimal(1)/Decimal(23) py x Decimal('0.04347826086956521739130434783') py x*23 == 1 True py sum( [x]*23 ) == 1 # Surprise! False py (Decimal(19)/Decimal(17))*Decimal(17) == 19 # Surprise! False It seems that no-one has mentioned the fractions module in this thread yet. It gives you rational numbers (enumerator/denominator), as supposed to the limited real numbers that floating point numbers represent. https://docs.python.org/3/library/fractions.html There are quite a number of use cases for exact calculations where rational numbers beat any other solution. For the cases above, for example, you'd get exact results by design. Or in currency calculations, where you want to move the rounding to the very end and prevent any loss of precision along the way (unless you're trying to tweak your account in the right direction, that is). Stefan -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Mon, 23 Jun 2014 17:55:50 -0700, buck wrote: It used to be that the best way to compare floating point numbers while disregarding the inherent epsilon was to use `str(x) == str(y)`. It looks like that workaround doesn't work anymore in 3.4. What inherent epsilon? Can you explain what you mean? What's the recommended way to do this now? format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g') True That's equivalent to doing an implicit round. If all you want to do is round your calculations, then explicitly round them: py x = sum([0.01]*6) py y = 0.06 py round(x, 12) == round(y, 12) True Not that I'm recommending that you do it this way, but an explicit round is better than using string formatting. See also this: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

It used to be that the best way to compare floating point numbers while disregarding the inherent epsilon was to use `str(x) == str(y)`. It looks like that workaround doesn't work anymore in 3.4. What's the recommended way to do this now? format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g') True On Saturday, June 21, 2014 12:24:24 PM UTC-7, Ned Deily wrote: In article captjjmrkpd5k__h9qg12q+arafzvan6egudtmedge2ccaqe...@mail.gmail.com, Chris Angelico ros...@gmail.com wrote: Also, when you're looking at how things print out, consider looking at two things: the str() and the repr(). Sometimes just print(p) doesn't give you all the info, so you might instead want to write your loop thus: z = 0.01 p = 0.0 for i in range(19): p += z print(str(p) + -- + repr(p)) Sometimes you can get extra clues that way, although in this instance I think you won't. Actually, I think this is one case where you would get extra clues (or extra headscratching) if you run the code with various releases of Python. $ python2.6 b.py 0.01 -- 0.01 0.02 -- 0.02 0.03 -- 0.02 0.04 -- 0.040001 0.05 -- 0.050003 0.06 -- 0.060005 0.07 -- 0.070007 0.08 -- 0.080002 0.09 -- 0.089997 0.1 -- 0.02 0.11 -- 0.10999 0.12 -- 0.11998 0.13 -- 0.12998 0.14 -- 0.13999 0.15 -- 0.14999 0.16 -- 0.16 0.17 -- 0.17001 0.18 -- 0.18002 0.19 -- 0.19003 $ python2.7 b.py 0.01 -- 0.01 0.02 -- 0.02 0.03 -- 0.03 0.04 -- 0.04 0.05 -- 0.05 0.06 -- 0.060005 0.07 -- 0.07 0.08 -- 0.08 0.09 -- 0.09 0.1 -- 0.0 0.11 -- 0.10999 0.12 -- 0.11998 0.13 -- 0.12998 0.14 -- 0.13999 0.15 -- 0.15 0.16 -- 0.16 0.17 -- 0.17 0.18 -- 0.18002 0.19 -- 0.19003 $ python3.4 b.py 0.01 -- 0.01 0.02 -- 0.02 0.03 -- 0.03 0.04 -- 0.04 0.05 -- 0.05 0.060005 -- 0.060005 0.07 -- 0.07 0.08 -- 0.08 0.09 -- 0.09 0.0 -- 0.0 0.10999 -- 0.10999 0.11998 -- 0.11998 0.12998 -- 0.12998 0.13999 -- 0.13999 0.15 -- 0.15 0.16 -- 0.16 0.17 -- 0.17 0.18002 -- 0.18002 0.19003 -- 0.19003 What's going on here is that in Python 2.7 the repr() of floats was changed to use the minimum number of digits to accurately roundtrip the number under correct rounding. For compatibility reasons, the str() representation was not changed for 2.7. But in Python 3.2, str() was changed to be identical to repr() for floats. It's important to keep in mind that the actual binary values stored in float objects are the same across all of these releases; only the representation of them as decimal characters varies. https://docs.python.org/2.7/whatsnew/2.7.html#other-language-changes http://bugs.python.org/issue9337 -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Tue, Jun 24, 2014 at 10:55 AM, buck workithar...@gmail.com wrote: It used to be that the best way to compare floating point numbers while disregarding the inherent epsilon was to use `str(x) == str(y)`. Who said that? ChrisA -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

buck wrote: What's the recommended way to do this now? format(.01 + .01 + .01 + .01 + .01 + .01, 'g') == format(.06, 'g') There's no recommended way. What you're asking for can't be done. Whatever trick you come up with, there will be cases where it doesn't work. Why do you think you want to compare floats for equality? The best thing to do will depend on the answer to that. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On 2014-06-21, FraserL fraser.long+use...@nospamgmail.com wrote: I'm not hugely accustomed to Python, but this seems crazy to me. Both are producing the same floating point numbers, Python just changed the way they're printed. One version doesn't show you all the digits, the other does. -- Grant -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

In article captjjmrkpd5k__h9qg12q+arafzvan6egudtmedge2ccaqe...@mail.gmail.com, Chris Angelico ros...@gmail.com wrote: Also, when you're looking at how things print out, consider looking at two things: the str() and the repr(). Sometimes just print(p) doesn't give you all the info, so you might instead want to write your loop thus: z = 0.01 p = 0.0 for i in range(19): p += z print(str(p) + -- + repr(p)) Sometimes you can get extra clues that way, although in this instance I think you won't. Actually, I think this is one case where you would get extra clues (or extra headscratching) if you run the code with various releases of Python. $ python2.6 b.py 0.01 -- 0.01 0.02 -- 0.02 0.03 -- 0.02 0.04 -- 0.040001 0.05 -- 0.050003 0.06 -- 0.060005 0.07 -- 0.070007 0.08 -- 0.080002 0.09 -- 0.089997 0.1 -- 0.02 0.11 -- 0.10999 0.12 -- 0.11998 0.13 -- 0.12998 0.14 -- 0.13999 0.15 -- 0.14999 0.16 -- 0.16 0.17 -- 0.17001 0.18 -- 0.18002 0.19 -- 0.19003 $ python2.7 b.py 0.01 -- 0.01 0.02 -- 0.02 0.03 -- 0.03 0.04 -- 0.04 0.05 -- 0.05 0.06 -- 0.060005 0.07 -- 0.07 0.08 -- 0.08 0.09 -- 0.09 0.1 -- 0.0 0.11 -- 0.10999 0.12 -- 0.11998 0.13 -- 0.12998 0.14 -- 0.13999 0.15 -- 0.15 0.16 -- 0.16 0.17 -- 0.17 0.18 -- 0.18002 0.19 -- 0.19003 $ python3.4 b.py 0.01 -- 0.01 0.02 -- 0.02 0.03 -- 0.03 0.04 -- 0.04 0.05 -- 0.05 0.060005 -- 0.060005 0.07 -- 0.07 0.08 -- 0.08 0.09 -- 0.09 0.0 -- 0.0 0.10999 -- 0.10999 0.11998 -- 0.11998 0.12998 -- 0.12998 0.13999 -- 0.13999 0.15 -- 0.15 0.16 -- 0.16 0.17 -- 0.17 0.18002 -- 0.18002 0.19003 -- 0.19003 What's going on here is that in Python 2.7 the repr() of floats was changed to use the minimum number of digits to accurately roundtrip the number under correct rounding. For compatibility reasons, the str() representation was not changed for 2.7. But in Python 3.2, str() was changed to be identical to repr() for floats. It's important to keep in mind that the actual binary values stored in float objects are the same across all of these releases; only the representation of them as decimal characters varies. https://docs.python.org/2.7/whatsnew/2.7.html#other-language-changes http://bugs.python.org/issue9337 -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

Ok I've seen https://docs.python.org/2/tutorial/floatingpoint.html now thanks to Yhg1s on #python I bet you get this kind of thing a lot, sorry :-/ FraserL fraser.long+use...@nospamgmail.com wrote in news:XnsA35313E634BA0fraserlonggmailcom34@216.196.109.145: I think I found a strange bug in python 3.4.1, ... #test code z = 0.01 p = 0.0 for x, y in enumerate(range(1, 20)): p += z print(p) #end 3.4.1 output: ... 0.05 0.060005 0.07 ... I'm not hugely accustomed to Python, but this seems crazy to me. -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On 06/20/2014 05:57 PM, FraserL wrote: I think I found a strange bug in python 3.4.1, No, this is not a bug in Python. There is a limitation of floating point arithmetic in *all* languages, on *all* computers. Python 3 may be the first to let you see this limitation, but it's always been there. See https://docs.python.org/2/tutorial/floatingpoint.html for more details. Gary Herron fresh install of https://www.python.org/ftp/python/3.4.1/python-3.4.1.amd64.msi and a fresh install of https://www.python.org/ftp/python/2.7.7/python-2.7.7.amd64.msi to compare it to. #test code z = 0.01 p = 0.0 for x, y in enumerate(range(1, 20)): p += z print(p) #end 3.4.1 output: 0.01 0.02 0.03 0.04 0.05 0.060005 0.07 0.08 0.09 0.0 0.10999 0.11998 0.12998 0.13999 0.15 0.16 0.17 0.18002 0.19003 2.7.7 output: 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19 I'm not hugely accustomed to Python, but this seems crazy to me. -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On 06/20/2014 06:11 PM, FraserL wrote: Ok I've seen https://docs.python.org/2/tutorial/floatingpoint.html now thanks to Yhg1s on #python I bet you get this kind of thing a lot, sorry :-/ Yes, often, but it's not a problem. :-) FraserL fraser.long+use...@nospamgmail.com wrote in news:XnsA35313E634BA0fraserlonggmailcom34@216.196.109.145: I think I found a strange bug in python 3.4.1, ... #test code z = 0.01 p = 0.0 for x, y in enumerate(range(1, 20)): p += z print(p) #end 3.4.1 output: ... 0.05 0.060005 0.07 ... I'm not hugely accustomed to Python, but this seems crazy to me. -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

On Sat, Jun 21, 2014 at 10:57 AM, FraserL fraser.long+use...@nospamgmail.com wrote: #test code z = 0.01 p = 0.0 for x, y in enumerate(range(1, 20)): p += z print(p) #end General tip when you think you've found a bug: Cut out everything that isn't part of it. In this case, the enumerate has nothing to do with what you're seeing, which is an artifact of floating-point arithmetic, so a more classic loop header would simply be: for i in range(19): (Or some people will use _ to emphasize that the iterated-over values are being ignored.) The smaller you can make your test code, the more likely that people will be able to see what's going on. Also, when you're looking at how things print out, consider looking at two things: the str() and the repr(). Sometimes just print(p) doesn't give you all the info, so you might instead want to write your loop thus: z = 0.01 p = 0.0 for i in range(19): p += z print(str(p) + -- + repr(p)) Sometimes you can get extra clues that way, although in this instance I think you won't. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

### Re: python 3.44 float addition bug?

Read this: https://docs.python.org/3.4/tutorial/floatingpoint.html On Sat, Jun 21, 2014 at 9:57 AM, FraserL fraser.long+use...@nospamgmail.com wrote: I think I found a strange bug in python 3.4.1, fresh install of https://www.python.org/ftp/python/3.4.1/python-3.4.1.amd64.msi and a fresh install of https://www.python.org/ftp/python/2.7.7/python-2.7.7.amd64.msi to compare it to. #test code z = 0.01 p = 0.0 for x, y in enumerate(range(1, 20)): p += z print(p) #end 3.4.1 output: 0.01 0.02 0.03 0.04 0.05 0.060005 0.07 0.08 0.09 0.0 0.10999 0.11998 0.12998 0.13999 0.15 0.16 0.17 0.18002 0.19003 2.7.7 output: 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1 0.11 0.12 0.13 0.14 0.15 0.16 0.17 0.18 0.19 I'm not hugely accustomed to Python, but this seems crazy to me. -- https://mail.python.org/mailman/listinfo/python-list -- INADA Naoki songofaca...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list