Infinity definitions
![](https://secure.gravatar.com/avatar/38d5ac232150013cbf1a4639538204c0.jpg?s=120&d=mm&r=g)
Hi, Since we are discussing namespace and standardization, I am curious in why there are multiple definitions for defining infinity in numpy when perhaps there should be two (one for positive infinity and one for negative infinity). I really do understand that other people have use of these definitions and that it is easier to leave them in than take them out. Also, it is minor reduction in namespace because I do know that much of the namespace is either defining variables (like different floats and complex numbers) or mathematical functions (like logs and trig functions). Currently we have: numpy.Inf numpy.Infinity numpy.inf numpy.infty numpy.NINF numpy.PINF Most of these are defined in numeric.py: 'Inf = inf = infty = Infinity = PINF' In the f2py/tests subdirectories, the files return_real.py and return_complex.py uses both 'inf','Infinity'. The only occurrence of NINF and PINF are in core/src/umathmodule.c but I don't see any other usage. There does not seem to be any use of 'infty'. A similar case could be made for 'Not a Number' (nan = NaN = NAN). Regards Bruce
![](https://secure.gravatar.com/avatar/ab7e74f2443b81e5175638d72be65e07.jpg?s=120&d=mm&r=g)
On 10/04/2008, Travis E. Oliphant <oliphant@enthought.com> wrote:
The others have some use if you want to be able to use the results of repr() as literals - as I understand it the output representation of a NaN depends on the C library, and users seeing, say, "NaN" might well expect to be able to type NaN (after from numpy import NaN) and get a NaN. Anne
![](https://secure.gravatar.com/avatar/38d5ac232150013cbf1a4639538204c0.jpg?s=120&d=mm&r=g)
Hi, Following Travis's suggestion below, I would like to suggest that the following definitions be depreciated or removed in this forthcoming release: numpy.Inf numpy.Infinity numpy.infty numpy.PINF numpy.NAN numpy.NaN I am not sure about what would be best for numpy.NINF. Thanks Bruce Travis E. Oliphant wrote:
![](https://secure.gravatar.com/avatar/547665790a071bb74c66ff10cc3a378a.jpg?s=120&d=mm&r=g)
On Tue, Jul 15, 2008 at 6:33 AM, Bruce Southey <bsouthey@gmail.com> wrote:
+1 on deprecating in the 1.2 release -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Jarrod Millman wrote:
Just to be clear, is the idea to remove the duplicate names, which will leave us with: numpy.nan numpy.inf What about: numpy.NINF should that be: numpy.ninf And is there a need for: numpy.pinf (or is that just redundant with numpy.inf) anyway, +1 for removing redundancies... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/d1189ce0778ab7465ef33b4883250d01.jpg?s=120&d=mm&r=g)
On 15 Jul 2008, at 6:33 AM, Bruce Southey wrote:
While this is being discussed, what about the "representation" of nan's an infinities produced by repr in various forms? It is particularly annoying when the repr of simple numeric types cannot be evaluated. These include: 'infj' == repr(complex(0,inf)) 'nanj' == repr(complex(0,nan)) 'infnanj' == repr(complex(inf,nan)) 'nannanj' == repr(complex(nan,nan)) It seems that perhaps infj and nanj should be defined symbols. I am not sure why a + does not get inserted before nan. In addition, the default infstr and nanstr printing options should also be changed to 'inf' and 'nan'. Michael.
![](https://secure.gravatar.com/avatar/afdaaab755ef79ac9e1374882d60ae9f.jpg?s=120&d=mm&r=g)
Hello all, If I recall correctly, one reason for the plethora of infinity definitions (which had been mentioned previously on the list) was that the repr for some or all float/complex types was generated by code in the host OS, and not in numpy. As such, these reprs were different for different platforms. As there was a desire to ensure that reprs could always be evaluated, the various ways that inf and nan could be spit out by the host libs were all included. Has this been fixed now, so that repr(inf), (etc.) looks identical on all platforms? Zach
![](https://secure.gravatar.com/avatar/ab7e74f2443b81e5175638d72be65e07.jpg?s=120&d=mm&r=g)
On 10/04/2008, Travis E. Oliphant <oliphant@enthought.com> wrote:
The others have some use if you want to be able to use the results of repr() as literals - as I understand it the output representation of a NaN depends on the C library, and users seeing, say, "NaN" might well expect to be able to type NaN (after from numpy import NaN) and get a NaN. Anne
![](https://secure.gravatar.com/avatar/38d5ac232150013cbf1a4639538204c0.jpg?s=120&d=mm&r=g)
Hi, Following Travis's suggestion below, I would like to suggest that the following definitions be depreciated or removed in this forthcoming release: numpy.Inf numpy.Infinity numpy.infty numpy.PINF numpy.NAN numpy.NaN I am not sure about what would be best for numpy.NINF. Thanks Bruce Travis E. Oliphant wrote:
![](https://secure.gravatar.com/avatar/547665790a071bb74c66ff10cc3a378a.jpg?s=120&d=mm&r=g)
On Tue, Jul 15, 2008 at 6:33 AM, Bruce Southey <bsouthey@gmail.com> wrote:
+1 on deprecating in the 1.2 release -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Jarrod Millman wrote:
Just to be clear, is the idea to remove the duplicate names, which will leave us with: numpy.nan numpy.inf What about: numpy.NINF should that be: numpy.ninf And is there a need for: numpy.pinf (or is that just redundant with numpy.inf) anyway, +1 for removing redundancies... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/d1189ce0778ab7465ef33b4883250d01.jpg?s=120&d=mm&r=g)
On 15 Jul 2008, at 6:33 AM, Bruce Southey wrote:
While this is being discussed, what about the "representation" of nan's an infinities produced by repr in various forms? It is particularly annoying when the repr of simple numeric types cannot be evaluated. These include: 'infj' == repr(complex(0,inf)) 'nanj' == repr(complex(0,nan)) 'infnanj' == repr(complex(inf,nan)) 'nannanj' == repr(complex(nan,nan)) It seems that perhaps infj and nanj should be defined symbols. I am not sure why a + does not get inserted before nan. In addition, the default infstr and nanstr printing options should also be changed to 'inf' and 'nan'. Michael.
![](https://secure.gravatar.com/avatar/afdaaab755ef79ac9e1374882d60ae9f.jpg?s=120&d=mm&r=g)
Hello all, If I recall correctly, one reason for the plethora of infinity definitions (which had been mentioned previously on the list) was that the repr for some or all float/complex types was generated by code in the host OS, and not in numpy. As such, these reprs were different for different platforms. As there was a desire to ensure that reprs could always be evaluated, the various ways that inf and nan could be spit out by the host libs were all included. Has this been fixed now, so that repr(inf), (etc.) looks identical on all platforms? Zach
participants (7)
-
Anne Archibald
-
Bruce Southey
-
Christopher Barker
-
Jarrod Millman
-
Michael McNeil Forbes
-
Travis E. Oliphant
-
Zachary Pincus