FW: [Numpy-discussion] Bug: extremely misleading array behavior

eric jones eric at enthought.com
Mon Jun 10 13:11:02 EDT 2002 

> We have certainly beaten this topic to death in the past. It keeps
> coming up because there is no good way around it.
> 
> Two points about the x + 1.0 issue:
> 
> 1. How often this occurs is really a function of what you are doing.
For
> those using Numeric Python as a kind of MATLAB clone, who are typing
> interactively, the size issue is of less importance and the easy
> expression is of more importance. To those writing scripts to batch
> process or writing steered applications, the size issue is more
> important and the easy expression less important. I'm using words like
> less and more here because both issues matter to everyone at some
time,
> it is just a question of relative frequency of concern.
> 
> 2. Part of what I had in mind with the kinds module proposal PEP 0242
> was dealing with the literal issue. There had been some proposals to
> make literals decimal numbers or rationals, and that got me thinking
> about how to defend myself if they did it, and also about the fact
that
> Python doesn't have Fortran's kind concept which you can use to gain a
> more platform-independent calculation.
> 
> >From the PEP this example
> 
> In module myprecision.py:
> 
>         import kinds
>         tinyint = kinds.int_kind(1)
>         single = kinds.float_kind(6, 90)
>         double = kinds.float_kind(15, 300)
>         csingle = kinds.complex_kind(6, 90)
> 
>     In the rest of my code:
> 
>         from myprecision import tinyint, single, double, csingle
>         n = tinyint(3)
>         x = double(1.e20)
>         z = 1.2
>         # builtin float gets you the default float kind, properties
> unknown
>         w = x * float(x)
>         # but in the following case we know w has kind "double".
>         w = x * double(z)
> 
>         u = csingle(x + z * 1.0j)
>         u2 = csingle(x+z, 1.0)
> 
>     Note how that entire code can then be changed to a higher
>     precision by changing the arguments in myprecision.py.
> 
>     Comment: note that you aren't promised that single != double; but
>     you are promised that double(1.e20) will hold a number with 15
>     decimal digits of precision and a range up to 10**300 or that the
>     float_kind call will fail.
> 

I think this is a nice feature, but it's actually heading the opposite
direction of where I'd like to see things go for the general use of
Numeric.  Part of Python's appeal for me is that I don't have to specify
types everywhere.  I don't want to write explicit casts throughout
equations because it munges up their readability.  Of course, the
casting sometimes can't be helped, but Numeric's current behavior really
forces this explicit casting for array types besides double, int, and
double complex.  
I like Numarray's fix for this problem.

Also, as Perry noted, its unlikely to be used as an everyday command
line tool (like Matlab) if the verbose casting is required.

I'm interested to learn what other drawbacks yall found with always
returning arrays (0-d for scalars) from Numeric functions.  Konrad
mentioned the tuple parsing issue in some extension libraries that
expects floats, but
it sounds like Travis thinks this is no longer an issue.  Are there
others?

eric

> 
> 
> 
> > -----Original Message-----
> > From: numpy-discussion-admin at lists.sourceforge.net
> > [mailto:numpy-discussion-admin at lists.sourceforge.net] On
> > Behalf Of Konrad Hinsen
> > Sent: Monday, June 10, 2002 10:08 AM
> > To: eric jones
> > Cc: numpy-discussion at lists.sourceforge.net
> > Subject: Re: FW: [Numpy-discussion] Bug: extremely misleading
> > array behavior
> >
> >
> > "eric jones" <eric at enthought.com> writes:
> >
> > > How about making indexing (not slicing) arrays *always*
> > return a 0-D
> > > array with copy instead of "view" semantics?  This is nearly
> > > equivalent to creating a new scalar type, but without
> > requiring major
> > > changes.  I
> > ...
> >
> > I think this was discussed as well a long time ago. For pure
> > Python code, this would be a very good solution. But
> >
> > > I think the only reason for the silent conversion is that
> > Python lists
> > > only allow integer values for use in indexing so that:
> >
> > There are some more cases where the type matters. If you call
> > C routines that do argument parsing via PyArg_ParseTuple and
> > expect a float argument, a rank-0 float array will raise a
> > TypeError. All the functions from the math module work like
> > that, and of course many in various extension modules.
> >
> > In the ideal world, there would not be any distinction
> > between scalars and rank-0 arrays. But I don't think we'll
> > get there soon.
> >
> > > On coercion rules:
> > >
> > > As for adding the array to a scalar value,
> > >
> > >   x = array([3., 4.], Float32)
> > >   y = x + 1.
> > >
> > > Should y be a Float or a Float32?  I like numarray's coercion
rules
> > > better (Float32).  I have run into this upcasting to many times to
> >
> > Statistically they probably give the desired result in more
> > cases. But they are in contradiction to Python principles,
> > and consistency counts a lot on my value scale.
> >
> > I propose an experiment: ask a few Python programmers who are
> > not using NumPy what type they would expect for the result. I
> > bet that not a single one would answer "Float32".
> >
> > > On the other hand, I don't think a jump from 21 to 22 is
> > enough of a
> > > jump to make such a change.  Numeric progresses pretty
> > fast, and users
> >
> > I don't think any increase in version number is enough for
> > incompatible changes. For many users, NumPy is just a
> > building block, they install it because some other package(s)
> > require it. If a new version breaks those other packages,
> > they won't be happy. The authors of those packages won't be
> > happy either, as they will get the angry letters.
> >
> > As an author of such packages, I am speaking from experience.
> > I have even considered to make my own NumPy distribution
> > under a different name, just to be safe from changes in NumPy
> > that break my code (in the past it was mostly the
> > installation code that was broken when arrayobject.h changed
> > its location).
> >
> > In my opinion, anything that is not compatible with Numeric
> > should not be called Numeric.
> >
> > Konrad.
> > --
> > --------------------------------------------------------------
> > -----------------
> > Konrad Hinsen                            | E-Mail:
> > hinsen at cnrs-orleans.fr
> > Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
> > Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
> > 45071 Orleans Cedex 2                    |
Deutsch/Esperanto/English/
> > France                                   | Nederlands/Francais
> > --------------------------------------------------------------
> > -----------------
> >
> > _______________________________________________________________
> >
> > Don't miss the 2002 Sprint PCS Application Developer's
> > Conference August 25-28 in Las Vegas -
> > http://devcon.sprintpcs.com/adp/index.cfm?> source=osdntextlink
> >
> >
> > _______________________________________________
> > Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
> http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list