[Numpy-discussion] coercion rules for float32 in numpy are different from numarray

[Sebastian Haase]

was: Re: [Numpy-discussion] hstack(arr_Int32, arr_float32) fails because 
of casting  rules
Travis Oliphant wrote:
> Sebastian Haase wrote:
>> On Thursday 24 August 2006 17:28, Travis Oliphant wrote:
>>   
>>> Sebastian Haase wrote:
>>>     
>>>> Hi,
>>>> I get
>>>> TypeError: array cannot be safely cast to required type
>>>>
>>>> when calling hstack()  ( which calls  concatenate() )
>>>> on two arrays being a int32 and a float32 respectively.
>>>>
>>>> I understand now that a int32 cannot be safely converted into a float32
>>>> but why does  concatenate  not automatically
>>>> up(?) cast to float64  ??
>>>>       
>>> Basically, NumPy is following Numeric's behavior of raising an error in
>>> this case of unsafe casting in concatenate.  For functions that are not
>>> universal-function objects, mixed-type behavior works basically just
>>> like Numeric did (using the ordering of the types to determine which one
>>> to choose as the output).
>>>
>>> It could be argued that the ufunc-rules should be followed instead.
>>>
>>> -Travis
>>>
>>>     
>> Are you saying the  ufunc-rules  would convert "int32-float32" to float64  and 
>> hence make my code "just work" !?
>>   
> 
> This is now the behavior in SVN.   Note that this is different from both 
> Numeric (which gave an error) and numarray (which coerced to float32). 
> 
> But, it is consistent with how mixed-types are handled in calculations 
> and is thus an easier rule to explain.
> 
> Thanks for the testing.
> 
> -Travis
After sleeping over this, I am contemplating about the cases where one 
would use float32 in the first place.
My case yesterday, where I only had a 1d line profile of my data, I was 
of course OK with coercion to float64.
But if you are working with 3D image data (as in medicine) or large 2D 
images as in astronomy I would assume the reason use float32 is that 
computer memory is to tight to afford 64bits per pixel.
This is probably why numarray tried to keep float32.
Float32 can handle a few more digits of precision than int16, but not as 
much as int32.  But I find that I most always have int32s only because 
its the default, whereas I have float32 as a clear choice to save memory.

How hard would it be to change the rules back to the numarray behavior ?
Who would be negatively affected ?
And who positively ?

Thanks for the great work.
Sebastian