Re: [Numpy-discussion] Converting bool to float

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

On 11/1/06, Tim Hochberg <tim...@ie...> wrote:
>
> 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