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

[Charles R Harris]

Hi,

On 8/25/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>
> Sebastian Haase wrote:
> >> 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
> >>
> >
> > How hard would it be to change the rules back to the numarray behavior ?
> >
> It wouldn't be hard, but I'm not so sure that's a good idea.   I do see
> the logic behind that approach and it is worthy of some discussion.
> I'll give my current opinion:
>
> The reason I changed the behavior is to get consistency so there is one
> set of rules on mixed-type interaction to explain. You can always do
> what you want by force-casting your int32 arrays to float32.    There
> will always be some people who don't like whichever behavior is
> selected, but we are trying to move NumPy in a direction of consistency
> with fewer exceptions to explain (although this is a guideline and not
> an absolute requirement).
>
> Mixed-type interaction is always somewhat ambiguous.  Now there is a
> consistent rule for both universal functions and other functions (move
> to a precision where both can be safely cast to --- unless one is a
> scalar and then its precision is ignored).


I think this is a good thing. It makes it easy to remember what the function
will produce. The only oddity the user has to be aware of is that int32 has
more precision than float32. Probably not obvious to a newbie, but a newbie
will probably be using the double defaults anyway. Which is another good
reason for making double the default type.

If you don't want that to happen, then be clear about what data-type
> should be used by casting yourself.   In this case, we should probably
> not try and guess about what users really want in mixed data-type
> situations.


I wonder if it would be reasonable to add the dtype keyword to hstack
itself? Hmmm, what are the conventions for coercions to lesser precision?
That could get messy indeed, maybe it is best to leave such things alone and
let the programmer deal with it by rethinking the program. In the float case
that would probably mean using a float32 array instead of an int32 array.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060825/187280a5/attachment.html>