shunwang / numexpr

Automatically exported from code.google.com/p/numexpr
MIT License
0 stars 0 forks source link

incorrect usage of inetger division #70

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. a = np.array([2,4])
2. print ne.evaluate('a ** -2')

Expected: [ 0.25    0.0625]
Actual result: [0 0]

This is related to issue 59.

The fix should be to change the
   ConstantNode(1)
to
   ConstantNode(1.)
in expression.py.   There are two occurrences, for different optimization 
levels.

Original issue reported on code.google.com by ka...@ucw.cz on 24 Jan 2012 at 1:54

GoogleCodeExporter commented 9 years ago
Try to print a array. It has an integer type.
The solution is to specify the type of the array like this

a = np.array([2,4], dtype='float')
print a
print ne.evaluate('a ** -2')

Original comment by nok.raven@gmail.com on 27 Jan 2012 at 9:00

GoogleCodeExporter commented 9 years ago
Yes, I was aware of this workaround.  Yet the above behavior is a defect; 
compare it with plain python

print 2 ** -2
-> 0.25

Original comment by ka...@ucw.cz on 27 Jan 2012 at 9:43

GoogleCodeExporter commented 9 years ago
Our goal is to mimick *numpy* semantics as close as possible, not plain Python. 
And in this particular example, numexpr has the same behavior than numpy:

In [3]: a = np.array([2, 4])

In [4]: a ** -2
Out[4]: array([0, 0])

In [5]: ne.evaluate('a ** -2')
Out[5]: array([0, 0])

You might want to ask them to change that behavior first. In the mean time, I'm 
closing this bug report. Feel free to reopen it if you have an example where 
numexpr differs from numpy (other than the documented ones).

Original comment by gdemen...@gmail.com on 30 Jan 2012 at 1:21

GoogleCodeExporter commented 9 years ago
Thank you for your answer.

First, your explanation has convinced me that the current behavior is right.
But I have found a subtly different issue: I have filed that as issue 71.

I was about to ask the numpy developers to change the evaluation of a ** -2, 
when I realized there are good reasons to keep the current behavior:

1) a ** 3 stays integer, which sounds sensible (and is consistent with Python)

2) If a ** -1 were float, what should be the output type of a ** e where e is 
an integer array?
Naturally, if all e >= 0, one would hope to get an integer array as the result.
But then the only uniform way is to say that ** yields an integer array if both 
operands are integer arrays.

So I don't think I'm going to reopen this issue.

(This bug report system does not seem to allow the original poster to reopen 
the issue anyway.)

Original comment by ka...@ucw.cz on 30 Jan 2012 at 4:40