I would like to have a useful rappresentation of infinite, is there
already something??
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'
def __add__(self,y):
"""addizione con infinito"""
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 12 1156
On Jun 27, 6:41 am, andrea <kerny...@gmail.comwrote:
I would like to have a useful rappresentation of infinite, is there
already something??
from numpy import inf
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
already something??
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.121)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>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
builtin 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 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 already something??
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.121)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>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
builtin inf?
What builtin 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
On Thu, 28 Jun 2007 23:20:30 0500
Robert Kern <ro*********@gmail.comwrote: mm****@gmx.net wrote:
Does it differ from the
builtin inf?
What builtin inf?
$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.121)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>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 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 builtin inf?
What builtin inf?
$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.121)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>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
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 builtin inf?
What builtin inf?
$ python Python 2.4.4 (#2, Apr 5 2007, 20:11:18) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.121)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
>>>>>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
"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. 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/
Mm very interesting thread, for my needs from numpy import inf is more
than enough :)
On Jun 27, 6:41 am, andrea <kerny...@gmail.comwrote:
I would like to have a useful rappresentation of infinite, is there
already something??
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'
def __add__(self,y):
"""addizione con infinito"""
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 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 crossplatform. 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 crossplatform way (at least for
IEEE754 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
Robert Kern wrote:
av*********@gmail.com wrote:
>>float('inf') works well, no?
It is not crossplatform. 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 This discussion thread is closed Replies have been disabled for this discussion. Similar topics
43 posts
views
Thread by Gremlin 
last post: by

5 posts
views
Thread by mailpitches 
last post: by

44 posts
views
Thread by James Watt 
last post: by

10 posts
views
Thread by bhipwell via AccessMonster.com 
last post: by
          