472,958 Members | 2,393 Online

# Rappresenting infinite

I would like to have a useful rappresentation of infinite, is there

I was thinking to something like this

class Inf(int):
"""numero infinito"""
def __init__(self,negative=False):
self.negative = negative
def __cmp__(self,y):
"""infinito maggiore di qualasiasi cosa"""
if self.negative:
return -1
else:
return 1
def __repr__(self):
"""docstring for __repr__"""
if self.negative:
return '-inf'
else:
return 'inf'
return self
def __mul__(self,y):
"""moltiplicazione"""
import types
if isinstance(y,types.IntType):
if y 0:
return self
if y == 0:
return 'indefinito'
else:
return Inf(negative)
I'd like to be able to compare between any value and infinite always
getting the right result, and paying attention to the special cases
like
inf / inf =not determinate

Jun 27 '07 #1
12 1199
On Jun 27, 6:41 am, andrea <kerny...@gmail.comwrote:
I would like to have a useful rappresentation of infinite, is there
from numpy import inf

Jun 27 '07 #2
On Wed, 27 Jun 2007 11:59:29 -0000
Rob De Almeida <ra******@gmail.comwrote:
On Jun 27, 6:41 am, andrea <kerny...@gmail.comwrote:
I would like to have a useful rappresentation of infinite, is there

from numpy import inf
\$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>>from numpy import inf
inf == inf
True
>>type(inf)
<type 'float'>
This looks like the floating point inf to me. Does it differ from the
built-in inf?

I would like to second the OP's question if there is a generic inf and
add the wish that that is not equal to itself (inf == inf would yield
nan). Ideally, it would not be of type float and work with gmpy mpq.
But I might have rare requirements...

Martin
Jun 29 '07 #3
mm****@gmx.net wrote:
On Wed, 27 Jun 2007 11:59:29 -0000
Rob De Almeida <ra******@gmail.comwrote:
>On Jun 27, 6:41 am, andrea <kerny...@gmail.comwrote:
>>I would like to have a useful rappresentation of infinite, is there
from numpy import inf

\$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>>>from numpy import inf
inf == inf
True
>>>type(inf)
<type 'float'>
This looks like the floating point inf to me.
It is.
Does it differ from the
built-in inf?
What built-in inf?
I would like to second the OP's question if there is a generic inf and
add the wish that that is not equal to itself (inf == inf would yield
nan).
No. You can make one that fits your requirements, though.
Ideally, it would not be of type float and work with gmpy mpq.
But I might have rare requirements...
Possibly.

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

Jun 29 '07 #4
On Thu, 28 Jun 2007 23:20:30 -0500
Robert Kern <ro*********@gmail.comwrote:
mm****@gmx.net wrote:
Does it differ from the
built-in inf?

What built-in inf?
\$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>>a = 1.0e1000
b = 2.0e1000
a
inf
>>b
inf
>>a == b
True
>>type(a)
<type 'float'>
No. You can make one that fits your requirements, though.
I am struggling to oversee the implications of design choices for inf
behaviour - especially if it comes to comparison with float type inf.
The type in my application contains a gmpy.mpq and a float that is
always kept between -1 and 1 by adding to the mpq on each operation.
I am looking for a robust inf design for this type. (Note: mpq and
float inf do not compare).

Martin
Jun 29 '07 #5
mm****@gmx.net wrote:
On Thu, 28 Jun 2007 23:20:30 -0500
Robert Kern <ro*********@gmail.comwrote:
>mm****@gmx.net wrote:
>>Does it differ from the
built-in inf?
What built-in inf?

\$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>>>a = 1.0e1000
b = 2.0e1000
a
inf
>>>b
inf
>>>a == b
True
>>>type(a)
<type 'float'>
Okay, I thought you meant that there was an actual symbol 'inf' in the builtins
or in a module somewhere.
>No. You can make one that fits your requirements, though.

I am struggling to oversee the implications of design choices for inf
behaviour - especially if it comes to comparison with float type inf.
The type in my application contains a gmpy.mpq and a float that is
always kept between -1 and 1 by adding to the mpq on each operation.
I am looking for a robust inf design for this type. (Note: mpq and
float inf do not compare).
You probably won't find one. You'll have to write it yourself.

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

Jun 29 '07 #6
Robert Kern wrote:
mm****@gmx.net wrote:
>>On Thu, 28 Jun 2007 23:20:30 -0500
Robert Kern <ro*********@gmail.comwrote:

>>>mm****@gmx.net wrote:

Does it differ from the
built-in inf?

What built-in inf?

\$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>>>>>a = 1.0e1000
>b = 2.0e1000
>a

inf
>>>>>b

inf
>>>>>a == b

True
>>>>>type(a)

<type 'float'>

Okay, I thought you meant that there was an actual symbol 'inf' in the builtins
or in a module somewhere.

>>>No. You can make one that fits your requirements, though.
That sounds like a bug. If Python numerics don't define
+INF, -INF, and NaN, along with the tests for them, that's a
flaw in the language. We can assume IEEE floating point at this
late date; it's been standard for twenty years and Java assumes it.

John Nagle
Jun 29 '07 #7

"John Nagle" <na***@animats.comwrote in message
news:iF**************@newssvr13.news.prodigy.net.. .
| If Python numerics don't define
| +INF, -INF, and NaN, along with the tests for them, that's a
| flaw in the language.

Are you volunteering to fix the 'flaw'? CPython floating point numerics
are currently defined to be C doubles and whatever else the particular
compiler/hardware provides. But Tim Peters said at least 5 years ago that
a volunteer could try to improve portability. Various people have since
talked about doing something.

| We can assume IEEE floating point at this
| late date; it's been standard for twenty years and Java assumes it.

Not all processors running Python even have floats ;-)
In any case, the IEEE standard did not seem to define a standard C binding.
Neither did the C89 committee. So gcc and msc differ on how to spell such
things.
Not everyone is satisfied with the Java solution.

Jun 29 '07 #8
mm****@gmx.net wrote:

>No. You can make one that fits your requirements, though.

I am struggling to oversee the implications of design choices for inf
behaviour - especially if it comes to comparison with float type inf.
The type in my application contains a gmpy.mpq and a float that is
always kept between -1 and 1 by adding to the mpq on each operation.
I am looking for a robust inf design for this type. (Note: mpq and
float inf do not compare).
Infinity, and all its behaviours are well defined in the General Decimal
Arithmetic Specification, here at http://www2.hursley.ibm.com/decimal/.

You can always pass your float to Decimal through string, and then do
there *all* the operations:
>>from decimal import *
a = 3.4
b = 1.0e1000
Decimal(str(a))
Decimal("3.4")
>>Decimal(str(b))
Decimal("Infinity")
>>Decimal(str(b)) / 0
Decimal("Infinity")
>>Decimal(str(b)) * 0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/decimal.py", line 1140, in __mul__
return context._raise_error(InvalidOperation, '(+-)INF * 0')
File "/usr/lib/python2.5/decimal.py", line 2325, in _raise_error
raise error, explanation
decimal.InvalidOperation: (+-)INF * 0
>>setcontext(ExtendedContext)
Decimal(str(b)) * 0
Decimal("NaN")
>>>
Regards,

--
.. Facundo
..
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Jun 29 '07 #9
Mm very interesting thread, for my needs from numpy import inf is more
than enough :)
Jul 2 '07 #10
On Jun 27, 6:41 am, andrea <kerny...@gmail.comwrote:
I would like to have a useful rappresentation of infinite, is there

I was thinking to something like this

class Inf(int):
"""numero infinito"""
def __init__(self,negative=False):
self.negative = negative
def __cmp__(self,y):
"""infinito maggiore di qualasiasi cosa"""
if self.negative:
return -1
else:
return 1
def __repr__(self):
"""docstring for __repr__"""
if self.negative:
return '-inf'
else:
return 'inf'
return self
def __mul__(self,y):
"""moltiplicazione"""
import types
if isinstance(y,types.IntType):
if y 0:
return self
if y == 0:
return 'indefinito'
else:
return Inf(negative)

I'd like to be able to compare between any value and infinite always
getting the right result, and paying attention to the special cases
like
inf / inf =not determinate
float('inf') works well, no?
>>inf = float('inf')
inf / inf
nan
>>-inf
-inf
>>inf / 0
ZeroDivisionError: float division
>>1 / inf
0.0
>>0 * float('inf')
nan

Jul 2 '07 #11
av*********@gmail.com wrote:
float('inf') works well, no?
>>inf = float('inf')
>>inf / inf
nan
>>-inf
-inf
>>inf / 0
ZeroDivisionError: float division
>>1 / inf
0.0
>>0 * float('inf')
nan
It is not cross-platform. The parsing of strings into floats and the string
representation of floats is dependent on your system's C library. For these
special values, this differs across platforms. Your code won't work on Windows,
for example. Fortunately, it doesn't matter all that much (at least for those
who just need to create such values; parsing them from files is another matter)
since infs and nans can be constructed in a cross-platform way (at least for
IEEE-754 platforms where these values make sense).

inf = 1e200 * 1e200
nan = inf / inf

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

Jul 2 '07 #12
Robert Kern wrote:
av*********@gmail.com wrote:

>>float('inf') works well, no?
It is not cross-platform. The parsing of strings into floats and the string
representation of floats is dependent on your system's C library. For these
special values, this differs across platforms. Your code won't work on Windows,
for example.
Yes. This is CPython bug #1255395, status "open".
Also CPython bug #44585 (Pickle fails on "inf" values)

PEP 42 contains excuses for not calling it a bug.

John Nagle
Jul 3 '07 #13

This thread has been closed and replies have been disabled. Please start a new discussion.