No subject

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: 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
>