On 11/1/06, Keith Goodman <[EMAIL PROTECTED]> wrote:
That one seems to be fixed:
In [1]: sum(ones((300,1)) == 1)
Out[1]: 300
In [2]: (ones((300,1)) == 1).sum()
Out[2]: 300
The matrix version also returns a numpy scalar, however.
In [20]: sum(matrix(ones((300,1)) == 1))
Out[20]: 300
I wonder if that is expected?
Chuck
On 11/1/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> It looks like 1.0-x is doing the right thing.
>
> The problem is 1.0*x for matrices is going to float64. For arrays it
> returns float32 just like the 1.0-x
>
> This can't be changed at this point until 1.1
>
> We will fix the bug in 1.0*x producing float64, however. I'm still not
> sure what's causing it, though.
I think it would be great if float64 was the default in numpy. That
way most people wouldn't have to worry about dtypes when crunching
numbers. And then numpy could apply for a trademark on 'it just
works'.
Having to worry about dtypes makes users (me) nervous.
I imagine a change like this would not be an overnight change, more of
a long-term goal.
This one, from a previous thread, also makes me nervous:
>> sum(M.ones((300,1)) == 1)
matrix([[44]], dtype=int8)
That one seems to be fixed:
In [1]: sum(ones((300,1)) == 1)
Out[1]: 300
In [2]: (ones((300,1)) == 1).sum()
Out[2]: 300
The matrix version also returns a numpy scalar, however.
In [20]: sum(matrix(ones((300,1)) == 1))
Out[20]: 300
I wonder if that is expected?
Chuck
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
