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

[Paul F D. <pa...@pf...>]

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.




> -----Original Message-----
> From: num...@li... 
> [mailto:num...@li...] On 
> Behalf Of Konrad Hinsen
> Sent: Monday, June 10, 2002 10:08 AM
> To: eric jones
> Cc: num...@li...
> Subject: Re: FW: [Numpy-discussion] Bug: extremely misleading 
> array behavior
> 
> 
> "eric jones" <er...@en...> 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: 
> hi...@cn...
> 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 Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>