finding out the precision of floats

[Arnaud Delobelle]

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

[John Machin]

On Feb 25, 9:57 pm, "Arnaud Delobelle" <arno...@google mail.comwrote:

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')

I'm a little puzzled:

You don't seem to want a function that will tell you the actual number
of significant decimal digits in a particular number e.g.

nsig(12300.0) -3
nsig(0.00123400 ) -4
etc

You appear to be trying to determine what is the maximum number of
significant decimal digits afforded by the platform's implementation
of Python's float type. Is Python implemented on a platform that
*doesn't* use IEEE 754 64-bit FP as the in-memory format for floats?

Cheers,
John

[Arnaud Delobelle]

On Feb 25, 11:20 am, "John Machin" <sjmac...@lexic on.netwrote:
[...]

I'm a little puzzled:

You don't seem to want a function that will tell you the actual number
of significant decimal digits in a particular number e.g.

nsig(12300.0) -3
nsig(0.00123400 ) -4
etc

You appear to be trying to determine what is the maximum number of
significant decimal digits afforded by the platform's implementation
of Python's float type.

Yes you are correct.

Is Python implemented on a platform that
*doesn't* use IEEE 754 64-bit FP as the in-memory format for floats?

I had no knowledge of IEEE 754 64-bit FP. The python doc says that
floats are implemented using the C 'double' data type but I didn't
realise there was a standard for this accross platforms .

Thanks for clarifying this. As my question shows I am not versed in
floating point arithmetic!

Looking at the definition of IEEE 754, the mantissa is made of 53
significant binary digits, which means
53*log10(2) = 15.954589770191 003 significant decimal digits
(I got 16 with my previous dodgy calculation).

Does it mean it is safe to assume that this would hold on any
platform?

--
Arnaud

[John Machin]

On Feb 25, 11:06 pm, "Arnaud Delobelle" <arno...@google mail.com>
wrote:

On Feb 25, 11:20 am, "John Machin" <sjmac...@lexic on.netwrote:
[...]

I'm a little puzzled:

You don't seem to want a function that will tell you the actual number
of significant decimal digits in a particular number e.g.

nsig(12300.0) -3
nsig(0.00123400 ) -4
etc

You appear to be trying to determine what is the maximum number of
significant decimal digits afforded by the platform's implementation
of Python's float type.

Yes you are correct.

Is Python implemented on a platform that
*doesn't* use IEEE 754 64-bit FP as the in-memory format for floats?

I had no knowledge of IEEE 754 64-bit FP. The python doc says that
floats are implemented using the C 'double' data type but I didn't
realise there was a standard for this accross platforms .

Thanks for clarifying this. As my question shows I am not versed in
floating point arithmetic!

Looking at the definition of IEEE 754, the mantissa is made of 53
significant binary digits, which means
53*log10(2) = 15.954589770191 003 significant decimal digits
(I got 16 with my previous dodgy calculation).

Does it mean it is safe to assume that this would hold on any
platform?

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. 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.

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

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

[Arnaud Delobelle]

On Feb 25, 1:31 pm, "John Machin" <sjmac...@lexic on.netwrote:

On Feb 25, 11:06 pm, "Arnaud Delobelle" <arno...@google mail.com>
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

[Jerry Hill]

On 25 Feb 2007 06:11:02 -0800, Arnaud Delobelle <ar*****@google mail.comwrote:

Moreover the reason I got interested in this is because I am creating
a Dec class (decimal numbers)

Are you familiar with Python's Decimal library?
http://docs.python.org/lib/module-decimal.html

--
Jerry

[Arnaud Delobelle]

On Feb 25, 3:59 pm, "Jerry Hill" <malaclyp...@gm ail.comwrote:

On 25 Feb 2007 06:11:02 -0800, Arnaud Delobelle <arno...@google mail.comwrote:

Moreover the reason I got interested in this is because I am creating
a Dec class (decimal numbers)

Are you familiar with Python's Decimal library?http://docs.python.org/lib/module-decimal.html

Read on my post for a few more lines and you'll know that the answer
is yes :)

--
Arnaud

[Robert Kern]

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

[Robert Kern]

Dennis Lee Bieber wrote:

On 25 Feb 2007 05:31:11 -0800, "John Machin" <sj******@lexic on.net>
declaimed the following in comp.lang.pytho n:

>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. 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

[Facundo Batista]

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/