458,127 Members | 1,160 Online Need help? Post your question and get tips & solutions from a community of 458,127 IT Pros & Developers. It's quick & easy.

# finding out the precision of floats

 P: n/a Hi all, I want to know the precision (number of significant digits) of a float in a platform-independent manner. I have scoured through the docs but I can't find anything about it! At the moment I use this terrible substitute: FLOAT_PREC = repr(1.0/3).count('3') How can I do this properly or where is relevant part of the docs? Thanks -- Arnaud Feb 25 '07 #1
23 Replies

 P: n/a On Feb 25, 9:57 pm, "Arnaud Delobelle"

 P: n/a On Feb 25, 11:20 am, "John Machin"

 P: n/a On Feb 25, 11:06 pm, "Arnaud Delobelle" wrote: On Feb 25, 11:20 am, "John Machin" >for n in range(200): | ... if (1.0 + 1.0/2**n) == 1.0: | ... print n, "bits" | ... break | ... | 53 bits At least this method has no dependency on the platform's C library. Note carefully the closing words of that tutorial section: """ (well, will display on any 754-conforming platform that does best- possible input and output conversions in its C library -- yours may not!). """ I hope some of this helps ... Cheers, John Feb 25 '07 #4

 P: n/a On Feb 25, 1:31 pm, "John Machin" wrote: [...] Evidently not; here's some documentation we both need(ed) to read: http://docs.python.org/tut/node16.html Thanks for this link I'm very curious to know what the exceptions were in November 2000 and if they still exist. There is also the question of how much it matters to you. Presuming the representation is 64 bits, even taking 3 bits off the mantissa and donating them to the exponent leaves you with 15.05 decimal digits -- perhaps you could assume that you've got at least 15 decimal digits. It matters to me because I prefer to avoid making assumptions in my code! Moreover the reason I got interested in this is because I am creating a Dec class (decimal numbers) and I would like that: * given a float x, float(Dec(x)) == x for as many values of x as possible * given a decimal d, Dec(float(d)) == d for as many values of d as possible. (and I don't want the standard Decimal class :) While we're waiting for the gurus to answer, here's a routine that's slightly less dodgy than yours: | >>for n in range(200): | ... if (1.0 + 1.0/2**n) == 1.0: | ... print n, "bits" | ... break | ... | 53 bits Yes I have a similar routine: |def fptest(): | "Gradually fill the mantissa of a float with 1s until running out of bits" | ix = 0 | fx = 0.0 | for i in range(200): | fx = 2*fx+1 | ix = 2*ix+1 | if ix != fx: | return i .... >>fptest() 53 I guess it would be OK to use this. It's just that this 'poking into floats' seems a bit strange to me ;) Thanks for your help -- Arnaud Feb 25 '07 #5

 P: n/a On 25 Feb 2007 06:11:02 -0800, Arnaud Delobelle

 P: n/a On Feb 25, 3:59 pm, "Jerry Hill"

 P: n/a John Machin wrote: Evidently not; here's some documentation we both need(ed) to read: http://docs.python.org/tut/node16.html """ Almost all machines today (November 2000) use IEEE-754 floating point arithmetic, and almost all platforms map Python floats to IEEE-754 "double precision". """ I'm very curious to know what the exceptions were in November 2000 and if they still exist. All Python interpreters use whatever is the C double type on its platform to represent floats. Not all of the platforms use *IEEE-754* floating point types. The most notable and still relevant example that I know of is Cray. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco Feb 25 '07 #8

 P: n/a Dennis Lee Bieber wrote: On 25 Feb 2007 05:31:11 -0800, "John Machin" declaimed the following in comp.lang.python: >Evidently not; here's some documentation we both need(ed) to read:http://docs.python.org/tut/node16.html"""Almost all machines today (November 2000) use IEEE-754 floating pointarithmetic, and almost all platforms map Python floats to IEEE-754"double precision"."""I'm very curious to know what the exceptions were in November 2000 andif they still exist. There is also the question of how much it matters Maybe a few old Vaxes/Alphas running OpenVMS... Those machines had something like four or five different floating point representations (F, D, G, and H, that I recall -- single, double, double with extended exponent range, and quad) I actually used Python on an Alpha running OpenVMS a few years ago. IIRC, the interpreter was built with IEEE floating point types rather than the other types. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco Feb 26 '07 #9

 P: n/a Arnaud Delobelle wrote: (and I don't want the standard Decimal class :) Why? -- .. Facundo .. Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Feb 27 '07 #10

 P: n/a On Feb 27, 1:36 pm, Facundo Batista >from timeit import Timert1 = Timer('(1.0/3.0)*3.0 - 1.0')t2 = Timer('(Decimal(1)/Decimal(3))*Decimal(3)-Decimal(1)', 'from decimal import Decimal') >>t2.timeit()/t1.timeit() 1621.7838879255889 If that's not enough to forget about Decimal, take a look at this: >>(Decimal(1)/Decimal(3))*Decimal(3) == Decimal(1) False >>((1.0/3.0)*3.0) == 1.0 True Feb 27 '07 #11

 P: n/a On 27 Feb, 14:09, "Bart Ogryczak" from timeit import Timert1 = Timer('(1.0/3.0)*3.0 - 1.0')t2 = Timer('(Decimal(1)/Decimal(3))*Decimal(3)-Decimal(1)', 'from decimal import Decimal')>>t2.timeit()/t1.timeit() 1621.7838879255889 Yes. The internal representation of a Decimal is a tuple of one-digit strings! This is one of the reasons (by no means the main) why I decided to write my own class. If that's not enough to forget about Decimal, take a look at this: >(Decimal(1)/Decimal(3))*Decimal(3) == Decimal(1) False >((1.0/3.0)*3.0) == 1.0 True OTOH float is not the panacea: >>0.1+0.1+0.1==0.3 False >>3*0.1==0.3 False Decimals will behave better in this case. Cheers -- Arnaud Feb 27 '07 #12

 P: n/a Why should you? It only gives you 28 significant digits, while 64-bit float (as in 32-bit version of Python) gives you 53 significant digits. Also note, that on x86 FPU uses 80-bit registers. An then Decimal executes over 1500 times slower. 64-bit floating point only gives you 53 binary bits, not 53 digits. That's approximately 16 decimal digits. And anyway, Decimal can be configured to support than 28 digits. > >from timeit import Timert1 = Timer('(1.0/3.0)*3.0 - 1.0')t2 = Timer('(Decimal(1)/Decimal(3))*Decimal(3)-Decimal(1)', 'from decimal import Decimal')>>t2.timeit()/t1.timeit() 1621.7838879255889 If that's not enough to forget about Decimal, take a look at this: >(Decimal(1)/Decimal(3))*Decimal(3) == Decimal(1) False >((1.0/3.0)*3.0) == 1.0 True Try ((15.0/11.0)*11.0) == 15.0. Decimal is actually returning the correct result. Your example was just lucky. Decimal was intended to solve a different class of problems. It provides predictable arithmetic using "decimal" floating point. IEEE-754 provides predictable arithmetic using "binary" floating point. casevh Feb 27 '07 #13

 P: n/a On Feb 27, 7:58 pm, "Arnaud Delobelle" >from timeit import Timer >>t1 = Timer('(1.0/3.0)*3.0 - 1.0') >>t2 = Timer('(Decimal(1)/Decimal(3))*Decimal(3)-Decimal(1)', 'from decimal import Decimal')>>t2.timeit()/t1.timeit() 1621.7838879255889 Yes. The internal representation of a Decimal is a tuple of one-digit strings! This is one of the reasons (by no means the main) why I decided to write my own class. Why not GMP? If that's not enough to forget about Decimal, take a look at this: >>(Decimal(1)/Decimal(3))*Decimal(3) == Decimal(1) False >>((1.0/3.0)*3.0) == 1.0 True OTOH float is not the panacea: My point is, that neither is Decimal. It doesn't solve the problem, creating additional problem with efficiency. >0.1+0.1+0.1==0.3 False >3*0.1==0.3 False Decimals will behave better in this case. Decimal will work fine as long as you deal only with decimal numbers and the most basic arithmetic. Any rational number with base that is not power of 10, or any irrational number won't have an exact representation. So as long as you're dealing with something like invoices, Decimal does just fine. When you start real calculations, not only scientific, but even financial ones, it doesn't do any better then binary float, and it's bloody slow.  eg. consider calculating interests rate, which often is defined as math.pow(anualRate,days/365.0). It's not rational number (unless days happen to be mutliple of 365), therefore has no exact representation. BTW, math.* functions do not return Decimals. Feb 28 '07 #14

 P: n/a On Feb 28, 10:38 pm, "Bart Ogryczak"

 P: n/a On Feb 28, 3:53 pm, "John Machin"

 P: n/a On 28 Feb, 11:38, "Bart Ogryczak" >0.1+0.1+0.1==0.3 False >>3*0.1==0.3 False Decimals will behave better in this case. Decimal will work fine as long as you deal only with decimal numbers and the most basic arithmetic. Any rational number with base that is not power of 10, or any irrational number won't have an exact representation. My problem is precisely to represent rational numbers whose denominator is a power of 10 (aka decimals) accurately. So as long as you're dealing with something like invoices, Decimal does just fine. When you start real calculations, not only scientific, but even financial ones, it doesn't do any better then binary float, and it's bloody slow. I'm not doing 'real world' calcultations, I'm making an app to help teach children maths. I need numerical values that behave well as decimals. I also need them to have an arbitrary number of significant figures. Floats are great but they won't help me with either. Amongst other things, I need 3.0*0.1==0.3 to be True. Please do not make the assumption that I have chosen to use a decimal type without some careful consideration. -- Arnaud Feb 28 '07 #17

 P: n/a On Feb 28, 6:34 pm, "Arnaud Delobelle"

 P: n/a Arnaud Delobelle wrote: I'm not doing 'real world' calcultations, I'm making an app to help teach children maths. I need numerical values that behave well as decimals. I also need them to have an arbitrary number of significant figures. Floats are great but they won't help me with either. Amongst other things, I need 3.0*0.1==0.3 to be True. I guess that speed is not at premium in your application, so you might try my continued fractions module, advertised here a few weeks ago: http://www-zo.iinf.polsl.gliwice.pl/...software/cf.py It represents rational numbers exactly, and irrational numbers with an arbitrary accuracy, i.e. unlike Decimal it implements exact rather than multiple-precision arithmetic. Once you create an expression, you can pull from it as many decimal digits as you wish. The subexpressions dynamically adjust their accuracy, so that you always get exact digits. Regards, Marcin Feb 28 '07 #19

 P: n/a On Feb 28, 7:28 pm, Marcin Ciura wrote: I guess that speed is not at premium in your application, so you might try my continued fractions module, advertised here a few weeks ago:http://www-zo.iinf.polsl.gliwice.pl/...software/cf.py Thanks for the link, I've had a quick glance and it seems great. I'll have to take a closer look to see if I can use it for this app, but in general it looks like a very useful piece of code. -- Arnaud Feb 28 '07 #20

 P: n/a On Mar 1, 4:19 am, "Bart Ogryczak"

 P: n/a On Feb 28, 10:29 pm, "John Machin"

 P: n/a On Mar 1, 9:33 pm, "Bart Ogryczak"

 P: n/a John Machin wrote: Storing 1.1 and using it in calculations may save you a few microseconds a day in your real-time apps. The main advantage would be clarity of code. naming 1.1 as "anualRate" (sic) is utterly ludicrous. So call it annualMultiplicationFactor or something in the code. -- Greg Mar 2 '07 #24

### This discussion thread is closed

Replies have been disabled for this discussion. 