Infinity definitions
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
Bruce Southey wrote:
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'.
I think this is a product of bringing together a few definitions into one and not forcing a standard. numpy.inf numpy.nan should be used except for backward compatibility. -Travis
On 10/04/2008, Travis E. Oliphant <oliphant@enthought.com> wrote:
Bruce Southey wrote:
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'.
I think this is a product of bringing together a few definitions into one and not forcing a standard.
numpy.inf numpy.nan
should be used except for backward compatibility.
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
Travis E. Oliphant wrote:
Bruce Southey wrote:
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'.
I think this is a product of bringing together a few definitions into one and not forcing a standard.
numpy.inf numpy.nan
should be used except for backward compatibility.
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Hi, Thanks, Do you want me to file a ticket or something since it be nice to remove the extra definitions? Bruce
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:
Bruce Southey wrote:
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'.
I think this is a product of bringing together a few definitions into one and not forcing a standard.
numpy.inf numpy.nan
should be used except for backward compatibility.
-Travis
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jul 15, 2008 at 6:33 AM, Bruce Southey <bsouthey@gmail.com> wrote:
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
+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/
Jarrod Millman wrote:
On Tue, Jul 15, 2008 at 6:33 AM, Bruce Southey <bsouthey@gmail.com> wrote:
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
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
Christopher Barker wrote:
Jarrod Millman wrote:
On Tue, Jul 15, 2008 at 6:33 AM, Bruce Southey <bsouthey@gmail.com> wrote:
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
Just to be clear, is the idea to remove the duplicate names, which will leave us with:
numpy.nan numpy.inf
Yes, that is my goal.
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)
In numeric.py these are defined as equal: 'Inf = inf = infty = Infinity = PINF' So, yes, these are redundant with using only numpy.inf.
anyway, +1 for removing redundancies...
-Chris
Bruce
On 15 Jul 2008, at 6:33 AM, Bruce Southey wrote:
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 ...
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.
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 ...
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'.
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