Robert Kern wrote:

On Thu, Aug 28, 2008 at 02:48, Stef Mientki <s.mientki@ru.nl> wrote:

...

Thanks, so it works for arrays, but not for normal integers:

...

...

...

3/0 Traceback (most recent call last): File "<interactive input>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero

Right. Python integers and floats explicitly check for this case and raise the error. numpy objects, either arrays or numpy scalar types, have a configurable mechanism. If you want scalars that work like this:

In [1]: from numpy import *

In [2]: float64(1.0) / 0.0 Out[2]: inf

In [5]: seterr(divide='raise') Out[5]: {'divide': 'ignore', 'invalid': 'ignore', 'over': 'ignore', 'under': 'ignore'}

In [6]: float64(1.0) / 0.0 --------------------------------------------------------------------------- FloatingPointError Traceback (most recent call last)

/Users/rkern/Downloads/Video/avy/<ipython console> in <module>()

FloatingPointError: divide by zero encountered in double_scalars

In [7]: seterr(divide='warn') Out[7]: {'divide': 'raise', 'invalid': 'ignore', 'over': 'ignore', 'under': 'ignore'}

In [8]: float64(1.0) / 0.0 /usr/local/bin/ipython:1: RuntimeWarning: divide by zero encountered in double_scalars #!/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python Out[8]: inf

In [9]: seterr(divide='print') Out[9]: {'divide': 'warn', 'invalid': 'ignore', 'over': 'ignore', 'under': 'ignore'}

In [10]: float64(1.0) / 0.0 Warning: divide by zero encountered in double_scalars Out[10]: inf

In [12]: seterr(divide='ignore') Out[12]: {'divide': 'print', 'invalid': 'ignore', 'over': 'ignore', 'under': 'ignore'}

In [13]: float64(1.0) / 0.0 Out[13]: inf

In [14]: seterr? Type: function Base Class: <type 'function'> String Form: <function seterr at 0x18e8e30> Namespace: Interactive File: /Users/rkern/svn/numpy/numpy/core/numeric.py Definition: seterr(all=None, divide=None, over=None, under=None, invalid=None) Docstring: Set how floating-point errors are handled.

Valid values for each type of error are the strings "ignore", "warn", "raise", and "call". Returns the old settings. If 'all' is specified, values that are not otherwise specified will be set to 'all', otherwise they will retain their old values.

Note that operations on integer scalar types (such as int16) are handled like floating point, and are affected by these settings.

Example:

>>> seterr(over='raise') # doctest: +SKIP {'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under': 'ignore'}

>>> seterr(all='warn', over='raise') # doctest: +SKIP {'over': 'raise', 'divide': 'ignore', 'invalid': 'ignore', 'under': 'ignore'}

>>> int16(32000) * int16(3) # doctest: +SKIP Traceback (most recent call last): File "<stdin>", line 1, in ? FloatingPointError: overflow encountered in short_scalars >>> seterr(all='ignore') # doctest: +SKIP {'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under': 'ignore'}

In Python (probably system and version dependent) you can generate infinity as float('inf'). You are overlooking the basic definition of infinity (http://en.wikipedia.org/wiki/Infinity) and numerical representation of numbers in computer science especially integer versus floating point. In computer science integers refer to a finite range ( http://en.wikipedia.org/wiki/Integer_(computer_science) ) which is contrary to the meaning of infinity. Technically the same argument holds true for floating point number, but, fortunately there is the IEEE Standard for Binary Floating-Point for Arithmetic (IEEE 754 see for example, http://en.wikipedia.org/wiki/IEEE_754) that NumPy supports. This standard allows for representations of 'special' floating point values (such as positive infinity, negative infinity and Not a Number) and, more importantly, operations involving these values. Using integers:

...

...

numpy.ones(10, dtype=numpy.int) array([1, 1, 1, 1, 1, 1, 1, 1, 1, 1]) numpy.ones(10, dtype=numpy.int)/0 array([0, 0, 0, 0, 0, 0, 0, 0, 0, 0]) type((numpy.ones(10, dtype=numpy.int)/0)[0]) <type 'numpy.int64'>

Compared to using floats (the default of dtype of numpy.ones, for example, http://sd-2116.dedibox.fr/pydocweb/doc/numpy.matlib.ones/ ):

...

...

numpy.ones(10, dtype=numpy.float)/0 array([ Inf, Inf, Inf, Inf, Inf, Inf, Inf, Inf, Inf, Inf]) type((numpy.ones(10, dtype=numpy.float)/0)[0]) <type 'numpy.float64'>

Bruce

Thu, 28 Aug 2008 09:56:36 +0200, Stef Mientki wrote:

another observation:

...

...

...

a=numpy.array([2,3]) a/0 array([0, 0])

Division in Numpy preserves the data types: in this case you have an integer array divided by an integer, so the output is also an integer. But Inf is not one of integers so something must be substituted; and it is zero. There probably was some reason for this choice... If you change your seterr configuration frmo divide='ignore' you should get a warning, see http://mentat.za.net/numpy/refguide/routines.math.xhtml#numpy.divide -- Pauli Virtanen

Stef Mientki wrote:

thank you all for the explanations.

I'm a practical engineer, who almost never divide by zero. But the question came from my son, familiar with python and a little with scipy. After his first lesson in MatLab, he said: Oh what a beautiful environment is MatLab, it's even capable to divide by zero without errors. So for the moment probably MatLab is better suited for educational purposes.

NO!!!

I'll ask him again to compare scipy and Matlab, after a few weeks ;-)

The fundamental difference here is that Matlab operates using double precision numbers for *everything* by default. I personally consider that a design flaw. Numpy is being smart and letting you use integers if that's what you give it. So this isn't some limitation of numpy, it's just a slight difference of "opinion" between the packages. Numpy is capable of the same behavior with just one of two minor tweaks to the example:

...

...

a = np.array([2., 3.]) #Note the decimal points, this makes floats a/0 array([ Inf, Inf])

-or-

...

...

a = np.array([2, 3], dtype=np.float32) #Explicitly ask for floats a/0 array([ Inf, Inf], dtype=float32)

Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma