Thu Nov 16 16:52:29 CST 2006
In module myprecision.py:
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
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 Hinsen | E-Mail:
> hinsen at cnrs-orleans.fr
> Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-188.8.131.52.24
> Rue Charles Sadron | Fax: +33-184.108.40.206.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
More information about the Numpy-discussion