Rappresenting infinite

[andrea]

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

[Rob De Almeida]

On Jun 27, 6:41 am, andrea <[e-mail]:

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 <[e-mail]:

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.1-21)] 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
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

[Robert Kern]

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 <[e-mail]:

>>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.1-21)] 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
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

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

[Robert Kern]

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

[John Nagle]

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

[Terry Reedy]

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

[Facundo Batista]

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/

[andrea]

Mm very interesting thread, for my needs from numpy import inf is more
than enough :)

[avassalotti]

On Jun 27, 6:41 am, andrea <[e-mail]:

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

[Robert Kern]

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

[John Nagle]

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