[Matrix-SIG] Re: Matrix-SIG digest, Vol 1 #361 - 6 msgs
Mon, 07 Feb 2000 11:10:07 -0500
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
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" <firstname.lastname@example.org>
> > 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.