On 11/1/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
Well, I think that the present convention of having the array float type determine the output type when doing a binary op with a scalar makes sense. The question is what to do when the initial array is an integer type and needs to be promoted. Now I could see
1) coercing the scalar float to integer, which is probably consistent with the treatment of integer types. (boo)
2) requiring explicit use of float types, i.e., float64(1.0), which is a bit clumsy.
3) promoting to float64 by default and expecting the user to specify float32( 1.0) when needed.
I prefer 3, as float32 is probably not the most used data type. So the rule would be
numpy_int array + python_int -- type numpy_int
numpy_int array + python_flt -- type float64
numpy_int array + numpy_flt -- type numpy_flt
numpy_flt array + python_flt -- type numpy_flt
Seems a bit much to remember, but things always get complicated when you want to control the types. Mind that going from int64 to float64 can lead to loss of precision.
Chuck
Travis Oliphant wrote:
> Robert Kern wrote:
>
>
>> Travis Oliphant 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
>>>
>>>
>>>
>> Why is this the right thing? Python floats are float64.
>>
>>
>>
> Yeah, why indeed. Must be something with the scalar coercion code...
This is one of those things that pops up every few years. I suspect that
the best thing to do here is to treat 1.0, and all Python floats as
having a kind (float), but no precision. Or, equivalently treat them as
the smallest precision floating point value. The rationale behind this
is that otherwise float32 array will be promoted whenever they are
multiplied by Python floating point scalars. If Python floats are
treated as Float64 for purposes of determining output precision then
anyone using float32 arrays is going to have to wrap all of their
literals in float32 to prevent inadvertent upcasting to float64. This
was the origin of the (rather clunky) numarray spacesaver flag.
It's no skin off my nose either way, since I pretty much never use
float32, but I suspect that treating python floats equivalently to
float64 scalars would be a mistake. At the very least it deserves a bit
of discussion.
Well, I think that the present convention of having the array float type determine the output type when doing a binary op with a scalar makes sense. The question is what to do when the initial array is an integer type and needs to be promoted. Now I could see
1) coercing the scalar float to integer, which is probably consistent with the treatment of integer types. (boo)
2) requiring explicit use of float types, i.e., float64(1.0), which is a bit clumsy.
3) promoting to float64 by default and expecting the user to specify float32( 1.0) when needed.
I prefer 3, as float32 is probably not the most used data type. So the rule would be
numpy_int array + python_int -- type numpy_int
numpy_int array + python_flt -- type float64
numpy_int array + numpy_flt -- type numpy_flt
numpy_flt array + python_flt -- type numpy_flt
Seems a bit much to remember, but things always get complicated when you want to control the types. Mind that going from int64 to float64 can lead to loss of precision.
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
