From rozey8@webtv.net Fri Jan 2 07:12:32 1998
From: rozey8@webtv.net (Rose Belk)
Date: Thu, 1 Jan 1998 23:12:32 -0800
Subject: [MATRIX-SIG] pickled sausages
Message-ID: <199801020712.XAA21001@mailtod-132.iap.bryant.webtv.net>
thanks for the recipe on pickled sausage
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From UXV12Y0Uq@1blowup.net Fri Jan 2 12:01:46 1998
From: UXV12Y0Uq@1blowup.net (UXV12Y0Uq@1blowup.net)
Date: 02 Jan 98 12:01:46 AM
Subject: [MATRIX-SIG] Give Your Child "One of the Best Children's Videos""
Message-ID: <eQoBXcmYbm3XZvYKJ4>
The holidays are upon us. If you're like a lot of people, you struggle to
find gifts for your children that will entertain and amuse them at the same
time. Well, here's a gift that will delight your child -
A Is For Airplane!
"A Is For Airplane" is the award-winning educational video that shows kids
all the fun and teamwork involved in running an airline. "A Is For Airplane"
gets viewers behind the scenes at the airport! Kids get to see:
* The ticket counter!
* Inside the baggage system!
* On the ramp with the baggage loaders and fuelers!
* In the catering kitchens!
* Inside the control tower!
* In the hangar with the mechanics!
* At the boarding gate!
* And even in the COCKPIT of a real Boeing 757!
Parenting Magazine calls "A Is For Airplane" "One of the Best Videos of
1996!" It's also Approved by the Parent's Choice Foundation!
Thousands of copies of "A Is For Airplane" have been sold for $14.95, but as
an Internet Special this holiday season you can get "A Is For Airplane" for
only $11.95 (plus shipping and handling.) ORDER TODAY FOR GUARANTEED HOLIDAY
DELIVERY!
You can order "A Is For Airplane" by calling our toll-free number -
800-250-4210.
If you'd like more information, visit our Website at
www.ppmm.com/jfp/jfp1297.htm
or CLICK HERE!
Thank you for your time...
Johnson Family Productions
Madison, WI
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Jack.Jansen@cwi.nl Wed Jan 7 12:09:52 1998
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 07 Jan 1998 13:09:52 +0100
Subject: [MATRIX-SIG] Re: [PYTHONMAC-SIG] MacPython v1.5b3 / NumPy bugs?
In-Reply-To: Message by wtbridgman@radix.net (W.T. Bridgman) ,
Tue, 6 Jan 1998 21:21:24 -0500 , <v01530500b0d88e5cd648@[209.48.225.39]>
Message-ID: <UTC199801071209.NAA10330.jack@snelboot.cwi.nl>
I've added the matrix-sig people to the recipients, hopefully there's someone
there who has a bright idea.
>
> 2) I reported this next problem in the NumPy that came with v1.5a4 and it
> seems to still be there. However, I suspect this is a NumPy specific
> problem. By just importing the RandomArray module, I get:
>
> >>>>> import RandomArray
> >>Traceback (innermost last):
> >> File "<stdin>", line 1, in ?
> >> File "Macintosh HD:Development:Python v1.5:Python
> >>1.5b3:Extensions:NumPy:NumPy:RandomArray.py", line 12, in ?
> >> seed()
> >> File "Macintosh HD:Development:Python v1.5:Python
> >>1.5b3:Extensions:NumPy:NumPy:RandomArray.py", line 8, in seed
> >> x = int(t)
> >>OverflowError: float too large to convert
> >>>>>
This is because MacPython time.time() can return a float that is bigger than
can be represented in a signed int (but it could have been represented in a
32bit unsigned int, had Python had such a type).
>
> Rob Managan reported this fix but my first concern is if this is legit and
> doesn't introduce any problems or correlations in the generator:
>
> >def seed(x=0,y=0):
> > if x == y == 0:
> > import time
> > t = time.time()
> > x = long(t)
> > y = long((t-long(t))*1000000)
> > ranlib.set_seeds(x,y)
> >
>
> Now this fix generates errors at ranlib.set_seeds with:
>
> OverflowError: long int too long to convert.
Yes, I noticed that. All the other fixes I tried (clamping the x value to 31
bits, or by trickery converting the longint to the 32bit signed representation
that corresponds to the unsigned value) have resulted in strange crashes
inside ranlib.set_seeds(). It turns out that the library that underlies the
ranlib module handles errors by calling printf() and then exit(); not very
nice on the Mac because you never get to see the output:-(
Apparently the numbers you give to ranlib.set_seeds() have to satisfy certain
criteria, what are these criteria, matrix-folks? If I know these I can come up
with two randomish numbers that match them for the mac...
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Jack.Jansen@cwi.nl Wed Jan 7 20:46:03 1998
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 07 Jan 1998 21:46:03 +0100
Subject: [MATRIX-SIG] Re: [PYTHONMAC-SIG] MacPython v1.5b3 / NumPy bugs?
In-Reply-To: Message by Konrad Hinsen <hinsen@ibs.ibs.fr> ,
Wed, 7 Jan 1998 18:36:29 +0100 , <199801071736.SAA12948@lmspc1.ibs.fr>
Message-ID: <UTC199801072046.VAA15610.jack@snelboot.cwi.nl>
Recently, Konrad Hinsen <hinsen@ibs.ibs.fr> said:
> But just an idea: are you sure the f2c generated code works on the
> Mac at all? It makes assumptions about the relative sizes of
> various data types, which might not be true on the Mac. In that
> case you might be overwriting essential data in common blocks.
">*WHAT?!*<", he says, grabbing the table and trying to steady his
breath... Since the C code, not the fortran code, is distributed it
might be a good idea to put some asserts somewhere that these
assumptions hold...
But, luckily, the f2c code seems to work on the mac. For all three
architectures (PPC, classic 68k, cfm68k) I use
sizeof(int)==sizeof(long)==4 and sizeof(double)==8. This seems what
f2c expects: PPC and classic 68k appear to work fine (except for this
little bug), cfm68k (which is 68k code but with a ppc-ish memory
model) has problems, but I'll get back with those when I have more
details (unless I can solve it myself).
Unless f2c (or something else) also expects IEEE floating point?
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From bsd@scripps.edu Wed Jan 7 22:14:26 1998
From: bsd@scripps.edu (Bruce Duncan)
Date: Wed, 7 Jan 1998 14:14:26 -0800 (PST)
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
Message-ID: <199801072214.OAA08405@joseph.scripps.edu>
Greetings,
The LoadArray function in Numeric python seems to have a bug.
I have the following situation:
A pickled file for an integer array was created on an SGI Onyx.
This machine has 4 byte ints and 4 byte longs.
The picked file would not read on a DEC alpha (64 bit longs).
The reshape function in LoadArray failed because the
byte counts didn't match.
In this situation, LoadArray should load the pickle file
using 32 bit ints using the elementsize information and the
desired typecode.
It could then optionally cast the resulting array to long.
-bsd-
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From pavlos@dionysos.physics.sunysb.edu Thu Jan 8 02:26:56 1998
From: pavlos@dionysos.physics.sunysb.edu (Pavlos Christoforou)
Date: Wed, 7 Jan 1998 21:26:56 -0500 (EST)
Subject: [MATRIX-SIG] Memory Leak?
Message-ID: <Pine.LNX.3.95.980107212128.15720A-100000@dionysos.physics.sunysb.edu>
I have installed Python-1.5 (final) and an old script now leaks. The
following code runs fine with python1.4 but leaks with python1.5
--------------------------------------------------------------------
import Numeric
a=Numeric.ones((10,2))
def test(data):
dat_max=[]
for i in range(3):
dat_max.append(data[i,:])
return dat_max
for i in range(100000):
m=test(a)
----------------------------------------------------------------
Any advice??
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Thu Jan 8 11:30:31 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 8 Jan 1998 12:30:31 +0100
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: <199801072214.OAA08405@joseph.scripps.edu> (message from Bruce
Duncan on Wed, 7 Jan 1998 14:14:26 -0800 (PST))
Message-ID: <199801081130.MAA16712@lmspc1.ibs.fr>
> A pickled file for an integer array was created on an SGI Onyx.
> This machine has 4 byte ints and 4 byte longs.
>
> The picked file would not read on a DEC alpha (64 bit longs).
> The reshape function in LoadArray failed because the
> byte counts didn't match.
I am not surprised - the pickling approach used in NumPy is not really
portable. Anyway, it will have to be rewritten to profit from cPickle
under Python 1.5. Unfortunately, there is no perfect solution; either
pickling must make assumptions about the binary format of its data
types (as it does now), or it must apply a conversion, which can
become very time consuming for large arrays.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jhauser@ifm.uni-kiel.de Thu Jan 8 13:34:23 1998
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Thu, 8 Jan 1998 14:34:23 +0100 (CET)
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: <199801081130.MAA16712@lmspc1.ibs.fr>
References: <199801072214.OAA08405@joseph.scripps.edu> <199801081130.MAA16712@lmspc1.ibs.fr>
Message-ID: <m0xqI6J-000sszC@lisboa.ifm.uni-kiel.de>
I have read part of the discussion between you and Jim Fulton. Was
there a real conclusion. Is pickling the only general way for NumPy. I
know one can store arrays in netcdf, but what if one wants to store a
hole object (make it persistent). I understand pickling to be similar
to a flat database format. Isn't there a way to have something like
BLOBs in this format?
Just curious,
__Janko
Konrad Hinsen writes:
> > A pickled file for an integer array was created on an SGI Onyx.
> > This machine has 4 byte ints and 4 byte longs.
> >
> > The picked file would not read on a DEC alpha (64 bit longs).
> > The reshape function in LoadArray failed because the
> > byte counts didn't match.
>
> I am not surprised - the pickling approach used in NumPy is not really
> portable. Anyway, it will have to be rewritten to profit from cPickle
> under Python 1.5. Unfortunately, there is no perfect solution; either
> pickling must make assumptions about the binary format of its data
> types (as it does now), or it must apply a conversion, which can
> become very time consuming for large arrays.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From bill.white@technologist.com Thu Jan 8 14:26:42 1998
From: bill.white@technologist.com (Bill White)
Date: Thu, 08 Jan 1998 09:26:42 -0500
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: Your message of "Thu, 08 Jan 1998 12:30:31 +0100."
<199801081130.MAA16712@lmspc1.ibs.fr>
Message-ID: <199801081426.JAA01724@starik.griggsinst.com>
> > A pickled file for an integer array was created on an SGI Onyx.
> > This machine has 4 byte ints and 4 byte longs.
> >
> > The picked file would not read on a DEC alpha (64 bit longs).
> > The reshape function in LoadArray failed because the
> > byte counts didn't match.
>
> I am not surprised - the pickling approach used in NumPy is not really
> portable. Anyway, it will have to be rewritten to profit from cPickle
> under Python 1.5. Unfortunately, there is no perfect solution; either
> pickling must make assumptions about the binary format of its data
> types (as it does now), or it must apply a conversion, which can
> become very time consuming for large arrays.
Well, forgive me for saying the obvious thing, but perhaps the best
approach is to do the following, assuming that people will be moving
mostly to similar or identical architectures, but with the occasional
radical excursion.
1.) Define a language for describing numeric representations. This
could be as simple as a bit string, with k bit fields to store
the sizes of the various sized integers, a field to store a
token to represent the floating point representation, and whatever
else needs to be done.
2.) Add a copy of this record to each pickled object somehow.
3.) Write routines to translate between non-stanard representations.
You could go wild with this, but I'll bet most or all needs would
be met with routines to translate 2^m byte integers to 2^n byte
integers, both signed and unsigned, for n > m, n,m \in {1..3}.
That's 3 * 2 == 12 trivial routines, since the diagonals are
just copies. Also, you'd have to write a floating point conversion
routine, which is complicated as well.
This way, if you pickle something for your own use later, or for use
on an identical machine, translation takes constant time. If you
pickle something to be sent to a different architecture, there is
enough information to do the conversion.
I think this is roughly the way DCE or Sun RPC does this. However, I
don't know the pickling code, so perhaps it is a silly idea after all.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Jack.Jansen@cwi.nl Thu Jan 8 14:25:12 1998
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Thu, 08 Jan 1998 15:25:12 +0100
Subject: [MATRIX-SIG] NumPy stack usage
Message-ID: <UTC199801081425.PAA25411.jack@snelboot.cwi.nl>
Am I right in guessing that NumPy (or at least some NumPy routines,
the ufunc stuff for instance) uses large amounts of stackspace?
For the last week I've been hunting crashes, and things appear to work
better when I increase the stackspace allotted to Python. (This is on
the 68K Mac, where you have to specify the amount of stackspace to use,
unlike on Unix and such. And if you guess wrong your stack will
happily run over your heap....)
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hugunin@CNRI.Reston.Va.US Thu Jan 8 14:49:09 1998
From: hugunin@CNRI.Reston.Va.US (Jim Hugunin)
Date: Thu, 08 Jan 1998 09:49:09 -0500
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
References: <199801081426.JAA01724@starik.griggsinst.com>
Message-ID: <34B4E765.4C3EC8BF@cnri.reston.va.us>
Bill White wrote:
>
> > > A pickled file for an integer array was created on an SGI Onyx.
> > > This machine has 4 byte ints and 4 byte longs.
> > >
> > > The picked file would not read on a DEC alpha (64 bit longs).
> > > The reshape function in LoadArray failed because the
> > > byte counts didn't match.
> >
> > I am not surprised - the pickling approach used in NumPy is not really
> > portable. Anyway, it will have to be rewritten to profit from cPickle
> > under Python 1.5. Unfortunately, there is no perfect solution; either
> > pickling must make assumptions about the binary format of its data
> > types (as it does now), or it must apply a conversion, which can
> > become very time consuming for large arrays.
>
> Well, forgive me for saying the obvious thing, but perhaps the best
> approach is to do the following, assuming that people will be moving
> mostly to similar or identical architectures, but with the occasional
> radical excursion.
<Proposed solution snipped>
This is in fact the assumption made by the current Pickling algorithm.
It includes the actual number of bytes used to store the particular
numeric type when it does the pickle. On platforms where this number
matches the native size, no conversions are necessary. The idea always
was to add code to LoadArray that would check this assumption and when
moving to a platform with different numeric sizes it would then (and
only then) perform a potentially expensive conversion operation.
I made sure that DumpArray put this information into the pickle format,
so that in the future somebody with the time could write a correct
implementation of LoadArray without needing to make any incompatible
changes to the array pickling format. Anybody want to actually write
the code?
-Jim
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Thu Jan 8 16:29:19 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 8 Jan 1998 08:29:19 -0800
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
Message-ID: <01bd1c52$9185c140$998a7380@pduboispc>
The PDB library has the following strategy: store the data in a format
native to the writing machine and also store info about the machine's
representation. If a reader discovers non-native data, it translates on the
way in. This gives you much better performance in normal cases than always
translating to some standard format.
Certainly there would be no reason to reinvent all that, if that was what
was wanted. But I know nothing about pickling so I will now shut up.
-----Original Message-----
From: Bill White <bill.white@technologist.com>
To: Konrad Hinsen <hinsen@ibs.ibs.fr>
Cc: bsd@scripps.edu <bsd@scripps.edu>; matrix-sig@python.org
<matrix-sig@python.org>; sanner@joseph.scripps.edu
<sanner@joseph.scripps.edu>
Date: Thursday, January 08, 1998 6:38 AM
Subject: Re: [MATRIX-SIG] Possible bug in Numeric LoadArray function
>
>> > A pickled file for an integer array was created on an SGI Onyx.
>> > This machine has 4 byte ints and 4 byte longs.
>> >
>> > The picked file would not read on a DEC alpha (64 bit longs).
>> > The reshape function in LoadArray failed because the
>> > byte counts didn't match.
>>
>> I am not surprised - the pickling approach used in NumPy is not really
>> portable. Anyway, it will have to be rewritten to profit from cPickle
>> under Python 1.5. Unfortunately, there is no perfect solution; either
>> pickling must make assumptions about the binary format of its data
>> types (as it does now), or it must apply a conversion, which can
>> become very time consuming for large arrays.
>
>Well, forgive me for saying the obvious thing, but perhaps the best
>approach is to do the following, assuming that people will be moving
>mostly to similar or identical architectures, but with the occasional
>radical excursion.
>1.) Define a language for describing numeric representations. This
> could be as simple as a bit string, with k bit fields to store
> the sizes of the various sized integers, a field to store a
> token to represent the floating point representation, and whatever
> else needs to be done.
>2.) Add a copy of this record to each pickled object somehow.
>3.) Write routines to translate between non-stanard representations.
> You could go wild with this, but I'll bet most or all needs would
> be met with routines to translate 2^m byte integers to 2^n byte
> integers, both signed and unsigned, for n > m, n,m \in {1..3}.
> That's 3 * 2 == 12 trivial routines, since the diagonals are
> just copies. Also, you'd have to write a floating point conversion
> routine, which is complicated as well.
>
>This way, if you pickle something for your own use later, or for use
>on an identical machine, translation takes constant time. If you
>pickle something to be sent to a different architecture, there is
>enough information to do the conversion.
>
>I think this is roughly the way DCE or Sun RPC does this. However, I
>don't know the pickling code, so perhaps it is a silly idea after all.
>
>
>
>_______________
>MATRIX-SIG - SIG on Matrix Math for Python
>
>send messages to: matrix-sig@python.org
>administrivia to: matrix-sig-request@python.org
>_______________
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jeremy@CNRI.Reston.Va.US Thu Jan 8 17:09:32 1998
From: jeremy@CNRI.Reston.Va.US (Jeremy Hylton)
Date: Thu, 8 Jan 1998 12:09:32 -0500
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: <01bd1c52$9185c140$998a7380@pduboispc>
References: <01bd1c52$9185c140$998a7380@pduboispc>
Message-ID: <199801081709.MAA29838@eric.CNRI.Reston.Va.US>
>>>>> "PD" == Paul F Dubois <dubois1@llnl.gov> writes:
PD> Certainly there would be no reason to reinvent all that, if that
PD> was what was wanted. But I know nothing about pickling so I will
PD> now shut up.
Actually, that's the way Modula-3 pickles work too.
Jeremy
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Thu Jan 8 18:15:14 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 8 Jan 1998 19:15:14 +0100
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: <199801081426.JAA01724@starik.griggsinst.com> (message from Bill
White on Thu, 08 Jan 1998 09:26:42 -0500)
Message-ID: <199801081815.TAA18518@lmspc1.ibs.fr>
> Well, forgive me for saying the obvious thing, but perhaps the best
> approach is to do the following, assuming that people will be moving
> mostly to similar or identical architectures, but with the occasional
> radical excursion.
> 1.) Define a language for describing numeric representations. This
> could be as simple as a bit string, with k bit fields to store
> the sizes of the various sized integers, a field to store a
> token to represent the floating point representation, and whatever
> else needs to be done.
That sounds like a good solution, provided that:
1) This additional information is not too big (it has to be
added to each array).
2) Such a description language exists or someone is willing
to invent it (because it doesn't sound trivial).
> I think this is roughly the way DCE or Sun RPC does this. However, I
> don't know the pickling code, so perhaps it is a silly idea after all.
RPC uses the XDR library, like netCDF and probably others. XDR uses
IEEE format for floats, so it's fast on IEEE machines and slow on
others. That sounds like a good solution to me, since non-IEEE
machines seem to be disappearing, but I am sure this could generate
some flame mails ;-)
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From managan@llnl.gov Thu Jan 8 20:51:46 1998
From: managan@llnl.gov (Rob Managan)
Date: Thu, 8 Jan 1998 12:51:46 -0800
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: <199801081815.TAA18518@lmspc1.ibs.fr>
References: <199801081426.JAA01724@starik.griggsinst.com> (message from
Bill White on Thu, 08 Jan 1998 09:26:42 -0500)
Message-ID: <v03110701b0dadc25ef71@[128.115.198.165]>
Bill White wrote
>> 1.) Define a language for describing numeric representations. This
>> could be as simple as a bit string, with k bit fields to store
>> the sizes of the various sized integers, a field to store a
>> token to represent the floating point representation, and whatever
>> else needs to be done.
Konrad Hinsen wrote
>RPC uses the XDR library, like netCDF and probably others. XDR uses
>IEEE format for floats, so it's fast on IEEE machines and slow on
>others. That sounds like a good solution to me, since non-IEEE
>machines seem to be disappearing, but I am sure this could generate
>some flame mails ;-)
>--
The PDBlib file format which is part of LLNL's PACT system has a way to
specify the numeric representation. They also have general conversion
routines. Those may be more than needed here. PDBlib defaults to storing in
the local native format so that reads and writes are fast if not changing
platforms. Conversions do occur when a file is moved to different platform.
Here is what is stored to define integers and floats
Define a primitive integral type (fixed point type) in the PDB file file.
Input: file, a pointer to a PDBfile,
name, an ASCII string containing the name of the new data type,
bytespitem, the number of bytes required for 1 item of the new type,
align, the byte alignment for the type,
flg, a flag indicating whether the byte ordering of the type is normal
or reverse ordered (NORMAL_ORDER or REVERSE_ORDER).
Define a new floating point type to the PDB file file.
Input: file, a pointer to a PDBfile,
name, an ASCII string containing the name of the data type in the
PDB file,
bytespitem, the number of bytes required for an item of the new type,
align, the byte alignment for this type,
ordr, an array of bytespitem integers specifying the byte order,
expb, the number of exponent bits,
mantb, the number of mantissa bits,
sbs, the position of the sign bit,
sbe, the starting bit of the exponent,
sbm, the starting bit of the mantissa,
hmb, the value of the high order mantissa bit,
bias, the bias of the exponent.
*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
Rob Managan mailto://managan@llnl.gov
LLNL ph: 510-423-0903
P.O. Box 808, L-183 FAX: 510-423-5804
Livermore, CA 94551-0808
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From bill.white@technologist.com Fri Jan 9 00:33:19 1998
From: bill.white@technologist.com (Bill White)
Date: Thu, 08 Jan 1998 19:33:19 -0500
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: Your message of "Thu, 08 Jan 1998 19:15:14 +0100."
<199801081815.TAA18518@lmspc1.ibs.fr>
Message-ID: <199801090033.TAA00966@starik.griggsinst.com>
Well, actually my reply was in the engineer's language, which is
to say too detailed to see the real idea. The recent reply "store it
in the creating machine's format along with an indication of what the
creating machine's format is" is pretty much all I had in mind.
If I get some time and still have energy to think after dancing this
evening I'll think about it more.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Jan 9 16:55:22 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 9 Jan 1998 17:55:22 +0100
Subject: [MATRIX-SIG] Possible bug in Numeric LoadArray function
In-Reply-To: <m0xqI6J-000sszC@lisboa.ifm.uni-kiel.de> (message from Janko
Hauser on Thu, 8 Jan 1998 14:34:23 +0100 (CET))
Message-ID: <199801091655.RAA23698@lmspc1.ibs.fr>
> I have read part of the discussion between you and Jim Fulton. Was
> there a real conclusion. Is pickling the only general way for NumPy. I
> know one can store arrays in netcdf, but what if one wants to store a
> hole object (make it persistent). I understand pickling to be similar
> to a flat database format. Isn't there a way to have something like
> BLOBs in this format?
Pickling has a number of advantages, most of all that it is supported
for almost any Python object. With respect to the cPickle discussion,
we never reached a final conclusion. That does not mean that
supporting NumPy pickling is impossible at the moment, but it would
suffer from the same problem as the current pickle implementation,
namely that a temporary data object of the same size as the array must
be created.
Obviously other storage formats could be invented and implemented,
but it's probably less effort to properly implement pickling.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From bsd@scripps.edu Tue Jan 13 08:38:34 1998
From: bsd@scripps.edu (Bruce Duncan)
Date: Tue, 13 Jan 1998 00:38:34 -0800 (PST)
Subject: [MATRIX-SIG] cPickle/shelve and Numeric
Message-ID: <199801130838.AAA28985@solomon.scripps.edu>
Is there a version of cPickle/shelve for Numeric?
If not, what is the best way to store arbitrary python objects (that
may contain Numeric arrays) to dbm-style database files?
Thanks,
-bsd-
Bruce Duncan
The Scripps Research Institute
bsd@scripps.edu
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jim@digicool.com Tue Jan 13 11:46:25 1998
From: jim@digicool.com (Jim Fulton)
Date: Tue, 13 Jan 1998 06:46:25 -0500
Subject: [MATRIX-SIG] cPickle/shelve and Numeric
References: <199801130838.AAA28985@solomon.scripps.edu>
Message-ID: <34BB5411.17B5@digicool.com>
Bruce Duncan wrote:
>
> Is there a version of cPickle/shelve for Numeric?
> If not, what is the best way to store arbitrary python objects (that
> may contain Numeric arrays) to dbm-style database files?
cPickle supports pickling objects of any type, including Numeric arrays,
however, cPickle's strategy is inefficient for arrays larger than a
few megs. Also, to use cPickle with a non-standard type, you have
to define a "reduction" function or method that and constructor that
converts the non-standard type to and from standard types. This is
not hard. See the cPickle documentation for details and contact me if
you have any questions.
I'd like to see something done about the inefficiency problem for
large arrays. I've come up with a few ideas, but don't have time to
work on this. If anyone wants to work on this, I'd be happy to work
with them and (probably) incorporate their change into the cPickle
distribution.
Jim
--
Jim Fulton mailto:jim@digicool.com
Technical Director (540) 371-6909 Python Powered!
Digital Creattions http://www.digicool.com http://www.python.org
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Tue Jan 13 16:47:04 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 13 Jan 1998 17:47:04 +0100
Subject: [MATRIX-SIG] cPickle/shelve and Numeric
In-Reply-To: <199801130838.AAA28985@solomon.scripps.edu> (message from Bruce
Duncan on Tue, 13 Jan 1998 00:38:34 -0800 (PST))
Message-ID: <199801131647.RAA13998@lmspc1.ibs.fr>
> Is there a version of cPickle/shelve for Numeric?
> If not, what is the best way to store arbitrary python objects (that
> may contain Numeric arrays) to dbm-style database files?
For the moment, use the pickler/unpickler defined in module Numeric
and put the result. I can think of a few ways to use it in shelve,
all of which untested, of course:
1) The "quick hack" solution:
import shelve
from Numeric import Pickler, Unpickler
shelve.Pickler = Pickler
shelve.Unpickler = Unpickler
2) Somewhat better: make a new module, called e.g. "array_shelve",
and containing
from shelve import *
from Numeric import Pickler, Unpickler
3) Subclass everything from shelve and replace the methods referring
to Pickler or Unpickler.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From holz@zib.de Tue Jan 13 17:19:34 1998
From: holz@zib.de (Martin Holz)
Date: 13 Jan 1998 18:19:34 +0100
Subject: [MATRIX-SIG] Bus error in LapackError
Message-ID: <wi7k9c4e1g9.fsf@mailhost.zib.de>
After installing NumPy-1.0b3 on SunOS 5.5.1, python1.5 always
crashed, when I imported lapack_lite.
Gdb says:
--------------------------------
(gdb) c
Continuing.
>>> import lapack_lite
Program received signal SIGBUS, Bus error.
0xef3e94dc in LapackError ()
--------------------------------
I am under the impression, that the C compiler (SC4.0) does not initialize
static variables to zero. I guess it is a compiler/linker bug, but changing
static PyObject *ErrorObject;
to
static PyObject *ErrorObject = NULL;
makes NumPy running fine.
Martin
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From friedric@ips.jsc.nasa.gov Tue Jan 13 19:58:54 1998
From: friedric@ips.jsc.nasa.gov (Friedrich)
Date: Tue, 13 Jan 1998 13:58:54 -0600 (CST)
Subject: [MATRIX-SIG] NumPy 1.0b3 on AIX 4.2.1 w/ python 1.5
Message-ID: <199801131958.NAA19656@fddo4_20.ips.jsc.nasa.gov>
I'm trying to build a clean extension of NumPy for my new 1.5final installation.
The install directions seem lacking. (Is there an updated version somewhere?)
The link of the various modules shared libraries were failing because ld seems
to have been looking for a .a archive of the libnumpymodule.so which was indeed
sitting in the same directory. (see below)
I placed a sym link libnumpymodule.a->libnumpymodule.so
and the linker was happy but this is obviously bogus.
[echo prints turned on]
./makexp_aix ranlib.exp ranlib.so ranlibmodule.o ranlib.o com.o linpack.o
cc -Wl,-einitranlib -Wl,-bE:ranlib.exp -Wl,-bI:./python.exp -Wl,-bhalt:4 -Wl,-bM
:SRE -Wl,-T512 -Wl,-H512 -lm -o ranlib.so ranlibmodule.o ranlib.o com.o linpack.
o -L. -lnumpymodule
ld: 0706-006 Cannot find or open library file: -l numpymodule
ld:open(): A file or directory in the path name does not exist.
Now that I have some .so files, one seems to be missing:
'4) Move numpymodule.so (or whatever you're dynamic library suffix is)
to "/usr/lib" or "/lib".' There is no numpymodule.so created by the makefile?
Can someone give some hints on AIX NumPy?
(please cc: me as I am not on matrix-sig)
TIA
Robin Friedrich
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From bsd@scripps.edu Tue Jan 13 20:43:49 1998
From: bsd@scripps.edu (Bruce Duncan)
Date: Tue, 13 Jan 1998 12:43:49 -0800 (PST)
Subject: [MATRIX-SIG] Numeric and LinearAlgebra on 64bit machines
Message-ID: <199801132043.MAA05229@lot.scripps.edu>
The following script produces a core dump with Python 1.5 on our DEC alpha
workstations:
import Numeric
import LinearAlgebra
a = Numeric.identity(3)
LinearAlgebra.eigenvectors(a)
Any clues on what's wrong here?
I suspect that somthing is not 64bit clean.
-bsd-
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Wed Jan 14 11:09:52 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 14 Jan 1998 12:09:52 +0100
Subject: [MATRIX-SIG] NumPy 1.0b3 on AIX 4.2.1 w/ python 1.5
In-Reply-To: <199801131958.NAA19656@fddo4_20.ips.jsc.nasa.gov> (message from
Friedrich on Tue, 13 Jan 1998 13:58:54 -0600 (CST))
Message-ID: <199801141109.MAA18293@lmspc1.ibs.fr>
> I'm trying to build a clean extension of NumPy for my new 1.5final installation.
> The install directions seem lacking. (Is there an updated version somewhere?)
Not really updated, but you will probably have much less trouble with
my modified version at
http://starship.skyport.net/crew/hinsen/numpy.tar.gz
This version explicitly imports all dynamic modules, i.e. no module
is ever linked with another shared library. There are no functional
differences (other than bug fixes posted previously to the Matrix-SIG),
so I don't expect any incompatibilities.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Wed Jan 14 11:13:54 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 14 Jan 1998 12:13:54 +0100
Subject: [MATRIX-SIG] Numeric and LinearAlgebra on 64bit machines
In-Reply-To: <199801132043.MAA05229@lot.scripps.edu> (message from Bruce
Duncan on Tue, 13 Jan 1998 12:43:49 -0800 (PST))
Message-ID: <199801141113.MAA18326@lmspc1.ibs.fr>
> Any clues on what's wrong here?
> I suspect that somthing is not 64bit clean.
No idea about the DEC, but on a 64-bit SGI the result is the following:
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "/usr/local/lib/python1.4/NumPy/LinearAlgebra.py", line 167, in eigenvectors
raise LinAlgError, 'Eigenvalues did not converge'
LinearAlgebraError: Eigenvalues did not converge
So there might indeed be some problem. On the other hand, I have had
so much trouble with SGI compilers already that I wouldn't exclude
another compiler-induced problem again.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From aaron_watters@classic.msn.com Wed Jan 14 19:23:27 1998
From: aaron_watters@classic.msn.com (aaron watters)
Date: Wed, 14 Jan 98 19:23:27 UT
Subject: [MATRIX-SIG] RE: Hybrid Symbolic-numerics
Message-ID: <UPMAIL01.199801141928040708@classic.msn.com>
[Query from Tony Scott follows]
I don't know of any integrated environments.
NumPy provide fast numeric operations, but no integrated, eg, graphics, afiak.
Someone should do it someday, if it hasn't been done ;).
If anyone would like to do it you could put an equational or other symbolic
interface onto NumPy using kwParsing pretty easily... Been meaning to do
this...
So much time, so little to do (scratch that, reverse it).
I forward your query to the matrix-sig@python.org.
Subscribe to it a http://www.python.org if you are interested. --- Aaron
Watters
-----Original Message-----
From: Tony Scott
Sent: Wednesday, January 14, 1998 11:52 AM
To: arw@pythonpros.com
Subject: Hybrid Symbolic-numerics
Dear Sir,
In searching on the web for a user-interface for
hybrid symbolic numerics, your email address viz-a-viz
Python appeared. Can you tell me if anybody has developed
a user-model or user-interface for a system which combined
the symbolic capabilities of e.g. Maple and the capabilities
of a fast numerical computation system like e.g. MATLAB?
Any info would be appreciated.
Thanx in advance
Best Wishes,
Tony
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Tony.Scott@inria.fr Wed Jan 14 19:50:28 1998
From: Tony.Scott@inria.fr (Tony Scott)
Date: Wed, 14 Jan 1998 20:50:28 +0100 (MET)
Subject: [MATRIX-SIG] RE: Hybrid Symbolic-numerics
In-Reply-To: <UPMAIL01.199801141928040708@classic.msn.com>
Message-ID: <Pine.OSF.3.96.980114205010.3541A-100000@arte.inria.fr>
Dear Sirs,
Thank you for this information.
Best Wishes,
Tony
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From PfZr5EB64@1nashvill.com Wed Jan 14 03:55:45 1998
From: PfZr5EB64@1nashvill.com (PfZr5EB64@1nashvill.com)
Date: 14 Jan 98 3:55:45 AM
Subject: [MATRIX-SIG] Check this out!
Message-ID: <RG0JS6Tl5Tg6M>
LET US DO YOUR BULK MAILINGS!!!
..$350 PER MILLION ADDRESSES SENT
..$250 PER 1/2 MILLION ADDRESSES SENT
THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS!
Our company will do bulk emailing for your product/service.
Addresses are extracted daily by six of our computers,
which run 24 hours a day 7 days a week, scanning the net
for new addresses. Estimated 60-80,000 addresses extracted
daily. They are fresh! Over 40 million addresses on file.
No more than 2 pages (50 lines), no porn and no foul
language. $50 per page/25 lines per page beyond 2 pages.
We do not do targeted mailings at this price.
Targeted mailings:
$150 per 50,000 addresses extracted or less.
We can extract by country, occupation, organizations,
associations, product, etc. If we can not
search and extract what you need, then nobody can.
There are no lower prices on the net. Your mailing
can be done in a matter of hours. We have 6 computers
extracting addresses 24/7.
For the fastest service, cheapest prices and cleanest
mailings call our processing and new accounts office
at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is
busy, please keep trying, as bulk mailing is growing fast.
We do want to work with you to advertise your product.
To have your name removed, call our processing office.
Any negative responses will be dealt with accordingly.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Thu Jan 15 17:26:17 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 15 Jan 1998 09:26:17 -0800
Subject: [MATRIX-SIG] Compiling NumPy on Windows
Message-ID: <01bd21da$afde23c0$998a7380@pduboispc>
I'm trying to package up Konrad's version of NumPy so that it produces
dynamically-loadable DLL's under MSVC 5.0. I have no problem compiling
Python 1.5, and no problem making my own extensions that do not use NumPy.
When I try to compile NumPy's array object, either as a C or C++ file, I get
an error in arraytypes.c at this line:
PyArrayDescr *PyArrayDescrFromType(int type) {
The complaint it makes makes it clear that it thinks the second instance of
the pattern PyArrayDescr is meant to refer to the type PyArrayDescr, when in
fact it is part of a name. Indeed, if you change the name of the function
being defined to something else, it compiles this line without problems.
PyArrayDescr has exactly 14 characters in it, and I've heard of compilers
that only used 14 significant characters in an external name, although I
wouldn't expect C++ to work very well with such a limit. But I also haven't
heard anybody else say they had this problem.
Does anyone know anything about this?
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Jan 16 17:22:56 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 16 Jan 1998 18:22:56 +0100
Subject: [MATRIX-SIG] Compiling NumPy on Windows
In-Reply-To: <01bd21da$afde23c0$998a7380@pduboispc> (dubois1@llnl.gov)
Message-ID: <199801161722.SAA00605@lmspc1.ibs.fr>
> PyArrayDescr has exactly 14 characters in it, and I've heard of compilers
> that only used 14 significant characters in an external name, although I
> wouldn't expect C++ to work very well with such a limit. But I also haven't
> heard anybody else say they had this problem.
>
> Does anyone know anything about this?
I haven't seen any compiler with such a length restriction for a long
time (I think it was during my Atari ST days). For your entertainment,
here's a quote from the gcc man page on this subject:
-Wid-clash-len
Warn whenever two distinct identifiers match in the
first len characters. This may help you prepare a
program that will compile with certain obsolete,
brain-damaged compilers.
Of course this doesn't help you at all :-(
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Fri Jan 16 19:05:44 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Fri, 16 Jan 1998 20:05:44 +0100 (MET)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <199801161722.SAA00605@lmspc1.ibs.fr>
Message-ID: <Pine.PMDF.3.91.980116193910.650159707A-100000@Pap.UniVie.AC.AT>
Q: What is n/(n+1)?
A: 0
This is of course wrong for most practical purposes,
but it is the result Python will give.
I'm aware that I should have written n/(n+1.0), or
typcast, or been more careful in the first place,
and that there are historical reasons;
nevertheless I think the above behaviour is
most unfortunate for the following reasons:
* Bugs can creep into the code in no time.
Just leave out a .0 ... And the
chance is not bad, especially when copying
algorithms from textbooks.
* These errors are extremely hard to find, because
calculations will yield valid, albeit wrong, values.
And how can you ever be sure you have found all of them?
* Explicit typecasts and .0's all over the place make
algorithms hard to read and comparison with textbooks
difficult.
So, is there any way to change this behaviour?
Thank you,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From cgw@pgt.com Fri Jan 16 19:58:42 1998
From: cgw@pgt.com (Charles G Waldman)
Date: Fri, 16 Jan 98 14:58:42 EST
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.PMDF.3.91.980116193910.650159707A-100000@Pap.UniVie.AC.AT>
References: <199801161722.SAA00605@lmspc1.ibs.fr>
<Pine.PMDF.3.91.980116193910.650159707A-100000@Pap.UniVie.AC.AT>
Message-ID: <9801161958.AA22427@reactor.pgt>
Rupert Mazzucco writes:
> Q: What is n/(n+1)?
> A: 0
>
> This is of course wrong for most practical purposes,
> but it is the result Python will give.
> So, is there any way to change this behaviour?
>
This was brought up as an issue at the October conference. The
authors of "Alice", a Python-based interactive 3D graphics
environment intended for students, thought this behaviour unintiuitive
enough that they ship out Alice with a modified version of Python.
(Their modified version changes Python so that 1/2 == 0.5, which I
like, but they also made all symbols case-insensitive, which I think
is a terrible idea....). One of the guys from the Alice team got up
and asked what it would take to bring these changes into Python. But
as I remember it, the ensuing conversation centered around why it's a
bad idea to have X==x, and not on integer division. For what it's
worth, I agree with you that the default behavior is too influenced
by the corresponding behavior in C.
My own personal wishlist is that 1/2==0.5, and I'd also like to see
the silly "j" changed to an "i" ;-)
But I don't think either of these things is going to happen, unless
there is a groundswell of support.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From carlosm@moet.cs.colorado.edu Fri Jan 16 20:10:37 1998
From: carlosm@moet.cs.colorado.edu (Carlos Maltzahn)
Date: Fri, 16 Jan 1998 13:10:37 -0700 (MST)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.PMDF.3.91.980116193910.650159707A-100000@Pap.UniVie.AC.AT>
Message-ID: <Pine.SUN.3.93.980116130123.2818N-100000@moet.cs.colorado.edu>
I disagree:
Assuming n is an integer matrix. If you expect float results from matrix
operations you should have the matrices typed as float in the first
place. This would ensure that all operations result in floats.
Also, I've come across plenty of situations where I want integer division
with integer results. In these cases I would pay a big performance penalty
if Python would do float operations with results that I would have to
convert back to integers.
Carlos
On Fri, 16 Jan 1998, Rupert Mazzucco wrote:
> Q: What is n/(n+1)?
> A: 0
>
> This is of course wrong for most practical purposes,
> but it is the result Python will give.
> I'm aware that I should have written n/(n+1.0), or
> typcast, or been more careful in the first place,
> and that there are historical reasons;
> nevertheless I think the above behaviour is
> most unfortunate for the following reasons:
>
> * Bugs can creep into the code in no time.
> Just leave out a .0 ... And the
> chance is not bad, especially when copying
> algorithms from textbooks.
>
> * These errors are extremely hard to find, because
> calculations will yield valid, albeit wrong, values.
> And how can you ever be sure you have found all of them?
>
> * Explicit typecasts and .0's all over the place make
> algorithms hard to read and comparison with textbooks
> difficult.
>
> So, is there any way to change this behaviour?
>
> Thank you,
> Rupert Mazzucco
>
> _______________
> MATRIX-SIG - SIG on Matrix Math for Python
>
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> _______________
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Fri Jan 16 20:48:13 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 16 Jan 1998 12:48:13 -0800
Subject: [MATRIX-SIG] integer division -- what a concept!
Message-ID: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
There is a long-established history of this behavior in both Fortran and C.
People use it on purpose for lots of different applications. It would be a
surprise to most scientific programmers if it behaved otherwise.
Another way to look at it is, suppose you saw:
x = i / j
Wouldn't you be surprised that the type of x depended on the data?
The i vs. j for complex constants issue was well discussed in the SIG, and
it was simply necessary to choose one and annoy half the people, or choose
both and annoy Guido. There simply are two different cultures out there on
this issue.
-----Original Message-----
From: Charles G Waldman <cgw@pgt.com>
To: Rupert Mazzucco <maz@pap.univie.ac.at>
Cc: matrix-sig@python.org <matrix-sig@python.org>
Date: Friday, January 16, 1998 12:12 PM
Subject: [MATRIX-SIG] integer division -- what a concept!
>
>Rupert Mazzucco writes:
> > Q: What is n/(n+1)?
> > A: 0
> >
> > This is of course wrong for most practical purposes,
> > but it is the result Python will give.
>
> > So, is there any way to change this behaviour?
> >
>
>This was brought up as an issue at the October conference. The
>authors of "Alice", a Python-based interactive 3D graphics
>environment intended for students, thought this behaviour unintiuitive
>enough that they ship out Alice with a modified version of Python.
>(Their modified version changes Python so that 1/2 == 0.5, which I
>like, but they also made all symbols case-insensitive, which I think
>is a terrible idea....). One of the guys from the Alice team got up
>and asked what it would take to bring these changes into Python. But
>as I remember it, the ensuing conversation centered around why it's a
>bad idea to have X==x, and not on integer division. For what it's
>worth, I agree with you that the default behavior is too influenced
>by the corresponding behavior in C.
>
>My own personal wishlist is that 1/2==0.5, and I'd also like to see
>the silly "j" changed to an "i" ;-)
>
>But I don't think either of these things is going to happen, unless
>there is a groundswell of support.
>
>
>
>_______________
>MATRIX-SIG - SIG on Matrix Math for Python
>
>send messages to: matrix-sig@python.org
>administrivia to: matrix-sig-request@python.org
>_______________
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From furnish@xdiv.lanl.gov Fri Jan 16 20:56:25 1998
From: furnish@xdiv.lanl.gov (Geoffrey M. Furnish)
Date: Fri, 16 Jan 1998 20:56:25 GMT
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <9801161958.AA22427@reactor.pgt>
References: <199801161722.SAA00605@lmspc1.ibs.fr>
<Pine.PMDF.3.91.980116193910.650159707A-100000@Pap.UniVie.AC.AT>
<9801161958.AA22427@reactor.pgt>
Message-ID: <199801162056.UAA03631@twix.lanl.gov>
I just wasted 2.5 hours yesterday debuging an algorithm written in
Python, and this business of integer arithemetic is exactly what bit
me.
I also think the engineers got it wrong (should be i instead of j).
Charles G Waldman writes:
> My own personal wishlist is that 1/2==0.5, and I'd also like to see
> the silly "j" changed to an "i" ;-)
>
> But I don't think either of these things is going to happen, unless
> there is a groundswell of support.
--
Geoffrey Furnish email: furnish@lanl.gov
LANL XTM Radiation Transport/POOMA phone: 505-665-4529 fax: 505-665-5538
"Software complexity is an artifact of implementation." -Dan Quinlan
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From furnish@xdiv.lanl.gov Fri Jan 16 21:00:37 1998
From: furnish@xdiv.lanl.gov (Geoffrey M. Furnish)
Date: Fri, 16 Jan 1998 21:00:37 GMT
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.SUN.3.93.980116130123.2818N-100000@moet.cs.colorado.edu>
References: <Pine.PMDF.3.91.980116193910.650159707A-100000@Pap.UniVie.AC.AT>
<Pine.SUN.3.93.980116130123.2818N-100000@moet.cs.colorado.edu>
Message-ID: <199801162100.VAA03643@twix.lanl.gov>
Carlos Maltzahn writes:
> I disagree:
>
> Assuming n is an integer matrix. If you expect float results from matrix
> operations you should have the matrices typed as float in the first
> place. This would ensure that all operations result in floats.
Despite my prior post, I also agree with this. What hapened in my
case was that oe of the source terms to my algorithm /happeed/ to be
integer. That is to say, it came from some other facility which
returned data that it computed who kows how, and returned. Python
stuffed it into a variable, which it decided should be an int, and
then I used it downstream assuming it would be a float, but it
wasn't.
I suppose what bit me was really dynamic typing. Hmph.
--
Geoffrey Furnish email: furnish@lanl.gov
LANL XTM Radiation Transport/POOMA phone: 505-665-4529 fax: 505-665-5538
"Software complexity is an artifact of implementation." -Dan Quinlan
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From zcm@llnl.gov Fri Jan 16 21:03:32 1998
From: zcm@llnl.gov (Zane Motteler)
Date: Fri, 16 Jan 1998 13:03:32 -0800
Subject: No subject
Message-ID: <v0300782bb0e57a1c1330@[128.115.108.86]>
Carlos Maltzahn wrote:
>Assuming n is an integer matrix. If you expect float results from matrix
>operations you should have the matrices typed as float in the first
>place. This would ensure that all operations result in floats.
He's right. It is important to understand the distinction between what
is a float and what is an int. At the hardware level, ints and floats
have different representation and different operations--and the result
of an int-on-int operation is always an int.
Furthermore, I have reams and reams of code (graphics stuff) where I
do very heavy computation of subscripts and subscript arrays, computation
which frequently involves divides and mods. Subscripts have to be ints.
Which brings us to Carlos's second point:
>Also, I've come across plenty of situations where I want integer division
>with integer results. In these cases I would pay a big performance penalty
>if Python would do float operations with results that I would have to
>convert back to integers.
Precisely.
--Zane
-----------------------------------------------------------------
Zane C. Motteler, Ph. D.
Computer Scientist | Professor Emeritus of
Lawrence Livermore National | Computer Science and Engineering
Laboratory | California Polytechnic
P. O. Box 808, L-472 | State University
(7000 East Avenue, zip 94550) | San Luis Obispo, CA 93407
Livermore, CA 94551-9900 | zmottel@phoenix.csc.calpoly.edu
510/423-2143, FAX 423-9969 (Area code 925 after March 14, 1998)
zcm@llnl.gov
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From cgw@pgt.com Fri Jan 16 21:40:23 1998
From: cgw@pgt.com (Charles G Waldman)
Date: Fri, 16 Jan 98 16:40:23 EST
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
Message-ID: <9801162140.AA23313@reactor.pgt>
Paul F. Dubois writes:
> Another way to look at it is, suppose you saw:
>
> x = i / j
>
> Wouldn't you be surprised that the type of x depended on the data?
>
I really don't understand this comment. It seems to me that this is
the case currently; if I do
i=1; j=2; x= i/j; print type(x)
I get a different result than if I did
i=1; j=2.0; x=i/j; print type(x)
Isn't the type of x dependent on the data? (I'm not trying to be a
wise guy, I think I must be missing your point). Imagine that i and j
aren't defined in the code but are being read in from a file. Then
seeing the line "x = i/j" out of context, it's anybody's guess what
the type of "x" will be. I'd rather have division *always* return a
float, and maybe have another operator like "//" for explicit integer
division.
> The i vs. j for complex constants issue was well discussed in the SIG, and
> it was simply necessary to choose one and annoy half the people, or choose
> both and annoy Guido. There simply are two different cultures out there on
> this issue.
I understand that this is a cultural thing... I'm just expressing my
own biases, being more of a mathematician than an engineer. Euler
wrote "e**2 pi i + 1 = 0", not "e**2 pi j + 1 = 0". And that's good
enough for me. Besides, what if I decide to make quaternions a
built-in type in Python? (Just kidding.)
I guess I wasn't a member of the SIG yet when this was being
discussed. Too bad, I would have agitated for "i". But I certainly
don't think it's an important issue; I was only bringing it up under
the rubric of "the only things about Python that I think are wrong",
becuase I believe that in most everything else Guido got it right.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From zcm@llnl.gov Fri Jan 16 22:14:32 1998
From: zcm@llnl.gov (Zane Motteler)
Date: Fri, 16 Jan 1998 14:14:32 -0800
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <9801162140.AA23313@reactor.pgt>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
<01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
Message-ID: <v0300782cb0e58aacf6e9@[128.115.108.86]>
Charles,
You wrote
>Paul F. Dubois writes:
>
> > Another way to look at it is, suppose you saw:
> >
> > x = i / j
> >
> > Wouldn't you be surprised that the type of x depended on the data?
> >
>
>I really don't understand this comment.
...<snip>...
I think I know what Paul was trying to say (I better, I've been
working for him for 12 years ;-).
If i and j are the same type, then the "principle of least surprise"
says that x should be of the same type as i and j. If they are of
different types, then the outcome of course depends on the rule
of coercion, but generally one would expect x to be of the same
type as either i or j. To me at least (and I've been in computing
for 41 years now) it seems counterintuitive that the result of an
operation would be of a different type than either operand.
--Zane
-----------------------------------------------------------------
Zane C. Motteler, Ph. D.
Computer Scientist | Professor Emeritus of
Lawrence Livermore National | Computer Science and Engineering
Laboratory | California Polytechnic
P. O. Box 808, L-472 | State University
(7000 East Avenue, zip 94550) | San Luis Obispo, CA 93407
Livermore, CA 94551-9900 | zmottel@phoenix.csc.calpoly.edu
510/423-2143, FAX 423-9969 (Area code 925 after March 14, 1998)
zcm@llnl.gov
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Carlos Maltzahn <carlosm@moet.cs.colorado.edu> Fri Jan 16 22:40:39 1998
From: Carlos Maltzahn <carlosm@moet.cs.colorado.edu> (Carlos Maltzahn)
Date: Fri, 16 Jan 1998 15:40:39 -0700 (MST)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <9801162140.AA23313@reactor.pgt>
Message-ID: <Pine.SUN.3.93.980116153709.2818S-100000@moet.cs.colorado.edu>
On Fri, 16 Jan 1998, Charles G Waldman wrote:
>
> Paul F. Dubois writes:
>
> > Another way to look at it is, suppose you saw:
> >
> > x = i / j
> >
> > Wouldn't you be surprised that the type of x depended on the data?
> >
>
> I really don't understand this comment. It seems to me that this is
> the case currently; if I do
>
> i=1; j=2; x= i/j; print type(x)
>
> I get a different result than if I did
>
> i=1; j=2.0; x=i/j; print type(x)
>
> Isn't the type of x dependent on the data? (I'm not trying to be a
I don't understand this example either. Even if x is typed the result
would depend on whether i and j are both integer (matrix) variables or
not.
> wise guy, I think I must be missing your point). Imagine that i and j
> aren't defined in the code but are being read in from a file. Then
> seeing the line "x = i/j" out of context, it's anybody's guess what
> the type of "x" will be. I'd rather have division *always* return a
> float, and maybe have another operator like "//" for explicit integer
> division.
I think the real issue is how you treat data import into a dynamically
typed environment and not whether we should have an extra operator for
explicit integer division (or all the other arithmetic operators for that
matter). As far as I know, NumPy lets you specify the type of matrix at
creation time. If you always specify the type of matrices at creation time
you would avoid any problems with integer division (unless your matrix
typing is wrong).
Geoffrey Furnish writes:
> I suppose what bit me was really dynamic typing. Hmph.
I agree.
Carlos
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From cgw@pgt.com Fri Jan 16 23:18:00 1998
From: cgw@pgt.com (Charles G. Waldman)
Date: Fri, 16 Jan 98 18:18 EST
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <v0300782cb0e58aacf6e9@[128.115.108.86]>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
<9801162140.AA23313@reactor.pgt>
<v0300782cb0e58aacf6e9@[128.115.108.86]>
Message-ID: <m0xtL2P-000e1bC@sirius>
Zane Motteler writes:
>
> To me at least (and I've been in computing
> for 41 years now) it seems counterintuitive that the result of an
> operation would be of a different type than either operand.
>
> --Zane
I respect your experience and opinions. To me, trained as a
mathematician, "integer division" is kind of a troublesome notion.
The integers are a commutative ring, not a field. There is no
"division" until we extend the ring to a field by adjoining the
rationals. The function div(x,y) that thinks div(1,2)==0 isn't really
anything I would call "division"; although I understand very well that
this is the traditional thinking in computing.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Fri Jan 16 23:45:01 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 00:45:01 +0100 (MET)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.SUN.3.93.980116130123.2818N-100000@moet.cs.colorado.edu>
Message-ID: <Pine.PMDF.3.91.980117003641.650158746A-100000@Pap.UniVie.AC.AT>
On Fri, 16 Jan 1998, Carlos Maltzahn wrote:
> I disagree:
>
> Assuming n is an integer matrix. If you expect float results from matrix
> operations you should have the matrices typed as float in the first
> place. This would ensure that all operations result in floats.
I'm afraid I don't quite get your point. If I write e.g.
dphi = zeros(( max,), Complex )
...
for n in xrange( 1, max ):
dphi[n] = phi[n-1] - ( n / ( n+1 )) * phi[n]
^^^^^^^^^^^
how would "typing my matrices as float in the first place" help?
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Fri Jan 16 23:58:33 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 00:58:33 +0100 (MET)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
Message-ID: <Pine.PMDF.3.91.980117004833.650158746B-100000@Pap.UniVie.AC.AT>
On Fri, 16 Jan 1998, Paul F. Dubois wrote:
> There is a long-established history of this behavior in both Fortran and C.
As I said, I'm aware of this.
But both Fortran and C are *old* languages.
Wasn't Python set to be a *modern* language
and easy-to-learn?
Experienced programmers may be know that 2/3 == 0,
and even make use of it; nevertheless this behaviour is
guaranteed to confuse beginners. And it introduces
a possibility for errors that are really hard to find.
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Sat Jan 17 00:26:29 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 01:26:29 +0100 (MET)
Subject: [MATRIX-SIG] Re: int. division
In-Reply-To: <v0300782bb0e57a1c1330@[128.115.108.86]>
Message-ID: <Pine.PMDF.3.91.980117005959.650158746C-100000@Pap.UniVie.AC.AT>
On Fri, 16 Jan 1998, Zane Motteler wrote:
> It is important to understand the distinction between what
> is a float and what is an int. At the hardware level, ints and floats
What do you mean, hardware level? Python is supposed to be a
dynamically typed OO language, abstraction, encapsulation,
all that stuff. Hardware level doesn't seem to be a particularly
strong argument in this case.
> have different representation and different operations--and the result
> of an int-on-int operation is always an int.
But even the Babylonians had some notion of rational numbers already.
It's high time modern programming languages catch up with them!
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From carlosm@moet.cs.colorado.edu Sat Jan 17 00:29:58 1998
From: carlosm@moet.cs.colorado.edu (Carlos Maltzahn)
Date: Fri, 16 Jan 1998 17:29:58 -0700 (MST)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.PMDF.3.91.980117003641.650158746A-100000@Pap.UniVie.AC.AT>
Message-ID: <Pine.SUN.3.93.980116171512.2818W-100000@moet.cs.colorado.edu>
On Sat, 17 Jan 1998, Rupert Mazzucco wrote:
> On Fri, 16 Jan 1998, Carlos Maltzahn wrote:
>
> > I disagree:
> >
> > Assuming n is an integer matrix. If you expect float results from matrix
> > operations you should have the matrices typed as float in the first
> > place. This would ensure that all operations result in floats.
>
> I'm afraid I don't quite get your point. If I write e.g.
>
> dphi = zeros(( max,), Complex )
> ...
> for n in xrange( 1, max ):
> dphi[n] = phi[n-1] - ( n / ( n+1 )) * phi[n]
> ^^^^^^^^^^^
> how would "typing my matrices as float in the first place" help?
It wouldn't. My point was that integer division can hurt you if you aren't
sure of the argument types of a division. In your example it is very
clear what n is: an integer loop variable. I would be very surprised if
the subexpression ( n / ( n+1 )) would result in a float since it
obviously only consists of integers. But that might be because I'm a
computer scientist and not a mathematician.
Carlos
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Sat Jan 17 00:37:12 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 01:37:12 +0100 (MET)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <v0300782cb0e58aacf6e9@[128.115.108.86]>
Message-ID: <Pine.PMDF.3.91.980117012754.650158746D-100000@Pap.UniVie.AC.AT>
On Fri, 16 Jan 1998, Zane Motteler wrote:
> If i and j are the same type, then the "principle of least surprise"
> says that x should be of the same type as i and j. If they are of
> different types, then the outcome of course depends on the rule
> of coercion, but generally one would expect x to be of the same
> type as either i or j. To me at least (and I've been in computing
> for 41 years now) it seems counterintuitive that the result of an
> operation would be of a different type than either operand.
It might seem you are somehow trapped by being a computer scientist
for a long time. I'm sure a beginner will find 1/2 == 0.5 less
surprising than 1/2 == 0, and the resulting different type
argument doesn't hold in a dynamically typed language.
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From phil@geog.ubc.ca Sat Jan 17 00:47:04 1998
From: phil@geog.ubc.ca (Phil Austin)
Date: Fri, 16 Jan 1998 16:47:04 -0800
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.PMDF.3.91.980117004833.650158746B-100000@Pap.UniVie.AC.AT>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
<Pine.PMDF.3.91.980117004833.650158746B-100000@Pap.UniVie.AC.AT>
Message-ID: <199801170047.QAA04428@curlew.geog.ubc.ca>
>>>>> "Rupert" == Rupert Mazzucco <maz@pap.univie.ac.at> writes:
Rupert> As I said, I'm aware of this. But both Fortran and C are
Rupert> *old* languages. Wasn't Python set to be a *modern*
Rupert> language and easy-to-learn?
Two examples from the competition:
<phil@peacock: /home/phil> matlab
>>
>> 5/4
5/4
ans =
1.2500
<phil@peacock: /home/phil> Splus
> 5/4
5/4
[1] 1.25
Phil
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Sat Jan 17 01:02:52 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 02:02:52 +0100 (MET)
Subject: [MATRIX-SIG] hardware level, you say?
In-Reply-To: <Pine.SUN.3.93.980116171512.2818W-100000@moet.cs.colorado.edu>
Message-ID: <Pine.PMDF.3.91.980117014842.650158746E-100000@Pap.UniVie.AC.AT>
It's me again. To clarify my point, let me cite from www.python.org,
from the section entitled _What is Python?_. It says there
Python combines remarkable power with very clear syntax. It has
modules, classes, exceptions, very high level dynamic data types,
and dynamic typing.
Sounds good, doesn't it? Unfortunately the aspiring Pythoner
will soon find itself thrown back to the level of Fortran.
Don't get me wrong, Fortran is OK, but it's already there.
No need to invent *that* old wheel again. But if we have
a brand new car here, couldn't we have a set of new wheels for it?
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From cgw@pgt.com Sat Jan 17 04:00:00 1998
From: cgw@pgt.com (Charles G. Waldman)
Date: Fri, 16 Jan 98 23:00 EST
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <v0300782cb0e58aacf6e9@[128.115.108.86]>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
<9801162140.AA23313@reactor.pgt>
<v0300782cb0e58aacf6e9@[128.115.108.86]>
Message-ID: <m0xtPRH-000e1bC@sirius>
Zane Motteler writes:
> If i and j are the same type, then the "principle of least surprise"
> says that x should be of the same type as i and j.
To me, the "principle of least surprise" (and high-school algebra)
says that if b != 0, then b*(a/b) should be equal to a. Values are
(to me) more important than types. If we were to insist that division
always promotes its operands to float before dividing, and returns a
float, then 2*(1/2) returns 1.0, which, although not the same type as
the integer 1, represents the same value. If you insist on being
type-centric, then 2*(1/2)==0 is true, which seems far weirder to me.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Sat Jan 17 10:07:33 1998
From: beach@verinet.com (David J. C. Beach)
Date: Sat, 17 Jan 1998 03:07:33 -0700
Subject: [MATRIX-SIG] Re: int. division
References: <Pine.PMDF.3.91.980117005959.650158746C-100000@Pap.UniVie.AC.AT>
Message-ID: <34C082E5.74736A7@verinet.com>
Rupert Mazzucco wrote:
> What do you mean, hardware level? Python is supposed to be a
> dynamically typed OO language, abstraction, encapsulation,
> all that stuff. Hardware level doesn't seem to be a particularly
> strong argument in this case.
Although the hardware level storage of ints and floats is indeed very
different, that is not actually the issue. The issue here is type
preservation.
Have none of you people (those who believe that 1/2 should be 0.5) ever
done any system level programming? Have you ever worked with any graphics
code? Have you ever actually needed integer division for anything you ever
wrote? If the answer is no, then I can only assume that you think that
_features_ which are not immediately useful to you should be removed from
the language.
Allow me to reiterate Paul Dubois's argument. Consider the code:
x = i / j
Now, suppose i=2 and j=4. Then x will be the integer, 2. Everybody agrees
on this. But suppose i=1 and j=2. Then x, one argues, should be the FLOAT
0.5.
Does anybody understand why this is a VeryBadThing(tm)? It is for two
reasons:
1) the type of x (int or float) depends on the values (not just the types)
of i and j.
2) there is no way to do integer division, which (while confusing to
mathematicians who only use math programming languages which tend to
interpret everything either symbolically or as floats) is
VERY NECESSARY FOR MANY OTHER PURPOSES.
But there _is_ a way that we can make it so that everybody can still get
their respective jobs done. How do we do this? simple:
If you want to do operations on integers, use only integers, and you will
get an integer result. If you want to do operations with float results,
use float arguments.
This does have the unfortunate side-effect of actually requiring one to
think about which type of numbers (s)he wants to use before hacking away.
Program with care.
> But even the Babylonians had some notion of rational numbers already.
> It's high time modern programming languages catch up with them!
And it's high time you caught up with modern programming languages. Yes,
even a humble integer-division supporting language like Python gives you
this ability. Through the wonderful techniques of aggregation and
encapsulation, you could certainly talk about rational numbers:
class Rational:
def __init__(self, p, q):
self.p, self.q = int(p), int(q)
def __repr__(self):
return "%i/%i" % (self.p, self.q)
etc...
(You could add all the operators, along with code to keep p and q in a
reduced form. You could even use long integers, which would yield a very
precise Rational type.)
Isn't *that* what OO is all about?
BTW, while I know I sound biased, I hold a double B.S. in computer science
and applied mathematics, so I'm not really here to anger any
mathematicians. I simply believe that integer division is a necessary and
important part of Python. I think that anybody who has a well rounded
programming background would understand why.
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Sat Jan 17 10:13:50 1998
From: beach@verinet.com (David J. C. Beach)
Date: Sat, 17 Jan 1998 03:13:50 -0700
Subject: [MATRIX-SIG] integer division -- what a concept!
References: <Pine.PMDF.3.91.980117012754.650158746D-100000@Pap.UniVie.AC.AT>
Message-ID: <34C0845E.97C3C742@verinet.com>
Rupert Mazzucco wrote:
> It might seem you are somehow trapped by being a computer scientist
> for a long time. I'm sure a beginner will find 1/2 == 0.5 less
> surprising than 1/2 == 0, and the resulting different type
> argument doesn't hold in a dynamically typed language.
Yes, Rupert. I'm sure that a beginner would also find the concept of
polymorphism confusing, but that doesn't mean I think we should take it
out of the language.
You see, most beginners haven't done any programming where they'd need
integer division. So naturally, when stumbling upon it, the beginner
finds it absurd. That doesn't mean that integer division isn't necessary
and useful.
Dave
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Sat Jan 17 11:50:27 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 12:50:27 +0100 (MET)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <34C0845E.97C3C742@verinet.com>
Message-ID: <Pine.PMDF.3.91.980117122803.650162719A-100000@Pap.UniVie.AC.AT>
On Sat, 17 Jan 1998, David J. C. Beach wrote:
> Yes, Rupert. I'm sure that a beginner would also find the concept of
> polymorphism confusing, but that doesn't mean I think we should take it
> out of the language.
This is not the same kind of confusion. A beginner may find the
concept of polymorphism *difficult to learn*, yes. But people are
not preoccupied with some different meaning.
Division, however, is taught in school, and people learn
that 1/2 == 0.5. Confusion arises if this is suddenly not
true anymore, for obscure -take that literally!- reasons.
> You see, most beginners haven't done any programming where they'd need
> integer division. So naturally, when stumbling upon it, the beginner
> finds it absurd. That doesn't mean that integer division isn't necessary
> and useful.
While I doubt the _necessary_, I'm sure you can put it to good use.
I'm only concerned about numerical errors that may creep into the code.
Maybe there could be a flag to turn on a runtime warning?
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Sat Jan 17 12:52:31 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 13:52:31 +0100 (MET)
Subject: [MATRIX-SIG] Re: int. division
In-Reply-To: <34C082E5.74736A7@verinet.com>
Message-ID: <Pine.PMDF.3.91.980117125208.650162719B-100000@Pap.UniVie.AC.AT>
[long posting, maybe interesting (?) suggestion at the end]
On Sat, 17 Jan 1998, David J. C. Beach wrote:
> Have none of you people (those who believe that 1/2 should be 0.5) ever
> done any system level programming? Have you ever worked with any graphics
Actually, I would do system level stuff in C. I thought Python was
meant to be more a kind of high-level language.
> code? Have you ever actually needed integer division for anything you ever
> wrote? If the answer is no, then I can only assume that you think that
> _features_ which are not immediately useful to you should be removed from
> the language.
No, I'm not *that* egoistic :-) But I find that this particular
_useful feature_ is actually quite problematic.
> x = i / j
>
> Now, suppose i=2 and j=4. Then x will be the integer, 2. Everybody agrees
> on this. But suppose i=1 and j=2. Then x, one argues, should be the FLOAT
> 0.5.
But such is life. Suppose two people have four whole apples. If they
divide them, each one will get two whole apples. OK. Now suppose they
had three whole apples they want to divide. How do we do that, they ask
themselves? After scratching their heads for a while, each one takes
one whole apple, and the remaining apple they cut in two halves.
I think most people would agree that this is a more sensible solution,
than to throw the third apple away. And this kind of solution is not new.
[pragraph paraphrased, hopefully correctly]
> ... integer division is ... VERY NECESSARY FOR MANY OTHER PURPOSES.
> But there _is_ a way that we can make it so that everybody can still get
> their respective jobs done. How do we do this? simple:
> ...
> Program with care.
Now this leads exactly to the point I'm trying to make.
Even if you _program with care_, how can you ever be sure
you have been careful *enough*? If somewhere (n+1) slipped
into the code instead of (n+1.0), the numerical results
may be wrong. Yet this kind of bug is very difficult
to detect in the first place and hard to find in the second.
I would really appreciate some help from Python here.
> [insightful solution, but for a different problem, snipped]
> Isn't *that* what OO is all about?
>
> BTW, while I know I sound biased, I hold a double B.S. in computer science
> and applied mathematics, so I'm not really here to anger any
> mathematicians. I simply believe that integer division is a necessary and
> important part of Python. I think that anybody who has a well rounded
> programming background would understand why.
Hm, I don't know much about the internals of python, but IMHO the problem
I'm talking about really arises if you have expressions like
I[n] = float1 + ( n / ( n+1 )) * float2
Maybe this could be evaluated differently, so that the interpreter
sees we're really talking about floats here and does the correct
conversion for n/(n+1) *before* dividing? (because I is typed float,
that is, not primarily because of float1 or float2)
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From maz@pap.univie.ac.at Sat Jan 17 15:31:41 1998
From: maz@pap.univie.ac.at (Rupert Mazzucco)
Date: Sat, 17 Jan 1998 16:31:41 +0100 (MET)
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <199801170047.QAA04428@curlew.geog.ubc.ca>
Message-ID: <Pine.PMDF.3.91.980117162837.650162543B-100000@Pap.UniVie.AC.AT>
On Fri, 16 Jan 1998, Phil Austin wrote:
> Two examples from the competition:
>
> <phil@peacock: /home/phil> matlab
> >> 5/4
> 5/4
> ans =
> 1.2500
>
> <phil@peacock: /home/phil> Splus
> > 5/4
> 5/4
> [1] 1.25
or take Perl:
print 5/4 ;
1.25
Regards,
Rupert Mazzucco
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hohn@math.utah.edu Sat Jan 17 17:44:57 1998
From: hohn@math.utah.edu (Michael Hohn)
Date: Sat, 17 Jan 1998 10:44:57 -0700 (MST)
Subject: [MATRIX-SIG] Re: int. division
In-Reply-To: <Pine.PMDF.3.91.980117125208.650162719B-100000@Pap.UniVie.AC.AT>
(message from Rupert Mazzucco on Sat, 17 Jan 1998 13:52:31 +0100
(MET))
Message-ID: <199801171744.KAA13094@sunscreen.math.utah.edu>
>> ...
>>
>> Now this leads exactly to the point I'm trying to make.
>> Even if you _program with care_, how can you ever be sure
>> you have been careful *enough*? If somewhere (n+1) slipped
>> into the code instead of (n+1.0), the numerical results
>> may be wrong. Yet this kind of bug is very difficult
>> to detect in the first place and hard to find in the second.
>> I would really appreciate some help from Python here.
>>
>> ...
The point about being careful enough is well taken. In using
FORTRASH, I had all kinds of problems with unwanted behavior, until
someone pointed me to the ultimate fortran tool: ftnchek.
Among many other things, it points out type inconsistencies.
And for C, lint and variants (especially lclint, at
http://larch-www.lcs.mit.edu:8001/larch/lclint/ ) do a similar job.
Note that no one (at least not recently) has proposed to make C or
FORTRAN "safer" for beginners by removing language features; instead,
people provide warning tools.
Maybe "plint" would be a useful thing?
Cheers,
Mike
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Sat Jan 17 17:56:15 1998
From: beach@verinet.com (David J. C. Beach)
Date: Sat, 17 Jan 1998 10:56:15 -0700
Subject: [MATRIX-SIG] integer division -- what a concept!
References: <Pine.PMDF.3.91.980117162837.650162543B-100000@Pap.UniVie.AC.AT>
Message-ID: <34C0F0BF.301E7A44@verinet.com>
Rupert Mazzucco wrote:
> > Two examples from the competition:
> >
> > <phil@peacock: /home/phil> matlab
> > >> 5/4
> > 5/4
> > ans =
> > 1.2500
> >
> > <phil@peacock: /home/phil> Splus
> > > 5/4
> > 5/4
> > [1] 1.25
>
That's funny, I've never seen anybody do *any* system programming in
matlab or Splus... In fact, I think that those languages are used
almost exclusively by mathematicians. And whadya know? I think we may
have stumbled across the reason why.
You see, you're just looking to change Python in a way that's only
useful for people who do mathematics. As far as you're concerned, those
features you don't use (e.g. integer division) have no purpose, so we
might as well remove them, right? I'm not convinced at all (especially
since I need and use integer division in python.)
Suppose you have three cars that you want to divide among two people.
(There are some things in this world that it's just not a good idea to
divide, and not all math is done with apples....sometimes it's done with
bits and bytes.)
> or take Perl:
>
> print 5/4 ;
> 1.25
Yes, but you forget that Perl doesn't differentiate it's scalar types at
all. You can do something like this, too:
$x = "5"; # the string "5"
print $x; #prints the string "5"
print $x + 1; # prints the integer 6
Perl just doesn't care. It will try to interpret any scalar "type" in
almost any way possible so that the operation you can work. If you
would like to make python much more error prone, we could adopt this
policy. Unfortunately, it is the source of many many errors in perl,
and probably a bad thing in python.
consider:
x = '5'
print x # prints the string '5'
print x + 1 # error! can't add a string to an int
If you really like the perl way better, go ahead and use perl. My guess
is that -- truth be told -- you don't.
If you have a function, foo, and you want to make sure that it is
getting floats as it's arguments, you can always either test the
arguments, or:
def foo(x, y): # x and y need to be floats
x, y = float(x), float(y)
# at this point, x and y are either floats, or an exception was
raised
# now, go about your usual business with confidence that operations
# involving x and y will return floats (principle of least surprise)
Dave
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Sat Jan 17 18:12:10 1998
From: beach@verinet.com (David J. C. Beach)
Date: Sat, 17 Jan 1998 11:12:10 -0700
Subject: [MATRIX-SIG] Re: int. division
References: <Pine.PMDF.3.91.980117125208.650162719B-100000@Pap.UniVie.AC.AT>
Message-ID: <34C0F47A.F2B2D32D@verinet.com>
Rupert Mazzucco wrote:
> I[n] = float1 + ( n / ( n+1 )) * float2
>
> Maybe this could be evaluated differently, so that the interpreter
> sees we're really talking about floats here and does the correct
> conversion for n/(n+1) *before* dividing? (because I is typed float,
> that is, not primarily because of float1 or float2)
This isn't generally a good, though. Asignment in python can change (or define)
the type of a scalar variable.
If x is a free variable (has not yet beed used),
x = 3/4
is entirely unclear. x doesn't have a type yet, so I don't know whether to do
0.75 == 3.0/4.0 or 0 == 3/4
In any case, I'm going to stop arguing here. If you feel very strongly about
3/4==0.75, you can talk to Guido about it and see if he'll change it. My guess
is that he will tell you, "sorry, 'fraid not" because Guido is reasonably
committed to keeping existing python programs compatible with new python
features. Such a change would break a tremendous amount of existing code.
Dave
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From cgw@pgt.com Sat Jan 17 18:31:00 1998
From: cgw@pgt.com (Charles G. Waldman)
Date: Sat, 17 Jan 98 13:31 EST
Subject: [MATRIX-SIG] Re: int. division
In-Reply-To: <34C082E5.74736A7@verinet.com>
References: <Pine.PMDF.3.91.980117005959.650158746C-100000@Pap.UniVie.AC.AT>
<34C082E5.74736A7@verinet.com>
Message-ID: <m0xtd1u-000e3KC@sirius>
David J. C. Beach writes:
>
> Allow me to reiterate Paul Dubois's argument. Consider the code:
>
> x = i / j
>
> Now, suppose i=2 and j=4. Then x will be the integer, 2. Everybody agrees
> on this.
Well, not everybody. I would have 2/4 == 2.0 and 2//4 == 2
I think these are different mathematical operations; in one view,
division is an "inverse operation" to multiplication, just as
subtraction is the inverse operation to addition; just as
(-B) + A + B == A for all A and B
I expect
(1/B) * A*B == A for all nonzero B
[at least up to the limits of machine representation of real numbers]
In the other view, division is the solution of the equation
xa + r = b, r<b
for an integer x, given integers a and b.
Both of these are useful notions and I'm not proposing we take any
feature out of the language, I would simply acknowledge that these two
are not the same operation and distinguish them with different
symbols.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jhsh@iafrica.com Sun Jan 18 06:38:45 1998
From: jhsh@iafrica.com (Jannie Hofmeyr)
Date: Sun, 18 Jan 1998 08:38:45 +0200
Subject: [MATRIX-SIG] A wrapper for odepack routines?
Message-ID: <34C1A375.76AD5708@iafrica.com>
Before I inadvertently re-invent the wheel, does anyone know of or have
a Python wrapper for the Livermore ODE solvers in odepack (LSODA,
LSODE)? Since the LLNL gurus have been very active in numerical Python I
am optimistic :-)
Jannie
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From beach@verinet.com Sun Jan 18 11:14:21 1998
From: beach@verinet.com (David J. C. Beach)
Date: Sun, 18 Jan 1998 04:14:21 -0700
Subject: [MATRIX-SIG] Re: int. division
References: <Pine.PMDF.3.91.980117005959.650158746C-100000@Pap.UniVie.AC.AT>
<34C082E5.74736A7@verinet.com> <m0xtd1u-000e3KC@sirius>
Message-ID: <34C1E40C.94DDDA3E@verinet.com>
Charles G. Waldman wrote:
> David J. C. Beach writes:
> >
> > Allow me to reiterate Paul Dubois's argument. Consider the code:
> >
> > x = i / j
> >
> > Now, suppose i=2 and j=4. Then x will be the integer, 2. Everybody agrees
> > on this.
>
> Well, not everybody. I would have 2/4 == 2.0 and 2//4 == 2
Perhaps the truly funny thing here is that 2.0/4.0 = 1.0/2.0 = 0.5. (WHOOPS!)
It's a known fact that mathematicians can't do simple arithmetic. For the
record, what we *meant* to say is that 4.0/2.0 = 2.0
Dave
--
David J. C. Beach
Colorado State University
mailto:beach@verinet.com
http://www.verinet.com/~beach
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Mon Jan 19 13:22:43 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 19 Jan 1998 14:22:43 +0100
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.PMDF.3.91.980116193910.650159707A-100000@Pap.UniVie.AC.AT>
(message from Rupert Mazzucco on Fri, 16 Jan 1998 20:05:44 +0100
(MET))
Message-ID: <199801191322.OAA15889@lmspc1.ibs.fr>
> Q: What is n/(n+1)?
> A: 0
Evidently everybody has had a lot of fun during the weekend discussing
this problem, so I can't resist joining in ;-)
What has happened on the Matrix SIG is a collision of two world views:
1) The various number representation are different data types, and
should behave according to some generally accepted rules for
type consistency. This is the view taken by C, Fortran, Python, etc.
2) There is just one data type "number", and the various representations
are only implementation details that shouldn't influence the
definition of mathematical operations or their outcome. This
is the view taken by APL, Matlab, etc.
Having done both science and systems programming, I can sympathize
with both views. And Python could easily support both; it would be an
easy exercise to implement a new data type "number" that behaves like
most mathematicians and scientists would expect. Yet it wouldn't
solve the problems people have, because number constants would still
be of types "int" or "float", not of type "number".
My ideal language would treat all numbers as being of one type by
default, but provide special "integer" and "float" types whose
constants are marked by some prefix or postfix. The reason for
choosing the "number" approach as the default is that this corresponds
to what most newcomers to programming expect from their math classes.
Neverthless I hope that Python's approach will not change, for the
simple reason of compatibility. We'll have to live with the fact
that Python is not perfect - just better than other languages ;-)
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From amullhau@ix.netcom.com Mon Jan 19 16:32:09 1998
From: amullhau@ix.netcom.com (Andrew P. Mullhaupt)
Date: Mon, 19 Jan 1998 11:32:09 -0500
Subject: [MATRIX-SIG] integer division -- what a concept!
Message-ID: <000f01bd253e$2510cce0$d1615ecf@amullhau.ix.netcom.com>
-----Original Message-----
From: Konrad Hinsen <hinsen@ibs.ibs.fr>
To: maz@pap.univie.ac.at <maz@pap.univie.ac.at>
Cc: matrix-sig@python.org <matrix-sig@python.org>
Date: Monday, January 19, 1998 8:46 AM
Subject: Re: [MATRIX-SIG] integer division -- what a concept!
>Neverthless I hope that Python's approach will not change, for the
>simple reason of compatibility. We'll have to live with the fact
>that Python is not perfect - just better than other languages ;-)
Me too.
Later,
Andrew Mullhaupt
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From turner@blueskystudios.com Tue Jan 20 01:19:51 1998
From: turner@blueskystudios.com (John Turner)
Date: Mon, 19 Jan 1998 20:19:51 -0500
Subject: [MATRIX-SIG] Re: int. division
In-Reply-To: <m0xtd1u-000e3KC@sirius>
References: <Pine.PMDF.3.91.980117005959.650158746C-100000@Pap.UniVie.AC.AT>
<34C082E5.74736A7@verinet.com>
<m0xtd1u-000e3KC@sirius>
Message-ID: <199801200119.UAA08003@oneida>
Charles G. Waldman writes:
>
> David J. C. Beach writes:
> >
> > Allow me to reiterate Paul Dubois's argument. Consider the
> > code:
> >
> > x = i / j
> >
> > Now, suppose i=2 and j=4. Then x will be the integer, 2.
> > Everybody agrees on this.
>
> Well, not everybody. I would have 2/4 == 2.0 and 2//4 == 2
Call me crazy, but somehow I'm not comfortable with the result of 2/4
being either 2 *or* 2.0...
:)
--
John A. Turner mailto:turner@blueskystudios.com
Senior Research Associate http://www.blueskystudios.com
Blue Sky | VIFX http://www.vifx.com
One South Road, Harrison, NY 10528 http://www.lanl.gov/home/turner
Phone: 914-381-8400 Fax: 914-381-9790/1
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From furnish@xdiv.lanl.gov Tue Jan 20 15:14:03 1998
From: furnish@xdiv.lanl.gov (Geoffrey M. Furnish)
Date: Tue, 20 Jan 1998 15:14:03 GMT
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.PMDF.3.91.980117004833.650158746B-100000@Pap.UniVie.AC.AT>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
<Pine.PMDF.3.91.980117004833.650158746B-100000@Pap.UniVie.AC.AT>
Message-ID: <199801201514.PAA06751@twix.lanl.gov>
Rupert Mazzucco writes:
> On Fri, 16 Jan 1998, Paul F. Dubois wrote:
>
> > There is a long-established history of this behavior in both Fortran and C.
>
> As I said, I'm aware of this.
> But both Fortran and C are *old* languages.
> Wasn't Python set to be a *modern* language
> and easy-to-learn?
>
> Experienced programmers may be know that 2/3 == 0,
> and even make use of it; nevertheless this behaviour is
> guaranteed to confuse beginners. And it introduces
> a possibility for errors that are really hard to find.
And it confused me too, though I am hardly a newbie, b/c I didn't
actually know that my two and my three, were integers. I have
littered my code now with float(x) and float(y), to promote my input
variables to the right type, but I have to say, this is hideously
ugly.
I suppose in the final analysis, I am really not a fa of dyamic
typing.
I am also not a fan of keyboards that don't reliably transmit the n
key...
--
Geoffrey Furnish email: furnish@lanl.gov
LANL XTM Radiation Transport/POOMA phone: 505-665-4529 fax: 505-665-5538
"Software complexity is an artifact of implementation." -Dan Quinlan
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From furnish@xdiv.lanl.gov Tue Jan 20 15:14:03 1998
From: furnish@xdiv.lanl.gov (Geoffrey M. Furnish)
Date: Tue, 20 Jan 1998 15:14:03 GMT
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <Pine.PMDF.3.91.980117004833.650158746B-100000@Pap.UniVie.AC.AT>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
<Pine.PMDF.3.91.980117004833.650158746B-100000@Pap.UniVie.AC.AT>
Message-ID: <199801201514.PAA06751@twix.lanl.gov>
Rupert Mazzucco writes:
> On Fri, 16 Jan 1998, Paul F. Dubois wrote:
>
> > There is a long-established history of this behavior in both Fortran and C.
>
> As I said, I'm aware of this.
> But both Fortran and C are *old* languages.
> Wasn't Python set to be a *modern* language
> and easy-to-learn?
>
> Experienced programmers may be know that 2/3 == 0,
> and even make use of it; nevertheless this behaviour is
> guaranteed to confuse beginners. And it introduces
> a possibility for errors that are really hard to find.
And it confused me too, though I am hardly a newbie, b/c I didn't
actually know that my two and my three, were integers. I have
littered my code now with float(x) and float(y), to promote my input
variables to the right type, but I have to say, this is hideously
ugly.
I suppose in the final analysis, I am really not a fa of dyamic
typing.
I am also not a fan of keyboards that don't reliably transmit the n
key...
--
Geoffrey Furnish email: furnish@lanl.gov
LANL XTM Radiation Transport/POOMA phone: 505-665-4529 fax: 505-665-5538
"Software complexity is an artifact of implementation." -Dan Quinlan
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Tue Jan 20 15:29:46 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 20 Jan 1998 07:29:46 -0800
Subject: [MATRIX-SIG] A wrapper for odepack routines?
Message-ID: <01bd25b8$3d517280$998a7380@pduboispc>
Alas, the LLNL guru who wrote LSODE (Alan Hindmarsh) hasn't (yet) become a
Pythonisto. Definitely, to do this would be a Good Thing. But as far as I
know, we haven't.
-----Original Message-----
From: Jannie Hofmeyr <jhsh@iafrica.com>
To: matrix-sig@python.org <matrix-sig@python.org>
Date: Saturday, January 17, 1998 10:44 PM
Subject: [MATRIX-SIG] A wrapper for odepack routines?
>Before I inadvertently re-invent the wheel, does anyone know of or have
>a Python wrapper for the Livermore ODE solvers in odepack (LSODA,
>LSODE)? Since the LLNL gurus have been very active in numerical Python I
>am optimistic :-)
>
>Jannie
>
>
>
>
>_______________
>MATRIX-SIG - SIG on Matrix Math for Python
>
>send messages to: matrix-sig@python.org
>administrivia to: matrix-sig-request@python.org
>_______________
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Tue Jan 20 15:49:12 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Tue, 20 Jan 1998 07:49:12 -0800
Subject: [MATRIX-SIG] integer division -- what a concept!
Message-ID: <01bd25ba$f4274140$998a7380@pduboispc>
An historical note: the original Matlab was a code (in Fortran) that Cleve
Moler wrote at the University of New Mexico as a teaching tool. In this
code, ALL numbers were complex. Further, you were limited to 10,000 of them.
I took this Matlab and removed the limit on the number of numbers by using
the dynamic memory features of LRLTRAN, LLNL's Fortran dialect. (During that
period, around 1981 I think, we had our own compiler group and our own
Fortran compiler that supported pointers). This allowed us to run Matlab on
the Cray 1 and analyze some of the large matrices that arise when
discretising PDEs.
Those of you who keep remarking that Fortran is OLD, and by inference
infering that I am also OLD, will rejoice in knowing that this is in fact
true. However, contrary to another remark, I in fact got my degree in
mathematics, not computer science (abelian groups!), and I bet you "modern"
youngsters haven't written a book about Eiffel. (:->.
Python is a strange language in which the objects are typed but the entities
are not declared. This permits an interesting degree of flexibility combined
with the ability to be type safe when you want to be. For example, you can
define your own Integer class in which division is always floating point
(hint, hint). Or complex, come to think of it.
Fortran 95, by the way, is strongly typed. It isn't fair to keep beating up
a twenty-year old version of the language.
Paul
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From furnish@xdiv.lanl.gov Tue Jan 20 15:53:11 1998
From: furnish@xdiv.lanl.gov (Geoffrey M. Furnish)
Date: Tue, 20 Jan 1998 15:53:11 GMT
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <m0xtPRH-000e1bC@sirius>
References: <01bd22c0$0ff23a40$6c357380@xfiles.llnl.gov>
<9801162140.AA23313@reactor.pgt>
<v0300782cb0e58aacf6e9@[128.115.108.86]>
<m0xtPRH-000e1bC@sirius>
Message-ID: <199801201553.PAA06801@twix.lanl.gov>
Charles G. Waldman writes:
>
> Zane Motteler writes:
>
> > If i and j are the same type, then the "principle of least surprise"
> > says that x should be of the same type as i and j.
>
> To me, the "principle of least surprise" (and high-school algebra)
> says that if b != 0, then b*(a/b) should be equal to a. Values are
> (to me) more important than types. If we were to insist that division
> always promotes its operands to float before dividing, and returns a
> float, then 2*(1/2) returns 1.0, which, although not the same type as
> the integer 1, represents the same value. If you insist on being
> type-centric, then 2*(1/2)==0 is true, which seems far weirder to me.
I am clearly a fence-sitter in this argument. I definitely see both
sides. To the extent that my comments fueled this back near the
beginning of the thread, my true surprise was in "discovering" what
the /true/ types of my operands were. Once I knew the types, the
behavior was ocmprehensible. Dynamic typing is just not something I
find real exciting.
I am not saying dynamic typing is worthless, or anything like that.
It clearly has uses, but it clearly also has failure modes which for
me, heinously violate the "principle of least surprise".
With all this talk about fixing Python so it behaves reasonably, I
guess the fix I would most like to see would be some sort of a "type
constraint" mechanism. If I could've said that that the operands to
my function were constrained to be of some type that supported
floating point arithematic, then I wouldn't have been bit.
This doesn't necessarily have to be the same as static typing. I am
not necessarily saying the function declaration/definition should
specify /the/ type of the operands, but perhaps a constraint on the
types of the operands, so that the true operands could be any of a
class of types which satisfy the type constraint.
This way, the integers could've been promoted to floats at the call
gate, without me having to dribble my function with explicit float
conversions.
--
Geoffrey Furnish email: furnish@lanl.gov
LANL XTM Radiation Transport/POOMA phone: 505-665-4529 fax: 505-665-5538
"Software complexity is an artifact of implementation." -Dan Quinlan
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From furnish@xdiv.lanl.gov Tue Jan 20 16:11:26 1998
From: furnish@xdiv.lanl.gov (Geoffrey M. Furnish)
Date: Tue, 20 Jan 1998 16:11:26 GMT
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <34C0F0BF.301E7A44@verinet.com>
References: <Pine.PMDF.3.91.980117162837.650162543B-100000@Pap.UniVie.AC.AT>
<34C0F0BF.301E7A44@verinet.com>
Message-ID: <199801201611.QAA06835@twix.lanl.gov>
David J. C. Beach writes:
> def foo(x, y): # x and y need to be floats
> x, y = float(x), float(y)
> # at this point, x and y are either floats, or an exception was
> raised
> # now, go about your usual business with confidence that operations
> # involving x and y will return floats (principle of least surprise)
If I had done this, I wouldn't have had my original problem. Perhaps
I will start doing this.
But I remain offended that it is possible to write algorithms in
Python which behave radically differently if they are called as
z = foo( 1, 2 )
or
z = foo( 1., 2. )
--
Geoffrey Furnish email: furnish@lanl.gov
LANL XTM Radiation Transport/POOMA phone: 505-665-4529 fax: 505-665-5538
"Software complexity is an artifact of implementation." -Dan Quinlan
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From zcm@llnl.gov Tue Jan 20 16:16:48 1998
From: zcm@llnl.gov (Zane Motteler)
Date: Tue, 20 Jan 1998 08:16:48 -0800
Subject: [MATRIX-SIG] integer division etc.
Message-ID: <v03007800b0ea7c434be4@[128.115.108.86]>
There seems to be a lot of sentiment out there that a number
is a number, and that 1/2 really ought to be 0.5, a float.
And, to paraphrase, that in a high level language you shouldn't
have to worry about type.
Integer operations really are distinct from floating point,
and there really are important cases where one wants the integer
result. I have done extensive work with graphics in Python,
and part of this involves computations with arrays of integers
which are actually subscripts into arrays of data. I really
do want division (/) and mod (%) to be operations which give
integer results. No matter how much you may not want to worry
about type, you still can't use a float for a subscript in
Python.
To me, saying that 1/2 ought to be 0.5 makes about as much
sense as saying "1"+"2" ought to be 3 rather than "12".
Cheers
Zane
-----------------------------------------------------------------
Zane C. Motteler, Ph. D.
Computer Scientist | Professor Emeritus of
Lawrence Livermore National | Computer Science and Engineering
Laboratory | California Polytechnic
P. O. Box 808, L-472 | State University
(7000 East Avenue, zip 94550) | San Luis Obispo, CA 93407
Livermore, CA 94551-9900 | zmottel@phoenix.csc.calpoly.edu
510/423-2143, FAX 423-9969 (Area code 925 after March 14, 1998)
zcm@llnl.gov
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From cgw@pgt.com Tue Jan 20 18:17:27 1998
From: cgw@pgt.com (Charles G Waldman)
Date: Tue, 20 Jan 98 13:17:27 EST
Subject: [MATRIX-SIG] integer division etc.
In-Reply-To: <v03007800b0ea7c434be4@[128.115.108.86]>
References: <v03007800b0ea7c434be4@[128.115.108.86]>
Message-ID: <9801201817.AA03979@reactor.pgt>
Paul Dubois wrote:
> Python is a strange language in which the objects are typed but the entities
> are not declared.
That sums it up well.
> For example, you can define your own Integer class in which
> division is always floating point (hint, hint).
Of course, I'm aware of this. But I thought we were talking about how
the literal expression "1/2" should be handled, not an expression like
Integer(1)/Integer(2) or Number(1)/Number(2).
Zane Motteler writes:
> To me, saying that 1/2 ought to be 0.5 makes about as much
> sense as saying "1"+"2" ought to be 3 rather than "12".
>
Clearly, "1" + "2" should come out to "3". ;-)
Actually, I think I'd like to retract my opinions on the integer
division issue. The fact that I sometimes use Python as a teaching
tool was the motivation behind my desire for 1/2=0.5. As a programmer
I understand the current behavior and can live with it, and think it
would be a bad idea to change the established behavior at this point
in Python's life. So, when I teach beginning programming using
Python, I will just explain about "integer division" and explain
contexts in which it is useful.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Wed Jan 21 09:40:04 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 21 Jan 1998 10:40:04 +0100
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <199801201553.PAA06801@twix.lanl.gov> (furnish@xdiv.lanl.gov)
Message-ID: <199801210940.KAA28133@lmspc1.ibs.fr>
> With all this talk about fixing Python so it behaves reasonably, I
> guess the fix I would most like to see would be some sort of a "type
> constraint" mechanism. If I could've said that that the operands to
> my function were constrained to be of some type that supported
> floating point arithematic, then I wouldn't have been bit.
Python even has such a mechanism - but only for C functions. If you
ask PyArg_ParseTuple() to parse an argument as float or double, it
will also accept and convert integers.
There was some discussion on optional type specifications at the last
Python Conference; if something like that ever gets implemented,
we might succeed in getting such a type constraint mechanism as
a byproduct.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Wed Jan 21 09:36:39 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 21 Jan 1998 10:36:39 +0100
Subject: [MATRIX-SIG] integer division -- what a concept!
In-Reply-To: <199801201514.PAA06751@twix.lanl.gov> (furnish@xdiv.lanl.gov)
Message-ID: <199801210936.KAA28118@lmspc1.ibs.fr>
> And it confused me too, though I am hardly a newbie, b/c I didn't
> actually know that my two and my three, were integers. I have
> littered my code now with float(x) and float(y), to promote my input
> variables to the right type, but I have to say, this is hideously
> ugly.
It also creates another problem: your code won't work with complex
numbers any more, because float() applied to a complex number raises
an exception. If you want code to work for *all* numeric types, the
most general "number conversion" is x = x + 0. (or, if you want some
variation, x = 1.*x).
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From stjohn@gav.gat.com Wed Jan 21 18:00:05 1998
From: stjohn@gav.gat.com (Holger St. John)
Date: Wed, 21 Jan 1998 10:00:05 -0800
Subject: [MATRIX-SIG] Re: int. division
Message-ID: <199801211755.MAA28917@python.org>
I know that this group has gone south for the winter when I read stuff
like this :-)
> > > ......Consider the
> > > code:
> > >
> > > x = i / j
> > >
> > > Now, suppose i=2 and j=4. Then x will be the integer, 2.
> > > Everybody agrees on this.
> >
> > Well, not everybody. I would have 2/4 == 2.0 and 2//4 == 2
>
>Call me crazy, but somehow I'm not comfortable with the result of 2/4
>being either 2 *or* 2.0...
>
Holger St. John
General Atomics
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Fri Jan 23 16:11:19 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 23 Jan 1998 08:11:19 -0800
Subject: [MATRIX-SIG] Anybody know all the rules for extension objects?
Message-ID: <01bd2819$8a371100$998a7380@pduboispc>
There are some rules for type objects that I'm not sure are written down
anywhere. For example,
a. Every type must have a dealloc function.
b. If a type defines a number add and is also a sequence you must define
sequence concat.
Failure to obey these rules results in code crashes of the unpleasant sort.
In a C++ facility to make it easier to write correct extensions to Python, I
can fix a few of these problems. For example, in case (a) I can supply a
default dealloc and in case (b) set the concat to be the same as the add if
the concat is not supplied.
So, what are the rest of the rules for type objects?
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From esikes@anet-dfw.com Mon Jan 26 04:51:08 1998
From: esikes@anet-dfw.com (esikes@anet-dfw.com)
Date: Sun, 25 Jan 1998 22:51:08 -0600 (CST)
Subject: [MATRIX-SIG] Home Bussiness
Message-ID: <eaep.3.0.reg.Ed P53.35820.4565439815@mail.anet-dfw.com>
We understand that you are interested in, or are already involved in marketing. We are searching for
people to get into the highest paying plan in the world. Contact me for all the details.
I have 28yrs. in the business world.
1-(972) 557-0955
Ed Sikes
You may also visit my website at: http://www.admaxsilver.com/sikes/
**(( You have recieved this message because you have visited one of our business opportunity sites
in the past. If you have recieved this message in error or simply wish to be removed from our list
please reply with the word "remove" in the subject header. We apologize for any inconvience if we
have sent this to you in error.))**
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From brydon@physics.utexas.edu Mon Jan 26 20:52:17 1998
From: brydon@physics.utexas.edu (David Brydon)
Date: 26 Jan 1998 20:52:17 -0000
Subject: [MATRIX-SIG] interpolating matrices
Message-ID: <19980126205217.21311.qmail@findmail.com>
Hello. I would like to take a matrix of floating point numbers,
say 200x200, representing data on a finite-difference grid,
and change the grid to be, say 400x400, perhaps with smoothing of
the data. Has anyone implemented that kind of operation?
Thanks a lot, D
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hochberg@wwa.com Mon Jan 26 22:29:47 1998
From: hochberg@wwa.com (Tim Hochberg)
Date: Mon, 26 Jan 1998 16:29:47 -0600
Subject: [MATRIX-SIG] interpolating matrices
Message-ID: <01bd2aa9$e8558400$a23cf1cf@oemcomputer>
> Hello. I would like to take a matrix of floating point numbers,
>say 200x200, representing data on a finite-difference grid,
>and change the grid to be, say 400x400, perhaps with smoothing of
>the data. Has anyone implemented that kind of operation?
If all you need to do is double the grid size, this should be fairly easy --
something like (untested):
m2 = zeros( (2*shape(m1)[0], 2*shape(m2)[1], Float)
m2[::2,::2] = m1
m2[1::2,::2] = (m1[:-1] + m1[1:])/2
m2[:,1::2] = (m1[:,:-1] + m1[:,1:])/2
If you need an arbitrary new matrix shape, this gets a bit more painful so
I'll leave it as an exercise for the reader.
____
/im
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Tue Jan 27 20:06:09 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Tue, 27 Jan 1998 21:06:09 +0100
Subject: [MATRIX-SIG] interpolating matrices
In-Reply-To: <19980126205217.21311.qmail@findmail.com>
(brydon@physics.utexas.edu)
Message-ID: <199801272006.VAA26936@lmspc1.ibs.fr>
> Hello. I would like to take a matrix of floating point numbers,
> say 200x200, representing data on a finite-difference grid,
> and change the grid to be, say 400x400, perhaps with smoothing of
> the data. Has anyone implemented that kind of operation?
My Interpolation module (at http://starship.skyport.net/crew/hinsen/) is
not exactly what you want, but probably a good starting point.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jcollins@pacificnet.net Thu Jan 29 05:49:14 1998
From: jcollins@pacificnet.net (Jeffery D. Collins)
Date: Wed, 28 Jan 1998 21:49:14 -0800
Subject: [MATRIX-SIG] Seg fault in netcdfmodule
Message-ID: <34D0185A.52BA6BA5@pacificnet.net>
I'm having problems with segmentation faults when using
netCDFmodule.c and/or ncmodule.c with Python-1.5 under
solaris 2.6. The problem arises when trying to read values
from the variables as in:
>>> import netcdf
>>> fh = netcdf.NetCDFFile('test.nc')
>>> v = fh.variables['cosx']
>>> v[0]
=> segmentation fault
or
>>> import nc
>>> fh = nc.open('test.nc')
>>> v = fh.var('cosx')
>>> v[0]
=> segmentation fault
It doesn't seem to matter if v is indexed as above or as a slice - the
same error
is produced. Additionally, other objects seem to work fine (eg,
fh.variables
prints the variable dictionary).
I suspect the gcc (2.7.2) compiler. A recent OS upgrade (2.5.1 to 2.6)
required a recompile
of gcc, then a recompile of Python-1.5, NumPy (the EZ Hinsen version),
and the
netcdf modules listed above (all as shared modules). I also recompiled
Python-1.4
and performed the above tests with mixed results - one of the two still
produced a
seg fault. Note that I had no problems under Python-1.4 compiled with
the gcc under
Solaris 2.5.1.
I also noticed a problem with ncmodule (NetCDFmodule seems to be ok)
under
Linux as compiled for Python-1.5 that doesn't exist for Python-1.4:
Python-1.4 (libc5, linux-2.0.29):
>>> import nc
>>> fh = nc.open('test.nc')
>>> v = fh.var('cos2x')
>>> v[0]
1.0
>>> v[1]
0.773474097252
>>> v[:]
[1.0, 0.773474097252, 0.299152284861, 0.00681934831664, 0.161359220743,
0.622742772102, 0.972908616066, 0.894570231438, 0.458710312843,
0.0602631233633, 0.0602631233633, 0.458710312843, 0.894570231438,
0.972908616066, 0.622742772102, 0.161359220743, 0.00681934831664,
0.299152284861, 0.773474097252, 1.0]
>>> v[0]
1.0
>>>
Python-1.5 (same OS):
>>> import nc
>>> fh = nc.open('test.nc')
>>> v = fh.var('cos2x')
>>> v[0]
1.0
>>> v[1]
0.773474097252
>>> v[:]
Traceback (innermost last):
File "<stdin>", line 1, in ?
nc.error: Problem getting data for variable <cos2x> (8)
>>> v[0]
Fatal Python error: PyString_InternInPlace: strings only please!
Abort
%
-----------------------
Any suggestions? Perhaps I need to flip a compiler flag (or upgrade to
a more recent
version). In building gcc, there is the question of which malloc to
use - the system's
version or gcc's version - I always choose the default (gcc's, I think)
- maybe that's
a problem.
I'll try the Sun compiler (cc) next to see what happens.
Thanks,
Jeff
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Thu Jan 29 14:13:05 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 29 Jan 1998 15:13:05 +0100
Subject: [MATRIX-SIG] Seg fault in netcdfmodule
In-Reply-To: <34D0185A.52BA6BA5@pacificnet.net> (jcollins@pacificnet.net)
Message-ID: <199801291413.PAA03919@lmspc1.ibs.fr>
> I'm having problems with segmentation faults when using
> netCDFmodule.c and/or ncmodule.c with Python-1.5 under
> solaris 2.6. The problem arises when trying to read values
> from the variables as in:
>
> >>> import netcdf
> >>> fh = netcdf.NetCDFFile('test.nc')
> >>> v = fh.variables['cosx']
> >>> v[0]
> => segmentation fault
There are some problems in the netcdf module that cause crashes
on machines where malloc(0) returns NULL, but only when accessing
scalar variables (i.e. no dimensions). That doesn't seem to be
your case, however.
> I suspect the gcc (2.7.2) compiler. A recent OS upgrade (2.5.1 to 2.6)
> required a recompile
> of gcc, then a recompile of Python-1.5, NumPy (the EZ Hinsen version),
> and the
If you use my modified NumPy, you must also use a version of the netCDF
module that was released later. You can recognize newer versions
by the "import_array" statement in the init function at the end
of the module. If you use an older version of the module, it will
crash as soon as it uses any NumPy functions. That could very well
be the problem you have!
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From KaliazinA@cardiff.ac.uk Thu Jan 29 18:21:05 1998
From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin)
Date: Thu, 29 Jan 1998 18:21:05 GMT0BST
Subject: [MATRIX-SIG] compiling NumPy for Windows
Message-ID: <44DF1132CA6@NPRDCF1S.CF.AC.UK>
Hi, wizards!
I am Andrey Kaliazin, russian, working in Cardiff on contract.
I deal with some simulations in solid state physics, and I am
interesting im MD. So I've found in internet very attractive
Konrad's MMTK and Python itself.
It seems to be my favorite language in future ( after russian and
english :-)
Unfortunately, (in this case) I work in Win'95 environ. and nearly
zero in C/C++ . But I want to build python executive with netCDF
support. (compiled binaries works fine, thanks to all providers!)
I have all last versions of suits -
Python-1.5 source and binary;
netCDF-3.3a-win32dll,
Konrad's MMTK-1.1b1, netcdfmodule dated Nov.97,
NumPy-1.0b3,
NumPyLib-1.0b2
I have included manually netcdfmodule in project and two strings in
config.c to init netCDF, NumPy's "arrayobject.h" is also on path.
But linker fails.
--------------------------------------------------
Visual C++ 4.2 compiler say:
...
Creating library vc40/python15.lib and object vc40/python15.exp
netcdfmodule.obj : error LNK2001: unresolved external symbol
_PyArray_Return
netcdfmodule.obj : error LNK2001: unresolved external symbol
_PyArray_FromDims
netcdfmodule.obj : error LNK2001: unresolved external symbol
_PyArray_ContiguousFromObject
vc40/python15.dll : fatal error LNK1120: 3 unresolved externals
Error executing link.exe.
----------------------------------------------------
Can anybody give me idea, what's going on?
Sincerely,
Andy
---
A. Kaliazin
Research Associate
School of Engineering, University of Wales, Cardiff
P.O.Box 689 Newport Rd, Cardiff, CF2 3TF, UK
phone: +(1222) 874000 ext. 5950 FAX: +(1222) 874420
home address:
flat 1, 28, Monthermer Rd.,
Cathays, Cardiff CF2 4RA, UK
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From pas@xis.xerox.com Thu Jan 29 19:26:28 1998
From: pas@xis.xerox.com (Perry Stoll)
Date: Thu, 29 Jan 1998 11:26:28 PST
Subject: [MATRIX-SIG] compiling NumPy for Windows
Message-ID: <006801bd2ceb$cc1cfb30$4a4df60d@stoll-pc.xis.xerox.com>
Looking at the symbols that are missing, I'd guess you're not linking
against
numpy.lib, which can be accomplised by including ("Add to Project")
numpy.lib in the project when building (I'm using VC++ 5.0, so I hope that
translates to VC++ 4.2...)
I went through something similar last night to get Konrad's RNG working on
WinNT. Which it does, I'm happy to report. Although only after some tweaking
to build as a dynamic extension dll - does anyone know why when building a
dll extension, the following:
static PyTypeObject distributiontype = {
PyObject_HEAD_INIT(&PyType_Type)
0, /*ob_size*/
"random_distribution", /*tp_name*/
Gives an error: Initialization from non-const value (refering to
&PyType_Type).
Changing it to:
static PyTypeObject distributiontype = {
PyObject_HEAD_INIT(NULL)
0, /*ob_size*/
"random_distribution", /*tp_name*/
And then doing the following in initRNG:
distributiontype.ob_type = &PyType_Type;
fixes the problem and lets the module function correctly.
(I learned that trick from Fredrick's tk extension for Win32). That seems
awfully nasty - am I doing something wrong? I'm guessing that the judicious
use of USE_DL_EXPORT or USE_DL_IMPORT might get rid of the problem...
Building extensions on the PC is not painless, but it's doable.
-Perry Stoll
pas@xis.xerox.com
-----Original Message-----
From: Andrey Kaliazin <KaliazinA@cardiff.ac.uk>
To: matrix-sig@python.org <matrix-sig@python.org>
Date: Thursday, January 29, 1998 1:37 PM
Subject: [MATRIX-SIG] compiling NumPy for Windows
I have included manually netcdfmodule in project and two strings in
config.c to init netCDF, NumPy's "arrayobject.h" is also on path.
But linker fails.
--------------------------------------------------
Visual C++ 4.2 compiler say:
...
Creating library vc40/python15.lib and object vc40/python15.exp
netcdfmodule.obj : error LNK2001: unresolved external symbol
_PyArray_Return
netcdfmodule.obj : error LNK2001: unresolved external symbol
_PyArray_FromDims
netcdfmodule.obj : error LNK2001: unresolved external symbol
_PyArray_ContiguousFromObject
vc40/python15.dll : fatal error LNK1120: 3 unresolved externals
Error executing link.exe.
----------------------------------------------------
Can anybody give me idea, what's going on?
Sincerely,
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From KaliazinA@cardiff.ac.uk Thu Jan 29 20:57:40 1998
From: KaliazinA@cardiff.ac.uk (Andrey Kaliazin)
Date: Thu, 29 Jan 1998 20:57:40 GMT0BST
Subject: [MATRIX-SIG] compiling NumPy for Windows
In-Reply-To: <006801bd2ceb$cc1cfb30$4a4df60d@stoll-pc.xis.xerox.com>
Message-ID: <4508C705FD7@NPRDCF1S.CF.AC.UK>
>
> Looking at the symbols that are missing, I'd guess you're not linking
> against
> numpy.lib, which can be accomplised by including ("Add to Project")
> numpy.lib in the project when building (I'm using VC++ 5.0, so I hope that
> translates to VC++ 4.2...)
Yee! you are right!
I had to compile NumPy from 10b3 distribution to
get that LIB and PYDs, but now it works well. At least given tests
for NumPy (test_all), netCDF (netcdf_demo) and MMTKlight importing
finish successfully.
Thanks
Andy.
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jcollins@pacificnet.net Fri Jan 30 03:27:34 1998
From: jcollins@pacificnet.net (Jeffery D. Collins)
Date: Thu, 29 Jan 1998 19:27:34 -0800
Subject: [MATRIX-SIG] Seg fault in netcdfmodule
References: <199801291413.PAA03919@lmspc1.ibs.fr>
Message-ID: <34D148A6.F9CF3B62@pacificnet.net>
Konrad Hinsen wrote:
> > I'm having problems with segmentation faults when using
> > netCDFmodule.c and/or ncmodule.c with Python-1.5 under
> > solaris 2.6. The problem arises when trying to read values
> > from the variables as in:
> >
> > >>> import netcdf
> > >>> fh = netcdf.NetCDFFile('test.nc')
> > >>> v = fh.variables['cosx']
> > >>> v[0]
> > => segmentation fault
>
> There are some problems in the netcdf module that cause crashes
> on machines where malloc(0) returns NULL, but only when accessing
> scalar variables (i.e. no dimensions). That doesn't seem to be
> your case, however.
>
> > I suspect the gcc (2.7.2) compiler. A recent OS upgrade (2.5.1 to 2.6)
> > required a recompile
> > of gcc, then a recompile of Python-1.5, NumPy (the EZ Hinsen version),
> > and the
>
> If you use my modified NumPy, you must also use a version of the netCDF
> module that was released later. You can recognize newer versions
> by the "import_array" statement in the init function at the end
> of the module. If you use an older version of the module, it will
> crash as soon as it uses any NumPy functions. That could very well
> be the problem you have!
That was the problem. Also, it looks like when python calls the sliceroutine for
the wildcard case (eg, v[:]), the low and high indexes
are 0 and INT_MAX, respectively. Is this a change in the interpreter?
Thanks for the help!
Jeff
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Jan 30 09:19:21 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 30 Jan 1998 10:19:21 +0100
Subject: [MATRIX-SIG] Seg fault in netcdfmodule
In-Reply-To: <34D148A6.F9CF3B62@pacificnet.net> (jcollins@pacificnet.net)
Message-ID: <199801300919.KAA08636@lmspc1.ibs.fr>
> That was the problem. Also, it looks like when python calls the sliceroutine for
> the wildcard case (eg, v[:]), the low and high indexes
> are 0 and INT_MAX, respectively. Is this a change in the interpreter?
Yes. For a well-written module this change shouldn't make a difference,
because it was always allowed to pass in an upper index that is
larger than the length of the sequence - but early versions of my
netCDF module weren't so well-written :-(
Anyone using the netCDF interface with Python 1.5 should pick up the
latest version from my Starship cabin.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Jan 30 13:33:55 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 30 Jan 1998 14:33:55 +0100
Subject: [MATRIX-SIG] compiling NumPy for Windows
In-Reply-To: <006801bd2ceb$cc1cfb30$4a4df60d@stoll-pc.xis.xerox.com>
(pas@xis.xerox.com)
Message-ID: <199801301333.OAA09685@lmspc1.ibs.fr>
> (I learned that trick from Fredrick's tk extension for Win32). That seems
> awfully nasty - am I doing something wrong? I'm guessing that the judicious
> use of USE_DL_EXPORT or USE_DL_IMPORT might get rid of the problem...
>
> Building extensions on the PC is not painless, but it's doable.
Perhaps some Windows wizard could prepare instructions on what can
and cannot be done with Windows DLLs and how to do it correctly.
Ideally in such a way that Unix people can make their modules
Windows compatible without having to test it on Windows!
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From da@skivs.ski.org Fri Jan 30 17:37:52 1998
From: da@skivs.ski.org (David Ascher)
Date: Fri, 30 Jan 1998 09:37:52 -0800 (PST)
Subject: [MATRIX-SIG] compiling NumPy for Windows
In-Reply-To: <199801301333.OAA09685@lmspc1.ibs.fr>
Message-ID: <Pine.SUN.3.96.980130093536.17411H-100000@skivs.ski.org>
On Fri, 30 Jan 1998, Konrad Hinsen wrote:
> > (I learned that trick from Fredrick's tk extension for Win32). That seems
> > awfully nasty - am I doing something wrong? I'm guessing that the judicious
> > use of USE_DL_EXPORT or USE_DL_IMPORT might get rid of the problem...
> >
> > Building extensions on the PC is not painless, but it's doable.
>
> Perhaps some Windows wizard could prepare instructions on what can
> and cannot be done with Windows DLLs and how to do it correctly.
> Ideally in such a way that Unix people can make their modules
> Windows compatible without having to test it on Windows!
Konrad, you'll be glad to know that numpy_ez builds fine on Windows.
There are things the windows person needs to do to configure the build,
but no modifications to your source were needed.
Harri Pasanen, Paul Dubois and myself have been talking about these things
as we're helping each other build various things on Windows. Maybe
someday in my spare time (Ha!) I'll make a "Microsoft Visual C for Unix
Makefile Hackers" document...
--da
This message brought to you by the National Non-Sequitur Society
We may not make sense, but the panda is a giant racoon.
--------------------------da@skivs.ski.org----------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From miller5@uiuc.edu Fri Jan 30 17:51:43 1998
From: miller5@uiuc.edu (Mike Miller)
Date: 30 Jan 1998 11:51:43 -0600
Subject: [MATRIX-SIG] random.gauss isn't Gaussian
Message-ID: <t9g1m5u9xs.fsf@uinpluxb.npl.uiuc.edu>
I've been doing some monte carlo studies with python (monte
python calculations actually) and have found rather weird
distributions when using random.gauss. Contrary to what the
docs say, it does not generate a normal distribution.
In addition, while looking into this, I found that the
test_generator function in random.py calculates standard
deviations as sqrt( Sum[ x*x ]/n - mean*mean ), which is
somewhat different from what I think of as the usual
definition - sqrt(Sum[ ( x - mean )^2 / N ]).
Is this all intentional? Or is it a bug?
Mike
--
Michael A. Miller miller5@uiuc.edu
Department of Physics, University of Illinois, Urbana-Champaign
PGP public key available on request
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From tismer@appliedbiometrics.com Fri Jan 30 19:13:55 1998
From: tismer@appliedbiometrics.com (Christian Tismer)
Date: Fri, 30 Jan 1998 20:13:55 +0100
Subject: [MATRIX-SIG] random.gauss isn't Gaussian
References: <t9g1m5u9xs.fsf@uinpluxb.npl.uiuc.edu>
Message-ID: <34D22673.8462C195@appliedbiometrics.com>
> I've been doing some monte carlo studies with python (monte
> python calculations actually) and have found rather weird
> distributions when using random.gauss. Contrary to what the
> docs say, it does not generate a normal distribution.
I did not check this one, but...
> In addition, while looking into this, I found that the
> test_generator function in random.py calculates standard
> deviations as sqrt( Sum[ x*x ]/n - mean*mean ), which is
> somewhat different from what I think of as the usual
> definition - sqrt(Sum[ ( x - mean )^2 / N ]).
>
> Is this all intentional? Or is it a bug?
The last one is definately no bug, but the formulas are equivalent
what can be seen by two lines of transformations. For computational
exactnes, the Python version might have slight advantages over
the usual" one, since there is only a single subtraction. Having
many mixed operations could worsen the result, especially for
very skewed distributions (where the sdev makes no sense at all, btw).
cheers - pirx
--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net
10553 Berlin : PGP key -> http://pgpkeys.mit.edu
we're tired of banana software - shipped green, ripens at home
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Fri Jan 30 19:23:56 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 30 Jan 1998 20:23:56 +0100
Subject: [MATRIX-SIG] compiling NumPy for Windows
In-Reply-To: <Pine.SUN.3.96.980130093536.17411H-100000@skivs.ski.org> (message
from David Ascher on Fri, 30 Jan 1998 09:37:52 -0800 (PST))
Message-ID: <199801301923.UAA11637@lmspc1.ibs.fr>
> Konrad, you'll be glad to know that numpy_ez builds fine on Windows.
> There are things the windows person needs to do to configure the build,
> but no modifications to your source were needed.
Fine, but some of my other modules don't, and I'd like to know why
and what to do about it. My MMTK modules seem to have the same
problem that Perry mentioned: Initialization of PyObject_HEAD_INIT()
with a constant address is not accepted by the compiler. On the
other hand, my netCDF module uses exactly the same method, and
it works. Such problems don't increase my confidence in easy
Windows installation...
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From miller5@uiuc.edu Fri Jan 30 19:34:03 1998
From: miller5@uiuc.edu (Mike Miller)
Date: 30 Jan 1998 13:34:03 -0600
Subject: [MATRIX-SIG] random.gauss isn't Gaussian
In-Reply-To: Christian Tismer's message of Fri, 30 Jan 1998 20:13:55 +0100
References: <t9g1m5u9xs.fsf@uinpluxb.npl.uiuc.edu> <34D22673.8462C195@appliedbiometrics.com>
Message-ID: <t9en1pu578.fsf@uinpluxb.npl.uiuc.edu>
>>>>> "Christian" == Christian Tismer <tismer@appliedbiometrics.com> writes:
> The last one is definately no bug, but the formulas are
> equivalent what can be seen by two lines of
> transformations.
Ahem, well, yes, of course I knew that... :)
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Paul F. Dubois" <dubois1@llnl.gov Fri Jan 30 19:51:58 1998
From: Paul F. Dubois" <dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 30 Jan 1998 11:51:58 -0800
Subject: [MATRIX-SIG] compiling NumPy for Windows
Message-ID: <01bd2db8$8668f620$998a7380@pduboispc>
You add /Tp to the compiler flags to tell it to treat your source as C++ and
that error goes away.
While it is true that I did find it easy to compile numpy I'm still trying
to figure out why it won't run. There is no question that Harri's .pyd's
work, but mine don't. I must have done something dumb but ...
-----Original Message-----
From: Konrad Hinsen <hinsen@ibs.ibs.fr>
To: da@skivs.ski.org <da@skivs.ski.org>
Cc: pas@xis.xerox.com <pas@xis.xerox.com>; matrix-sig@python.org
<matrix-sig@python.org>
Date: Friday, January 30, 1998 11:29 AM
Subject: Re: [MATRIX-SIG] compiling NumPy for Windows
>> Konrad, you'll be glad to know that numpy_ez builds fine on Windows.
>> There are things the windows person needs to do to configure the build,
>> but no modifications to your source were needed.
>
>Fine, but some of my other modules don't, and I'd like to know why
>and what to do about it. My MMTK modules seem to have the same
>problem that Perry mentioned: Initialization of PyObject_HEAD_INIT()
>with a constant address is not accepted by the compiler. On the
>other hand, my netCDF module uses exactly the same method, and
>it works. Such problems don't increase my confidence in easy
>Windows installation...
>
>Konrad.
>--
>---------------------------------------------------------------------------
----
>Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
>Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
>Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
>41, av. des Martyrs | Deutsch/Esperanto/English/
>38027 Grenoble Cedex 1, France | Nederlands/Francais
>---------------------------------------------------------------------------
----
>
>_______________
>MATRIX-SIG - SIG on Matrix Math for Python
>
>send messages to: matrix-sig@python.org
>administrivia to: matrix-sig-request@python.org
>_______________
>
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From Warren Focke <warren@xtepca.gsfc.nasa.gov> Fri Jan 30 20:06:43 1998
From: Warren Focke <warren@xtepca.gsfc.nasa.gov> (Warren Focke)
Date: Fri, 30 Jan 1998 15:06:43 -0500 (EST)
Subject: [MATRIX-SIG] random.gauss isn't Gaussian
In-Reply-To: <34D22673.8462C195@appliedbiometrics.com>
Message-ID: <Pine.SUN.3.96.980130145721.2970B-100000@xtepca.gsfc.nasa.gov>
On Fri, 30 Jan 1998, Christian Tismer wrote:
>
> > In addition, while looking into this, I found that the
> > test_generator function in random.py calculates standard
> > deviations as sqrt( Sum[ x*x ]/n - mean*mean ), which is
> > somewhat different from what I think of as the usual
> > definition - sqrt(Sum[ ( x - mean )^2 / N ]).
> >
> > Is this all intentional? Or is it a bug?
>
> The last one is definately no bug, but the formulas are equivalent
> what can be seen by two lines of transformations. For computational
> exactnes, the Python version might have slight advantages over
> the usual" one, since there is only a single subtraction. Having
> many mixed operations could worsen the result, especially for
> very skewed distributions (where the sdev makes no sense at all, btw).
>
Sum[ ( x - mean )^2 / N ]
is more accurate than
Sum[ x*x ]/n - mean*mean,
especially when the mean is much larger than the standard dev or there are
many points, because the two terms in the second formula tend to be large
and their difference small. Sometimes the difference in the second
formula comes out negative!
The advantage of the second formula is that it can be used to
calculate the std dev and the mean in a single pass through the data.
Warren Focke
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From da@skivs.ski.org Fri Jan 30 21:15:26 1998
From: da@skivs.ski.org (David Ascher)
Date: Fri, 30 Jan 1998 13:15:26 -0800 (PST)
Subject: [MATRIX-SIG] compiling NumPy for Windows
In-Reply-To: <01bd2db8$8668f620$998a7380@pduboispc>
Message-ID: <Pine.SUN.3.96.980130131104.17411Q-100000@skivs.ski.org>
On Fri, 30 Jan 1998, Paul F. Dubois wrote:
> You add /Tp to the compiler flags to tell it to treat your source as C++ and
> that error goes away.
Right.
> While it is true that I did find it easy to compile numpy I'm still trying
> to figure out why it won't run. There is no question that Harri's .pyd's
> work, but mine don't. I must have done something dumb but ...
I sympathize -- I've spent a long time fiddling around until I got it to
work. Maybe the thing to do is for you and either Harri or I to output
Makefiles from DevStudio (Project/Export Makefiles) and compare those...
--david
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From da@skivs.ski.org Fri Jan 30 21:19:43 1998
From: da@skivs.ski.org (David Ascher)
Date: Fri, 30 Jan 1998 13:19:43 -0800 (PST)
Subject: [MATRIX-SIG] compiling NumPy for Windows
In-Reply-To: <199801301923.UAA11637@lmspc1.ibs.fr>
Message-ID: <Pine.SUN.3.96.980130131543.17411R-100000@skivs.ski.org>
On Fri, 30 Jan 1998, Konrad Hinsen wrote:
>
> Fine, but some of my other modules don't, and I'd like to know why
> and what to do about it. My MMTK modules seem to have the same
> problem that Perry mentioned: Initialization of PyObject_HEAD_INIT()
> with a constant address is not accepted by the compiler. On the
> other hand, my netCDF module uses exactly the same method, and
> it works. Such problems don't increase my confidence in easy
> Windows installation...
Paul gave the fix for that, in all likelihood.
As far as easy windows installation, I do believe that the right solution
there is to ship binaries -- the WISE installer makes for a very simple
package to install from the user's perspective, and a lot of users
shouldn't need to own the compiler suite.
Here's a challenge: Write a PythonCOM program which when sent a .tar.gz
file via the web, opens DevStudio, creates a workspace, a package, adds
all the appropriate files, runs a compile, opens WISE, creates an
installer, compiles it, and ships back to the person who provided the
.tar.gz a simple executable. Or maybe not. =)
--david
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From jcollins@pacificnet.net Sat Jan 31 03:40:39 1998
From: jcollins@pacificnet.net (Jeffery D. Collins)
Date: Fri, 30 Jan 1998 19:40:39 -0800
Subject: [MATRIX-SIG] ArrayPrinter problem
Message-ID: <34D29D37.749F333A@pacificnet.net>
There seems to be a problem in the ArrayPrinter module. Consider
the following:
>>> from Numeric import array
>>>
>>>
>>> a = array((1e9,))
>>> a
array([ 1000000000.])
>>> str(a)
'[ 1000000000.]'
>>> str( array((1e9,)) )
'[ 1000000000.]'
>>> str( array((1e10,)) )
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "/usr/local/Python1.5/lib/python1.5/Numeric.py", line 116, in
array_str
return array2string(a, max_line_width, precision, suppress_small, '
', 0)
File "/usr/local/Python1.5/lib/python1.5/ArrayPrinter.py", line 46, in
array2string
format, item_length = _floatFormat(data, precision, suppress_small)
File "/usr/local/Python1.5/lib/python1.5/ArrayPrinter.py", line 118,
in _floatFormat
max_str_len = len(str(int(max_val))) + precision + 2
OverflowError: float too large to convert
>>> str( array((1e12,)) )
'[ 1.00000000e+12]'
Apparently, the max_val is exceeding MAX_INT in the expression
max_str_len = len(str(int(max_val))) + precision + 2
I was able to fix the problem by replacing (line 101)
if max_val >= 1.e12:
exp_format = 1
with
if max_val >= 1.e9:
exp_format = 1
Now:
>>> from Numeric import array
>>> str( array((1e8,)) )
'[ 100000000.]'
>>> str( array((1e9,)) )
'[ 1.00000000e+09]'
>>> str( array((1e10,)) )
'[ 1.00000000e+10]'
>>> str( array((1e11,)) )
'[ 1.00000000e+11]'
>>> str( array((1e12,)) )
'[ 1.00000000e+12]'
>>> str( array((1e30,)) )
'[ 1.00000000e+30]'
Thanks,
Jeff
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Sat Jan 31 20:54:36 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sat, 31 Jan 1998 21:54:36 +0100
Subject: [MATRIX-SIG] compiling NumPy for Windows
In-Reply-To: <Pine.SUN.3.96.980130131543.17411R-100000@skivs.ski.org> (message
from David Ascher on Fri, 30 Jan 1998 13:19:43 -0800 (PST))
Message-ID: <199801312054.VAA16626@lmspc1.ibs.fr>
> As far as easy windows installation, I do believe that the right solution
> there is to ship binaries -- the WISE installer makes for a very simple
> package to install from the user's perspective, and a lot of users
> shouldn't need to own the compiler suite.
For widely used packages this is obviously the best solution. For more
specialized and/or frequently changing ones it is a bit unpractical,
especially if the author does not use Windows.
It would be nice if it were possible to distribute a single source
package for all operating systems that could be compiled and installed
by anyone with the necessary tools (compiler etc.) *automatically*,
i.e. with no manual intervention. For Unix this is already reality
(via Misc/Makefile.pre.in and a Setup file). For Windows we seem to be
far away from such a situation, if it is at all doable.
> Here's a challenge: Write a PythonCOM program which when sent a .tar.gz
> file via the web, opens DevStudio, creates a workspace, a package, adds
> all the appropriate files, runs a compile, opens WISE, creates an
> installer, compiles it, and ships back to the person who provided the
> .tar.gz a simple executable. Or maybe not. =)
Except for the "shipping back" part, this looks like what I just
described for some particular compiler. Is that really such a big
problem?
Another question: is it necessary to consider more than one compiler
for the Windows platform? With several different compilers, it would
already be a problem to provide installation instructions for
everyone.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From hinsen@ibs.ibs.fr Sat Jan 31 21:14:40 1998
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Sat, 31 Jan 1998 22:14:40 +0100
Subject: [MATRIX-SIG] random.gauss isn't Gaussian
In-Reply-To: <t9g1m5u9xs.fsf@uinpluxb.npl.uiuc.edu> (message from Mike Miller
on 30 Jan 1998 11:51:43 -0600)
Message-ID: <199801312114.WAA16757@lmspc1.ibs.fr>
> I've been doing some monte carlo studies with python (monte
> python calculations actually) and have found rather weird
> distributions when using random.gauss. Contrary to what the
> docs say, it does not generate a normal distribution.
Indeed. And it's not just a bug in the code; the formula given in the
comment is already wrong! Badly wrong, in fact. It generates an
exponential distribution and then pretends it's a Gaussian!
On the other hand, random.normalvariate() does work. However, it
is a bit slow if you need plenty of random numbers. You should
try my enhanced version of Paul Dubois' random number generator;
it also has a normal distribution, which works and is fast.
You can pick it up at
http://starship.skyport.net/crew/hinsen/RNGmodule.tar.gz
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale | Fax: +33-4.76.88.54.94
41, av. des Martyrs | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France | Nederlands/Francais
-------------------------------------------------------------------------------
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________
From miller5@uiuc.edu Sat Jan 31 22:20:11 1998
From: miller5@uiuc.edu (Mike Miller)
Date: 31 Jan 1998 16:20:11 -0600
Subject: [MATRIX-SIG] random.gauss isn't Gaussian
In-Reply-To: Konrad Hinsen's message of Sat, 31 Jan 1998 22:14:40 +0100
References: <199801312114.WAA16757@lmspc1.ibs.fr>
Message-ID: <t9yazw476s.fsf@uinpluxb.npl.uiuc.edu>
>>>>> "Konrad" == Konrad Hinsen <hinsen@ibs.ibs.fr> writes:
> [...] RNGmodule [...]
Yep - that what I did. But what can be done to get random.gauss
out of the distribution? Or fixed?
Mike
_______________
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________