numpy-discussion

[Numpy-discussion] Why doesn't array(a, dtype=single, copy=0) downcast a double array.

[Charles R H. <cha...@gm...>]

It seems to me that since the behaviour when copy=0 is to make a copy only
if necessary, it should find it necessary and make the downcast. After all,
array(a, dtype=single, copy=1) does just that without complaint. Some common
code in linalg could be replaced if array and asarray would do that
operation.

Chuck

Re: [Numpy-discussion] Why doesn't array(a, dtype=single, copy=0) downcast a double array.

[Travis O. <oli...@ie...>]

Charles R Harris wrote:
> It seems to me that since the behaviour when copy=0 is to make a copy 
> only if necessary, it should find it necessary and make the downcast. 
> After all, array(a, dtype=single, copy=1) does just that without 
> complaint. Some common code in linalg could be replaced if array and 
> asarray would do that operation.
>
Well, the fact that it makes the copy without raising an error is 
different behavior from Numeric and should be considered an unintended 
change.

We definitely should make this consistent for copy=0 or copy=1.  The 
only question, is do we raise the error in both cases or allow the 
conversion in both cases.

The long-standing behavior is to raise the error on possible-loss 
conversion and so my opinion is that we should continue with that behavior.

-Travis

Re: [Numpy-discussion] Why doesn't array(a, dtype=single, copy=0) downcast a double array.

[Charles R H. <cha...@gm...>]

On 10/16/06, Travis Oliphant <oli...@ie...> wrote:
>
> Charles R Harris wrote:
> > It seems to me that since the behaviour when copy=0 is to make a copy
> > only if necessary, it should find it necessary and make the downcast.
> > After all, array(a, dtype=single, copy=1) does just that without
> > complaint. Some common code in linalg could be replaced if array and
> > asarray would do that operation.
> >
> Well, the fact that it makes the copy without raising an error is
> different behavior from Numeric and should be considered an unintended
> change.
>
> We definitely should make this consistent for copy=0 or copy=1.  The
> only question, is do we raise the error in both cases or allow the
> conversion in both cases.
>
> The long-standing behavior is to raise the error on possible-loss
> conversion and so my opinion is that we should continue with that
> behavior.


Tradition is tradition. My own preference would be to perform the downcast
on the grounds that if I care enough to specify a data type, then that is
what I want. But I'm late to this particular party ;)

Chuck

Re: [Numpy-discussion] Why doesn't array(a, dtype=single, copy=0) downcast a double array.

[Travis O. <oli...@ee...>]

Travis Oliphant wrote:

>Charles R Harris wrote:
>  
>
>>It seems to me that since the behaviour when copy=0 is to make a copy 
>>only if necessary, it should find it necessary and make the downcast. 
>>After all, array(a, dtype=single, copy=1) does just that without 
>>complaint. Some common code in linalg could be replaced if array and 
>>asarray would do that operation.
>>
>>    
>>
>Well, the fact that it makes the copy without raising an error is 
>different behavior from Numeric and should be considered an unintended 
>change.
>
>We definitely should make this consistent for copy=0 or copy=1.  The 
>only question, is do we raise the error in both cases or allow the 
>conversion in both cases.
>
>The long-standing behavior is to raise the error on possible-loss 
>conversion and so my opinion is that we should continue with that behavior.
>
>  
>
But, on the other hand, it looks like numarray went the other direction 
and allows a cast using the array call.

Thus

import numarray
a = numarray.array([1,2,3],'d')
numarray.array(a, 'f')

works


So, I'm willing to go with the numarray behavior in numpy.


-Travis

Re: [Numpy-discussion] Why doesn't array(a, dtype=single, copy=0) downcast a double array.

[Charles R H. <cha...@gm...>]

On 10/17/06, Travis Oliphant <oli...@ee...> wrote:
>
> Travis Oliphant wrote:
>
> >Charles R Harris wrote:
> >


<snip>

>The long-standing behavior is to raise the error on possible-loss
> >conversion and so my opinion is that we should continue with that
> behavior.
> >
> >
> >
> But, on the other hand, it looks like numarray went the other direction
> and allows a cast using the array call.
>
> Thus
>
> import numarray
> a = numarray.array([1,2,3],'d')
> numarray.array(a, 'f')
>
> works
>
>
> So, I'm willing to go with the numarray behavior in numpy.
>
>
Thanks for the change, Travis. I'll wait a bit to make sure the API remains
stable and then do some cleanups in linalg. Correctness before optimization
and all that. I did note that the LaPack interface could throw an error at
the fortran level that would issue an informative error message and dump me
out of python. Is there anyway you know of to trap this behaviour?

Chuck