On 9/4/06, Charles R Harris <charlesr.harris@gmail.com> wrote:

On 9/4/06, Sebastian Haase < haase@msg.ucsf.edu> wrote:
Paulo J. S. Silva wrote:
> Once again, the information that singed zero is part of IEEE standard is
> in the paper I cited in my last message.
>
> It is very important to be able to compute the sign of an overflowed
> quantity in expressions like 1/x when x goes to zero.
>
> Best,
>
> Paulo
Hi,

This is all very interesting ( and confusing (to me, maybe others) at
the same time ...) ...

Question 0: Are you sure this is not a bug ?
>>> N.array([66]).round(-1)
[60]

That does look like a bug.

>>> array([66]).round(-1)
array([60])
>>> array([66.]).round(-1)
array([ 70.])

I suspect it is related to the integer data type of the first example. The code probably does something like this:

round(66/10)*10

and 66/10 == 6 in integer arithmetic.

The problem is somewhere in this bit of code:

// f will be a double

f = PyFloat_FromDouble(power_of_ten(decimals));
if (f==NULL) return NULL;

// op1 will be division
ret = PyObject_CallFunction(op1, "OOO", a, f, out);
if (ret==NULL) goto finish;

// round in place.
tmp = PyObject_CallFunction(n_ops.rint, "OO", ret, ret);
if (tmp == NULL) {Py_DECREF(ret); ret=NULL; goto finish;}

I suspect the problem is the division, which has integer 'a', double 'f', and integer 'out'. Integer out is probably the killer. Let's see:

# use doubles for output
>>> out = zeros(1)
>>> array([66]).round(decimals=-1, out=out)
array([ 70.])

yep, that's the problem

Chuck.

<snip>