The smallest and largest values of numeric types

[tom]

Hi!
How can I determine the smallest and largest values of numeric types
(for example int) possible in my system? I think there exists a function
for this task but I don't know it.

[Lou Pecora]

In article <QA************ **@read3.inet.f i>, to*@finland.com wrote:

Hi!
How can I determine the smallest and largest values of numeric types
(for example int) possible in my system? I think there exists a function
for this task but I don't know it.

There is or was a module called "kinds" which was an implementation of
PEP 0242. I have it and it gives the values you are looking for (and
more). But I don't know where I got it. I think it was once
distributed with Macpython on MacPython.org, but I'm not sure. I've
searched for it, but nothing shows up except my own questions about it
from many years ago and they have no clues.

Does anyone know where this package is? Or what might replace it. It
is very useful.

[Robert Kern]

Lou Pecora wrote:

In article <QA************ **@read3.inet.f i>, to*@finland.com wrote:

>Hi!
How can I determine the smallest and largest values of numeric types
(for example int) possible in my system? I think there exists a function
for this task but I don't know it.

There is or was a module called "kinds" which was an implementation of
PEP 0242. I have it and it gives the values you are looking for (and
more). But I don't know where I got it. I think it was once
distributed with Macpython on MacPython.org, but I'm not sure. I've
searched for it, but nothing shows up except my own questions about it
from many years ago and they have no clues.

I'm surprised they also didn't turn up my replies to those questions.

Does anyone know where this package is? Or what might replace it. It
is very useful.

It used to be distributed with Numeric.

http://numpy.cvs.sourceforge.net/numpy/kinds/

numpy exposes the same information for floating point types with its finfo
class. Nothing particular for ints.

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

[fumanchu]

On Apr 17, 7:12 am, [e-mail] m wrote:

How can I determine the smallest and largest values
of numeric types (for example int) possible in my
system? I think there exists a function for this task
but I don't know it.

This should work for ints:

import sys
print sys.maxint
For floats, just try until it fails. This is from
http://projects.amor.org/geniusql/br...dapters.py#l41

# Determine max binary digits for float on this system. Crude but
effective.
maxfloat_digits = 2
while True:
L = (2 ** (maxfloat_digit s + 1)) - 1
if int(float(L)) != L:
break
maxfloat_digits += 1

Note this will get you the number of binary digits, which is not a
simple matter to translate to maximum and minimum values, since floats
are inexact numerics. IEEE 754 floats are stored with one bit for the
sign, some bits for the exponent (which is biased) and some for the
significand. See http://babbage.cs.qc.edu/IEEE-754/32bit.html for a
visual example of how it works.
Robert Brewer
System Architect
Amor Ministries
fu******@amor.o rg

[tom]

Thank you for your answers. Seems like the limits of numeric values
aren't considered as important in Python as in C ;)

[Michael Hoffman]

fumanchu wrote:

On Apr 17, 7:12 am, [e-mail] m wrote:

>How can I determine the smallest and largest values
of numeric types (for example int) possible in my
system? I think there exists a function for this task
but I don't know it.

This should work for ints:

import sys
print sys.maxint

One should note that ints bigger than sys.maxint are possible almost
seamlessly since Python will use longs for these numbers:

Python 2.5 (r25:51908, Mar 13 2007, 08:13:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright" , "credits" or "license" for more information.

>>import sys
sys.maxint

2147483647

>>sys.maxint+ 1

2147483648L

>>sys.maxint* 2

4294967294L

>>sys.maxint**1 0

208592483005316 931156432119130 593119974171156 068820005046395 057804716416933 772965076580224 2049L

Of course performance decreases for longer longs.
--
Michael Hoffman

[mensanator]

On Apr 17, 11:37 am, [e-mail] m wrote:

Thank you for your answers. Seems like the limits of numeric values
aren't considered as important in Python as in C ;)

Sure, they're important, we just don't want to notice them. That's why
conversion to longs is automatic, so that number size limits don't
cause problems and your problems are solved rather than throw
exceptions or produce invalid results.

[Hendrik van Rooyen]

"Michael Hoffman" <ca*******@mh39 1.invalidwrote:

>

208592483005316 931156432119130 593119974171156 068820005046395 057804716416933 77296
50765802242049L

>
Of course performance decreases for longer longs.

I once made a thing that tried to find the limit of longs and stopped
when I had two or three screenfulls of numbers.

I came to the conclusion that for "integer" arithmetic like this,
the limit is either your memory size, or some other number
that is so big that in practice you don't have to worry about it..

- Hendrik

[Steven D'Aprano]

On Wed, 18 Apr 2007 07:15:11 +0200, Hendrik van Rooyen wrote:

I once made a thing that tried to find the limit of longs and stopped
when I had two or three screenfulls of numbers.

You should find that converting longs to strings (say, for printing them)
is *very* slow. E.g. the following code

big = 10L**100 # one google, a big number
while True:
print big # so we can see the last value before it fails
big *= 10

will run terribly slow and should be written as:

big = 10L**100 # one google, a big number
try:
while True:
big *= 10
except: # don't know what exception will be raised, so catch ANYTHING
print len(str(big))-1 # the number of digits

only does the slow conversion to string once, instead of every time around
the loop. However, once your machine starts paging, it will still slow
down a lot.

I came to the conclusion that for "integer" arithmetic like this, the
limit is either your memory size, or some other number that is so big
that in practice you don't have to worry about it..

Yes, longs are limited only by the amount of memory accessible.
--
Steven D'Aprano

[mensanator]

On Apr 18, 3:09�am, Steven D'Aprano <s...@REMOVEME. cybersource.com .au>
wrote:

On Wed, 18 Apr 2007 07:15:11 +0200, Hendrik van Rooyen wrote:

I once made a thing that tried to find the limit of longs and stopped
when I had two or three screenfulls of numbers.

You should find that converting longs to strings (say, for printing them)
is *very* slow. E.g. the following code

big = 10L**100 # one google, a big number
while True:
* * print big # so we can see the last value before it fails
* * big *= 10

will run terribly slow and should be written as:

big = 10L**100 # one google, a big number
try:
* * while True:
* * * * big *= 10
except: # don't know what exception will be raised, so catch ANYTHING
* * print len(str(big))-1 # the number of digits

only does the slow conversion to string once, instead of every time around
the loop. However, once your machine starts paging, it will still slow
down a lot.

I came to the conclusion that for "integer" arithmetic like this, the
limit is either your memory size, or some other number that is so big
that in practice you don't have to worry about it..

Yes, longs are limited only by the amount of memory accessible.

But there may be other limitations even if you have the memory.

For example, this test is limited to generation 10
because tne 11th generation produces "outrageous
exponent" error. Here, every 9th 1st generation,
starting from the fifth is a second generation, every
9th sencond, starting from the fifth, is a 3rd generation,
every 9th 3rd gen, starting from the 5th is a 4th gen, etc.

Closed form: Type12MH(k,i)
Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)/2+1)-1)-1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7
2**14348909-1 generation: 8
2**129140165-1 generation: 9
2**1162261469-1 generation:10

1.797 seconds

There is never a number too large to worry about.

>
--
Steven D'Aprano