[Matrix-SIG] Numeric Nits--a slightly different proposal

Rick White rlw@stsci.edu
Fri, 16 Jul 1999 08:20:37 -0400 (EDT)


David Beach writes:

% On Thu, Jul 15, 1999 at 06:33:35PM -0400, Rick White wrote:
% 
% > >An expression involving two incompatible
% > >forced objects would raise an exception.
% > 
% > I can't agree with that, though.  I'm afraid that will result
% > in more ugly, hard-to-read code with lots of explicit casts.
% > I believe that an operation between two forced objects should
% > obey the normal promotion rules, with the lower forced type
% > being promoted to the higher forced type.
% 
% Yes.  Then maybe there should be a ForcedForcedFloat32 which is
% "stronger" (more forceful?) than a plain ol' ForcedFloat32.  Doesn't
% this problem just start to repeat itself?  Do numeric types need a
% "degree of force" (e.g., a Force5Float32 beats out a Force2Float64, so
% the result is then typed as a Force5Float32 because 5 is "stronger"
% than 2)?  Where is this going?

Maybe you missed the original reason for these types, which is that any
operations with Python scalars lead to promotions, effectively making
the lower types (Float32, Int16, etc.) nearly useless except for input
and output.  For example, if x is a Float32 array, then (x+1) is a
Float64 array.  Adding Numeric types that do not get promoted in
operations with scalars puts the programmer back in control.

At that point, in my opinion, the least surprising behavior would be
for promotions to occur in the normal way within the hierarchy.  Only
operations with other forced arrays would lead to promotion, and so the
programmer can easily control that (just like you do when you write
non-Numeric Python.)

---
Richard L. White    rlw@stsci.edu    http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD