Re: Strange behaviour with numbers in exponential notation
Am 04.09.16 um 10:29 schrieb Nobody: On Fri, 02 Sep 2016 18:18:08 +0200, Christian Gollwitzer wrote: 1e26 denotes a *floating point number* Floating point has finite precision, in CPython it is a 64bit IEEE number. The largest exact integer there is 2**53 (~10^16), everything beyond cannot be accurately represented. Uh, that's wrong. All integers smaller than 2**53 can be represented exactly. Some, but not all, of the integers above 2**53 can be represented exactly. Agreed. That's what I wanted to say. Of course you can represent 2**327 exactly in 64 bit binary floating point. The point is, that you can't sensibly assumy to get exact integer results for numbers beyond 2**53 - except for special cases. For example, 133 * 2**53 is exactly representable in FP, but 2**53+1 is not. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
On Fri, 02 Sep 2016 18:18:08 +0200, Christian Gollwitzer wrote: > 1e26 denotes a *floating point number* Floating point has finite > precision, in CPython it is a 64bit IEEE number. The largest exact > integer there is 2**53 (~10^16), everything beyond cannot be accurately > represented. Uh, that's wrong. All integers smaller than 2**53 can be represented exactly. Some, but not all, of the integers above 2**53 can be represented exactly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
Am 03.09.16 um 02:31 schrieb Marco Sulla: On 2 September 2016 at 21:12, Christian Gollwitzer wrote: Am 02.09.16 um 19:24 schrieb Marco Sulla: Because Python has no long double type? Python no of course, but C++ yes, and CPython is written in C++. However, I think the answer is here: https://en.wikipedia.org/wiki/Long_double#Implementations Briefly, long double is not implemented in all hardwares, or its implementation is really different from machine to machine. Yes - 64 bit IEEE floats are today the universally available floating point data type across different machines. If you want arbitrary precision floats, you can have them in Python, too: https://pypi.python.org/pypi/bigfloat/ Of course this is a "software emulation" and is consequently slower then hardware floats. It does not, howver take away the principle problem that you must set the precision from the beginning of your calculation. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
On 3 September 2016 at 02:31, Marco Sulla wrote: > Python no of course, but C++ yes, and CPython is written in C++. Sorry, I just founded CppPython... -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
On 2 September 2016 at 21:12, Christian Gollwitzer wrote: > Am 02.09.16 um 19:24 schrieb Marco Sulla: > Because Python has no long double type? Python no of course, but C++ yes, and CPython is written in C++. However, I think the answer is here: https://en.wikipedia.org/wiki/Long_double#Implementations Briefly, long double is not implemented in all hardwares, or its implementation is really different from machine to machine. I suppose this is why long double is not supported. -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
On 2016-09-02 20:47, Random832 wrote: On Fri, Sep 2, 2016, at 15:12, Christian Gollwitzer wrote: Tradition? All languages I know of treat a number with an exponent as floating point. Scheme does allow you to give integers (and rationals) in decimal and/or exponential notation with the "#e" prefix. In Ada, integers can have an exponent, provided that it's non-negative. -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
On Fri, Sep 2, 2016, at 15:12, Christian Gollwitzer wrote: > Tradition? All languages I know of treat a number with an exponent as > floating point. Scheme does allow you to give integers (and rationals) in decimal and/or exponential notation with the "#e" prefix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
Christian Gollwitzer : > Am 02.09.16 um 19:24 schrieb Marco Sulla: >> float has an 'exponentfloat' syntax. Why integers does not have an >> equivalent syntax? > > Tradition? All languages I know of treat a number with an exponent as > floating point. Approximate real numbers are mostly needed by scientific applications, and floats do the job marvelously. Unlike many programming languages, Python has adopted big integers, which have immediate applications in cryptography. Those big integers hardly ever involve powers of ten, however, and they cannot be approximated. So the scientific notation doesn't offer any notational advantage. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
Am 02.09.16 um 19:24 schrieb Marco Sulla: Excuse me, I forgot to include the python list mail addess. I repost the mail. On Fri, Sep 2, 2016 at 6:18 PM, Christian Gollwitzer wrote: 1e26 denotes a *floating point number* Floating point has finite precision, in CPython it is a 64bit IEEE number. The largest exact integer there is 2**53 (~10^16), everything beyond cannot be accurately represented. I see. So python float type is the IEEE 754 double. Why is it not automatically converted to long double? Because Python has no long double type? And "long double" (assuming 80bit or 128bit) does not solve the problem, it just shifts the bound to some higher arbitrary limit. In fact, it is impossible to make a bigfloat class which acts like a float, but always carries enough bits. A simple counterexample is 0.3, a periodic fraction in binary. Or, if you include arbitrary precision fractions, then e.g. sqrt(2). And I want to add to my original question: indeed I read from the docs: https://docs.python.org/3/reference/lexical_analysis.html#floating-point-literals that float has an 'exponentfloat' syntax. Why integers does not have an equivalent syntax? Tradition? All languages I know of treat a number with an exponent as floating point. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
On Fri, Sep 2, 2016, at 13:02, Marco Sulla wrote:
> On Fri, Sep 2, 2016 at 6:17 PM, Random832 wrote:
> > Trying to add 1 gets it rounded off again, and the value is simply
> > printed as 1e+26 by default because this is the shortest representation
> > that gives the same number, even if "14764729344.0"
> > would be more accurate.
>
> It seems it's not simply a representation. It seems the numbers are just
> equal:
Yes. The number 1e+16 is represented as a floating point number
equal to 14764729344. Then when you add 1 to it, the
1 gets rounded off and you get a floating point number that is still
equal to 14764729344:
>>> a = float(10**16)
>>> int(a)
14764729344
>>> b = a + 1
>>> int(b)
14764729344
You switched examples. 10**22 is the largest power of 10 that can be
represented exactly, but 10**15+1 is te largest "power of 10 plus
one" that can be represented exactly.
Float can only represent numbers whose binary representation
contains 53 bits or less from the first to the last "1".
>>> '{:b}'.format(10**15)
'1110001101011010100100110001101000'
# 35 bits before the run of zeros
>>> '{:b}'.format(10**16)
'1000111110001001101101'
# 38 bits, works fine in float
>>> '{:b}'.format(10**15+1)
'1110001101011010100100110001101001'
# 50 bits, barely fits in a float
>>> '{:b}'.format(10**16+1)
'10001111100010011011010001'
# 54 bits, too many.
Anything else gets rounded off. It's the same as if you tried to add
a tiny number to 1.
>>> 1+1e-15 == 1
False
>>> 1+1e-16 == 1
True
> This is really weird. I tried to do it just in C:
You should be using double instead of long double; double is the
C equivalent of the Python float type.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
Excuse me, I forgot to include the python list mail addess. I repost the mail. On Fri, Sep 2, 2016 at 6:18 PM, Christian Gollwitzer wrote: > 1e26 denotes a *floating point number* Floating point has finite precision, > in CPython it is a 64bit IEEE number. The largest exact integer there is > 2**53 (~10^16), everything beyond cannot be accurately represented. I see. So python float type is the IEEE 754 double. Why is it not automatically converted to long double? And I want to add to my original question: indeed I read from the docs: https://docs.python.org/3/reference/lexical_analysis.html#floating-point-literals that float has an 'exponentfloat' syntax. Why integers does not have an equivalent syntax? It's not too difficult to lexically distinguish between a integer and a float written in exponential notation, I think. -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
Am 02.09.16 um 17:51 schrieb Marco Sulla: 10**26 - 1 99 1e26 - 1 1e+26 10**26 is computed with integer arithmetics. Python has bigints (i.e. as big as the memory allows) 1e26 denotes a *floating point number* Floating point has finite precision, in CPython it is a 64bit IEEE number. The largest exact integer there is 2**53 (~10^16), everything beyond cannot be accurately represented. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Strange behaviour with numbers in exponential notation
On Fri, Sep 2, 2016, at 11:51, Marco Sulla wrote: > >>> 10**26 - 1 > 99 > >>> 1e26 - 1 > 1e+26 > > > Why? Exponential notation creates floating point numbers, which have a limited amount of precision in binary. Specifically (on my system which, as most modern computers do, use IEEE double precision numbers for the python float type), 0x52b7d2dcc80cd4 is the value of 1e26, whereas. 0x52b7d2dcc80cd2e400 is the valoe of 10**26. Trying to add 1 gets it rounded off again, and the value is simply printed as 1e+26 by default because this is the shortest representation that gives the same number, even if "14764729344.0" would be more accurate. -- https://mail.python.org/mailman/listinfo/python-list
Strange behaviour with numbers in exponential notation
>>> 10**26 - 1 99 >>> 1e26 - 1 1e+26 Why? -- https://mail.python.org/mailman/listinfo/python-list
