[Numpy-discussion] A couple more Numeric incompatibilitiesand a possible bug

[Todd Miller]

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.  

> > > Finally, has anyone got any comment about whether the __repr__ versus __str__ display of object array members is the expected behaviour?
> > > 
> > 
> > Yes.  The basic look is exactly what I wanted:

Don't ask how, but I just noticed that my foot has nearly the same
dimensions of my mouth.

> > 
> > >>> a = numarray.objects.fromlist(range(10))
> > >>> str(a)
> > '[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]'
> > >>> repr(a)
> > 'ObjectArray([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])'
> > 
> > But I'm open to suggestions and recognize that the handling of
> > spaces/item sizing is weak (although it's not pronounced in this simple
> > example).  Do people want something else?
> > 
> > Regards,
> > Todd
> 
> Your example doesn't demonstrate the problem I'm talking about because for integers the __str__ and __repr__ methods are identical. However, it does show a difference between Numeric and numarray, which would display your str(a) as
> '[0  1  2  3  4  5  6  7  8  9 ]'
> 

Well, almost what I wanted.  This will change.

> If you make an ObjectArray containing objects whose __repr__ and __str__ methods are not the same, I think you need a way of displaying the contained objects via their type-specific __str__ method. Numeric did this by default, whereas numarray has changed that behaviour.

This will change too.

> I'll go back to my example again.
> In my example str() does not display the array elements in the same way that Numeric does.
> In my case, numarray does this:
> 
> >>> print ArrayOfErr([909., 802., 677., 585.], 1.0)
> [Err(909.0,1.0,1.0), Err(802.0,1.0,1.0), Err(677.0,1.0,1.0), Err(585.0,1.0,1.0)]
> 
> >>> print str(ArrayOfErr([909., 802., 677., 585.], 1.0))
> [Err(909.0,1.0,1.0), Err(802.0,1.0,1.0), Err(677.0,1.0,1.0), Err(585.0,1.0,1.0)]
> 
> >>> print repr(ArrayOfErr([909., 802., 677., 585.], 1.0))
> ObjectArray([Err(909.0,1.0,1.0), Err(802.0,1.0,1.0), Err(677.0,1.0,1.0), Err(585.0,1.0,1.0)])
> 
> 
> ie. str() is not using the __str__ method I have defined for my Err class.
> Numeric correctly uses my class's Err.__str__ method and does this instead:
> 
> >>> print ArrayOfErr([909., 802., 677., 585.], 1.0)
> [909.0 +1.0/-1.0  802.0 +1.0/-1.0  677.0 +1.0/-1.0  585.0 +1.0/-1.0 ]
> 
> In summary, I think te behaviour should be
> >>> print str(ArrayOfErr([909., 802., 677., 585.], 1.0))
> [909.0 +1.0/-1.0  802.0 +1.0/-1.0  677.0 +1.0/-1.0  585.0 +1.0/-1.0 ]
> 
> >>> print repr(ArrayOfErr([909., 802., 677., 585.], 1.0))
> ObjectArray([Err(909.0,1.0,1.0), Err(802.0,1.0,1.0), Err(677.0,1.0,1.0), Err(585.0,1.0,1.0)])
> 
> I hope I've clarified what I'm getting at, although I probably haven't :-)

Quite clear.   Stuff will change.

Regards,
Todd

-- 
Todd Miller <jmiller at stsci.edu>