[Numpy-discussion] type coercion question

[Perry G. <pe...@st...>]

David Cooke wrote:
> On Mon, Mar 29, 2004 at 06:55:57AM -0500, Todd Miller wrote:
> > On Sun, 2004-03-28 at 22:46, Gary Ruben wrote:
> > > > > >>> cos(1)
> > > > > 0.54030227661132813
> > > > >
> > > > > gives a different result to cos(1.)
> > > <snip>
> > > > >  Do others think precision is being lost unnecessarily?
> > > >
> > > > No.  Do you have any suggestions?
> > >
> > > Yes. My problem is that numarray is not replicating the behaviour of
> > > the Python math module, which presumably coerces immediately to the
> > > float precision of the underlying platform. This is probably a
> > > float64 in Windows. If you don't explicitly specify that float32 is
> > > to be used, shouldn't the default be for a rank-0 value to
> > > immediately coerce ints to the same precision as the native Python
> > > float type on the underlying platform, since you know it will be
> > > coerced to that later and in the meantime you've lost precision
> > > because you've applied a function to a value of lower precision?
> > >
> >
> > I see your point and I'll talk it over with Perry unless he chimes in on
> > his own.  I'm ambivalent:  while it would be nice for the numarray
> > ufuncs to act as full equivalents to the Python math functions in scalar
> > cases,  numarray has to strike a balance between managing storage space
> > and maintaining precision and these two goals are in conflict.  I think
> > using an array package you have to be at least a little more aware of
> > storage concerns.
>
> I'll throw in a vote for 'cos(1)' coercing 1 to a (equivalent-to-)
> Python float. The reason is that I have 'from numarray import *' for my
> interactive interpreter, as I use numarray a lot in that.
> I would rather not have to remember to always cast my args to ufuncs to
> arrays. This isn't a storage space problem, per se., the question is
> whether cos(1) and cos(1.0) should return the same answer.
>
> Having cos(1) cast 1 to a Float32 makes numarray much less useful as a
> calculator -- mistakes are more likely. I'll probably switch my
> interpreter back to Numeric so as not to make mistakes, or I'll write a
> wrapper (which I'll post if I do).
>
> Whether cos([1,1,1]) and cos([1.0,1.0,1.0]) are the same I'd say is
> different, as there I've taken the conscious decision not to cast to an
> array. (And the fact that cos([1,1,1]) will return an array printed out
> with 'type=Float32' is a clue to what I've done.)
>
Let me say that I see the last issue (whether cos([1,1,1]) and
cos([1.0,1.0,1.0]) are the same) is important. If cos([1,1,1])[0] !=
cos(1) I think that is just as bad. So the question is whether
ints scalars and arrays should automatically be promoted to
double floats when given to unary scientific functions (sqrt,
sin, cos, log, etc.). By the way, if an Int32 is so promoted,
I don't see why it isn't the same for Int8, Int16, etc.
But it appears that Numeric promotes Int32 to Float64 for cos(),
but promotes In16 to Float32 for cos().

I believe making this change to numarray is fairly easy (we'd have
to check). But is what most people want? Should we retain complete
compatibility with Numeric (which, as pointed out, treats different
kinds of integers differently)

Just to summarize what I see as acceptable choices:

1) ints promote to Float32 (current behavior)
2) ints promote to Float64
3) Int32 promotes to Float64, lesser ints promote to Float32 (Numeric
behavior)

Perry