[Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #361 - 6 msgs

[Greg Kochanski]

I think Andrew Mullhaupt came up with a good point.
Unexpected downcasting is one of those things that is
hard to detect, hard to trace,
and can give you subtly wrong answers.

NumPy needs a mechanism that will optionally throw an
exception when there is a downcast.

I'd suggest a module scope flag called 'debug_precision' that
is normally 0.   When set to 1, NumPy would throw an
exception if there is a downcast.   When set to 2,
NumPy would also throw an exception for integer/integer division.

(The latter is one of my pet peeves of python.  It's too easy
to type   x=0  when you mean   x=0.0, so one ends up doing
divisions like    3/4==0 when you really mean 3.0/4.0 == 0.75.
That's another error that can be hard to track down...)


The other thing is that there ought to be a statement in the
documentation
to the effect that "It is bad practice for functions to return an
active array unless its inputs are active."

> Subject: Re: [Matrix-SIG] I have working code that implements active-casting concept.
> From: "Andrew P. Mullhaupt" <amullhau@zen-pharaohs.com>
> 
> > When a universal function involving NumPy arrays is encountered, if all
> > arrays are passive (active flag = 0) then the current coercion rules are
> > used.  If any of the arguments to the function are active arrays, then the
> > active array with the largest typecode (enumerated types in arrayobject.h)
> > determines the output types.  All other arrays are automatically cast
> > (even if it means loss of precision) to that type, before the operation
> > begins.  The output arrays from the function are all active arrays.
> 
> As long as there is a simple, completely global way for me to make sure this
> never happens - i.e. that I can turn off active arrays globally and
> permanently without regard to modules that get imported, etc., I'm OK.
> 
> It's a real annoyance to detect, let alone have to track down an unexpected
> loss of precision bug when it's not in code you wrote.