From pascucci@cs.utexas.edu Sun Jan 2 09:51:37 2000
From: pascucci@cs.utexas.edu (pascucci)
Date: Sun, 02 Jan 2000 03:51:37 -0600
Subject: [Matrix-SIG] numpy interface
References: <Pine.LNX.4.04.9904110221070.7997-100000@us2.mayo.edu>
Message-ID: <386F1FA9.BD2B7119@cs.utexas.edu>
Hi,
I am new in this list.
I would like to access NumericPython arrays in my own C/C++ library.
Does anyone have a piece of SWIG interface that can be used at this end?
thanks
Valerio
From roitblat@hawaii.edu Sun Jan 2 00:41:36 2000
From: roitblat@hawaii.edu (Herbert L. Roitblat)
Date: Sat, 1 Jan 2000 14:41:36 -1000
Subject: [Matrix-SIG] Limited size arrays with cPickle
Message-ID: <027601bf54ba$2036dd60$8fd6afcf@0gl1u.pixi.com>
Help Please:
I have run into this problem before and I have a workaround for it now, but
it seems like something that would be good to fix.
I have a very large array (19741 x 53566) stored as 8-bit unsigned. I want
to cPickle it into a file and then cPickle it back when I want to use it. I
have a 2 GB machine, so memory is not immediately the problem, rather it
seems to be the routine that translates the array into a string for cPickle.
It reports a memory error. I suppose that it could take up that much more
memory to translate this array into a string, but it seems that there ought
to be a more efficient way to store arrays that would not take any more
memory than the amount taken by the array. The actual routine that does the
translation is in multiarray.pyd, so I cannot get to it with my limited
skills.
I'm running NT on a Pentium II 450MHz machine. My Numeric is dated July 13,
1999, but I think that this is the date I downloaded it. I believe that it
is the latest release of Numeric. The pdf manual is copyright 1999.
Thank you.
Herbert L. Roitblat, Ph.D.
Department of Psychology
University of Hawaii
2430 Campus Road
Honolulu, HI 96822
From da@ski.org Sun Jan 2 03:46:19 2000
From: da@ski.org (David Ascher)
Date: Sat, 1 Jan 2000 19:46:19 -0800
Subject: [Matrix-SIG] Limited size arrays with cPickle
References: <027601bf54ba$2036dd60$8fd6afcf@0gl1u.pixi.com>
Message-ID: <005f01bf54d4$27b55b60$e355cfc0@ski.org>
Did you make sure to use "binary" pickle to a file opened in 'wb' mode?
--david
----- Original Message -----
From: Herbert L. Roitblat <roitblat@hawaii.edu>
To: <matrix-SIG@python.org>
Sent: Saturday, January 01, 2000 4:41 PM
Subject: [Matrix-SIG] Limited size arrays with cPickle
> Help Please:
>
> I have run into this problem before and I have a workaround for it now,
but
> it seems like something that would be good to fix.
> I have a very large array (19741 x 53566) stored as 8-bit unsigned. I
want
> to cPickle it into a file and then cPickle it back when I want to use it.
I
> have a 2 GB machine, so memory is not immediately the problem, rather it
> seems to be the routine that translates the array into a string for
cPickle.
> It reports a memory error. I suppose that it could take up that much more
> memory to translate this array into a string, but it seems that there
ought
> to be a more efficient way to store arrays that would not take any more
> memory than the amount taken by the array. The actual routine that does
the
> translation is in multiarray.pyd, so I cannot get to it with my limited
> skills.
>
> I'm running NT on a Pentium II 450MHz machine. My Numeric is dated July
13,
> 1999, but I think that this is the date I downloaded it. I believe that
it
> is the latest release of Numeric. The pdf manual is copyright 1999.
>
> Thank you.
> Herbert L. Roitblat, Ph.D.
> Department of Psychology
> University of Hawaii
> 2430 Campus Road
> Honolulu, HI 96822
>
>
> _______________________________________________
> Matrix-SIG maillist - Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
>
From roitblat@hawaii.edu Sun Jan 2 04:55:58 2000
From: roitblat@hawaii.edu (Herbert L. Roitblat)
Date: Sat, 1 Jan 2000 18:55:58 -1000
Subject: [Matrix-SIG] Limited size arrays with cPickle
Message-ID: <028601bf54dd$a91f2740$8fd6afcf@0gl1u.pixi.com>
Yes, I did. I have made that mistake in the past. It does work with
smaller arrays, but this is the biggest one I have tried to do.
Thank you for asking.
-----Original Message-----
From: David Ascher <da@ski.org>
To: Herbert L. Roitblat <roitblat@hawaii.edu>; matrix-SIG@python.org
<matrix-SIG@python.org>
Date: Saturday, January 01, 2000 5:50 PM
Subject: Re: [Matrix-SIG] Limited size arrays with cPickle
>Did you make sure to use "binary" pickle to a file opened in 'wb' mode?
>
>--david
>
>----- Original Message -----
>From: Herbert L. Roitblat <roitblat@hawaii.edu>
>To: <matrix-SIG@python.org>
>Sent: Saturday, January 01, 2000 4:41 PM
>Subject: [Matrix-SIG] Limited size arrays with cPickle
>
>
>> Help Please:
>>
>> I have run into this problem before and I have a workaround for it now,
>but
>> it seems like something that would be good to fix.
>> I have a very large array (19741 x 53566) stored as 8-bit unsigned. I
>want
>> to cPickle it into a file and then cPickle it back when I want to use it.
>I
>> have a 2 GB machine, so memory is not immediately the problem, rather it
>> seems to be the routine that translates the array into a string for
>cPickle.
>> It reports a memory error. I suppose that it could take up that much
more
>> memory to translate this array into a string, but it seems that there
>ought
>> to be a more efficient way to store arrays that would not take any more
>> memory than the amount taken by the array. The actual routine that does
>the
>> translation is in multiarray.pyd, so I cannot get to it with my limited
>> skills.
>>
>> I'm running NT on a Pentium II 450MHz machine. My Numeric is dated July
>13,
>> 1999, but I think that this is the date I downloaded it. I believe that
>it
>> is the latest release of Numeric. The pdf manual is copyright 1999.
>>
>> Thank you.
>> Herbert L. Roitblat, Ph.D.
>> Department of Psychology
>> University of Hawaii
>> 2430 Campus Road
>> Honolulu, HI 96822
>>
>>
>> _______________________________________________
>> Matrix-SIG maillist - Matrix-SIG@python.org
>> http://www.python.org/mailman/listinfo/matrix-sig
>>
>
>
>_______________________________________________
>Matrix-SIG maillist - Matrix-SIG@python.org
>http://www.python.org/mailman/listinfo/matrix-sig
>
From guido@CNRI.Reston.VA.US Mon Jan 3 17:37:59 2000
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Mon, 03 Jan 2000 12:37:59 -0500
Subject: [Matrix-SIG] Python Conference -- Early Bird Registration ends Jan 5!
Message-ID: <200001031737.MAA24342@eric.cnri.reston.va.us>
This is the last warning. The conference is getting booked full,
don't wait till the last moment!
If you haven't registered and paid by January 5, you will paying full
price... So, be smart and register NOW. Also don't forget to book
your hotel room by January 3 to qualify for the conference rate!
Some highlights from the conference program:
- 8 tutorials on topics ranging from JPython to Fnorb;
- a keynote by Open Source evangelist Eric Raymond;
- another by Randy Pausch, father of the Alice Virtual Reality project;
- a separate track for Zope developers and users;
- live demonstrations of important Python applications;
- refereed papers, and short talks on current topics;
- a developers' day where the feature set of Python 2.0 is worked out.
Our motto, due to Bruce Eckel, is: "Life's better without braces."
Come and join us at the Key Bridge Marriott in Rosslyn (across the
bridge from Georgetown), January 24-27 in 2000. Make the Python
conference the first conference you attend in the new millennium!
The early bird registration deadline is January 5. More info:
http://www.python.org/workshops/2000-01/
The program is now complete with the titles of all presentations.
There is still space in the demo session and in the short talks
session.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From robin@jessikat.demon.co.uk Mon Jan 3 19:18:11 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Mon, 3 Jan 2000 19:18:11 +0000
Subject: [Matrix-SIG] invalid floats
Message-ID: <WKHoPAAzXPc4Ewqj@jessikat.demon.co.uk>
Is there any nice way to allow unset elements in Numeric arrays? I know
I can do array([1e308],'d')*1e308 and get 1.#INF, but is there any
concept of an unset other than using some special value?
--
Robin Becker
From hinsen@cnrs-orleans.fr Thu Jan 6 13:58:53 2000
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Thu, 6 Jan 2000 14:58:53 +0100
Subject: [Matrix-SIG] extending an array
In-Reply-To: <385AC679.FF1AE134@cs.utexas.edu> (message from pascucci on Fri,
17 Dec 1999 17:25:45 -0600)
References: <Pine.LNX.4.10.9911081105020.10064-100000@us2.mayo.edu> <385AC679.FF1AE134@cs.utexas.edu>
Message-ID: <200001061358.OAA13484@chinon.cnrs-orleans.fr>
> Is it possible to extend an array "in place"?
No.
> Reshape does not do that but resize creates always a copy.
> Is there something that behaves like a C realloc?
Even C realloc doesn't guarantee an extension in place; it might as well
allocate a new memory block and copy the data. I suppose one could somehow
provide access to the realloc operation in NumPy, but I am not sure that
it makes much sense.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
From hinsen@dirac.cnrs-orleans.fr Thu Jan 6 13:59:11 2000
From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr)
Date: Thu, 6 Jan 2000 14:59:11 +0100
Subject: [Matrix-SIG] extending an array
In-Reply-To: <385AC679.FF1AE134@cs.utexas.edu> (message from pascucci on Fri,
17 Dec 1999 17:25:45 -0600)
References: <Pine.LNX.4.10.9911081105020.10064-100000@us2.mayo.edu> <385AC679.FF1AE134@cs.utexas.edu>
Message-ID: <200001061359.OAA13488@chinon.cnrs-orleans.fr>
> Is it possible to extend an array "in place"?
No.
> Reshape does not do that but resize creates always a copy.
> Is there something that behaves like a C realloc?
Even C realloc doesn't guarantee an extension in place; it might as well
allocate a new memory block and copy the data. I suppose one could somehow
provide access to the realloc operation in NumPy, but I am not sure that
it makes much sense.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
From Oliphant.Travis@mayo.edu Fri Jan 7 02:08:36 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Thu, 6 Jan 2000 20:08:36 -0600 (CST)
Subject: [Matrix-SIG] Numerical Python update?
Message-ID: <Pine.LNX.4.10.10001062003550.3131-100000@us2.mayo.edu>
Does anybody have any idea when the next Numerical Python update will be?
It has been a long time since I have heard any news about this. Perhaps
moving NumPy to an open development location like SourceForge would be a
good idea so that anyone who is interested can keep on top of any changes?
Thanks,
Travis
From da@ski.org Fri Jan 7 05:12:37 2000
From: da@ski.org (David Ascher)
Date: Thu, 6 Jan 2000 21:12:37 -0800
Subject: [Matrix-SIG] Numerical Python update?
References: <Pine.LNX.4.10.10001062003550.3131-100000@us2.mayo.edu>
Message-ID: <002701bf58cd$d185cc90$e655cfc0@ski.org>
> Does anybody have any idea when the next Numerical Python update will be?
> It has been a long time since I have heard any news about this. Perhaps
> moving NumPy to an open development location like SourceForge would be a
> good idea so that anyone who is interested can keep on top of any changes?
I am hereby promising to do a release before IPC8. The release will
basically be a backtrack from the extensionclass idea back to the
architecture of release 12, but with the bug fixes in the current beta. In
fact I'm going to get to work on it as soon as I figure out how to undo the
damage I just did by installing Office2000...
For future development, SourceForge might be a good idea. The problem
however has not been lack of technical solutions but lack of time and
volunteers. If you want to become more directly involved, I'm sure that can
be arranged -- Talk to Paul DuBois about it.
--david
From dubois1@llnl.gov Fri Jan 7 15:05:38 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 7 Jan 2000 07:05:38 -0800
Subject: [Matrix-SIG] Numerical Python update?
In-Reply-To: <002701bf58cd$d185cc90$e655cfc0@ski.org>
Message-ID: <NDBBIEFMILBFPMDHJIMFCEJECBAA.dubois1@llnl.gov>
I have been thinking lately that we have fallen into the Cathedral rather
than the Bazaar and we need to get out of that mode, so Travis' letter is
timely. We also have had a problem in that LLNL's new security regime has
made it difficult, and I really do need to move the sources somewhere. I am
ignorant of SourceForge.
I am open to suggestions as to what to do after David cuts his release.
From Oliphant.Travis@mayo.edu Sat Jan 8 21:58:33 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sat, 8 Jan 2000 15:58:33 -0600 (CST)
Subject: [Matrix-SIG] Numerical python on SourceForge?
Message-ID: <Pine.LNX.4.10.10001081549100.5017-100000@us2.mayo.edu>
SourceForge is a community site run by VA Linux that provides CVS and web
space to many open projects. http://sourceforge.net
From the site:
SourceForge is a free service to Open Source developers offering easy
access to the best in CVS, mailing lists, bug tracking, message
boards/forums, task management, site hosting, permanent file archival,
full backups, and total web-based administration.
I think it is an ideal site to allow community involvement in Numerical
Python development.
One of the outstanding issues that needs addressing quickly is how to
integrate Numerical Python into the core. Guido has expressed enough
interest that it would be a real shame not to get it in by Python 1.6
There are issues that need deciding however:
* Will Python still retain other Numeric Types or will rank-0 arrays and
Python Numeric objects become equivalent?
* How will FFTpack and LAPACK get distributed if NumPy is now in the
core?
to name just a couple.
It is straightforward to get an account on SourceForge and I for one would
heartily support such a move.
Travis
From jhauser@ifm.uni-kiel.de Sat Jan 8 23:18:39 2000
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Sun, 9 Jan 2000 00:18:39 +0100 (CET)
Subject: [Matrix-SIG] Numerical python on SourceForge?
In-Reply-To: <Pine.LNX.4.10.10001081549100.5017-100000@us2.mayo.edu>
References: <Pine.LNX.4.10.10001081549100.5017-100000@us2.mayo.edu>
Message-ID: <20000108231840.27054.qmail@lisboa.ifm.uni-kiel.de>
If a restructuring of the development model is considered, I would
like to raise some more questions. I agree with Travis that a
decision regarding the inclusion of parts of NumPy into python should
be made. Questions under this topic are:
- What parts? Is it important to be compatible with jpython or viper?
If nD-arrays go into the core, become they part of the language?
- I think all the higher level stuff (fft, lapack) should remain an
external module.
- Can these modules be separated in a similar form to other modules. I
mean, is it achievable to integrate e.g. the cephes module at the
same level as Numeric? Or deintegrate e.g. fft on the other hand?
- Should there be provisions made for the inclusion of new packages
into the source tree? This inflicts with the progress of the
distutils package.
- Should the documentation be made compatible to the normal python
module documentation? I would volunteer to reformat the
documentation.
- Are our needs fulfilled by sourceforge? I mean a first step would
be a public CVS (anonymous checkout, restricted checkin)
- Will gist be also part of this ``outsourcing''?
- Can some parts be restructured? I think about the array_map from
Travis and some code from the arrayfns module.
- Is it possible to include also some more IO stuff at the ``basic''
module level?
Stop!
Just as a side note, our perl counterpart pdl is already at
sourceforge :-)
__Janko
From Oliphant.Travis@mayo.edu Sun Jan 9 01:44:33 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sat, 8 Jan 2000 19:44:33 -0600 (CST)
Subject: [Matrix-SIG] Numerical python on SourceForge?
In-Reply-To: <20000108231840.27054.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <Pine.LNX.4.10.10001081933490.5375-100000@us2.mayo.edu>
>
> - What parts? Is it important to be compatible with jpython or viper?
> If nD-arrays go into the core, become they part of the language?
My vote is to eliminate Python Numeric Types and make them all rank-0
arrays. This would possibly involve changing rank-0 arrays in Numeric so
that don't have so much overhead. At the very least, arrays and
ufuncs should become standard types and umath and multiarray in the
standard library.
>
> - I think all the higher level stuff (fft, lapack) should remain an
> external module.
I agree.
>
> - Can these modules be separated in a similar form to other modules. I
> mean, is it achievable to integrate e.g. the cephes module at the
> same level as Numeric? Or deintegrate e.g. fft on the other hand?
I don't understand what you mean. Are you talking about distributing
cephes in a "standard" package or tying it more closely to Numeric. All
of this depends on what goes in to Python itself and what stays a separate
package.
>
> - Should there be provisions made for the inclusion of new packages
> into the source tree? This inflicts with the progress of the
> distutils package.
I think a separate project could handle "new packages" and take the Python
core and extend it with all kinds of Math goodies.
>
> - Should the documentation be made compatible to the normal python
> module documentation? I would volunteer to reformat the
> documentation.
Yes, definitely if it is going to be part of the language.
>
> - Are our needs fulfilled by sourceforge? I mean a first step would
> be a public CVS (anonymous checkout, restricted checkin)
I'm not sure. Lot's of people seem to be using sourceforge and it sure
looks nice. Certainly a CVS server would be a start with multiple people
allowed to check changes in.
>
> - Will gist be also part of this ``outsourcing''?
Gist is very nice but should definitely be an add-on,
>
> - Can some parts be restructured? I think about the array_map from
> Travis and some code from the arrayfns module.
What do you mean restructured? Do you mean that array_map and other
functions from arrayfns should go into the Python core along with the
basic modules? If so then I think that would be useful.
>
> - Is it possible to include also some more IO stuff at the ``basic''
> module level?
I agree. If the NumPy type is in the Python core then we need something
like numpyiomodule to get data into arrays quickly.
>
> Stop!
Please don't, let's keep going and get the ball rolling again.
>
> Just as a side note, our perl counterpart pdl is already at
> sourceforge :-)
From skaller@maxtal.com.au Sun Jan 9 14:44:02 2000
From: skaller@maxtal.com.au (skaller)
Date: Mon, 10 Jan 2000 01:44:02 +1100
Subject: [Matrix-SIG] Numerical python on SourceForge?
References: <Pine.LNX.4.10.10001081549100.5017-100000@us2.mayo.edu> <20000108231840.27054.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <38789EB2.A6AFD121@maxtal.com.au>
Janko Hauser wrote:
>
> If a restructuring of the development model is considered, I would
> like to raise some more questions. I agree with Travis that a
> decision regarding the inclusion of parts of NumPy into python should
> be made. Questions under this topic are:
>
> - What parts? Is it important to be compatible with jpython or viper?
> If nD-arrays go into the core, become they part of the language?
There is _currently_ no risk at all of an incompatibility with
Viper, since Viper does not even support the array module.
Viper doesn't have any array handling at all.
My problem is that NumPy doesn't _quite_ provide the
technology required for Fish, which is the best array handling around.
In particular, incorporation of Fish 1 style arrays into Viper,
if it is possible, would provide it with the fastest array
handling in the world.
Fish generates, compiles, and executes optimal code for array
algorithms. This is MUCH faster than any subroutine library could
ever be. Fish is also suitable for both vectorisation and
distributed parallel processing.
So there is an opportunity, perhaps, to make Python/Viper
the premier _industrial_ array processing language (outperforming
normal usage of fortran and C).
The style of Fish array handling integrated with Python
would be to use Python syntax to write array algorithms,
NOT subroutines for things like componentwise addition.
The reason is that such code can be 'inlined'
and optimised in a way that is impossible with 'opaque' routines.
Of course, some standard routines like componentwise addition
would be provided, and have the same syntax (probably) as used
by NumPy.
Fish currently uses an ML like front end, and it is not
clear that a Python like syntax can be used instead.
If NumPy has a problem, it is that the 'type' of
arrays is deficient: it is NOT enough to support just
some numeric cases and PyObject: it is _essential_ that
the type be recursive -- that is, NumPy arrays be allowed
as well.
I'd like to see the 'type-code' used in NumPy
be replaced by a proper object representing an array shape:
floats, PyObjects, etc, are degenerate cases of this.
I'm not sure this change can be made compatible
with NumPy -- but it sound feasible [the existing type
codes are a special encoding of degenerate cases of the
more general types.
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850
From skaller@maxtal.com.au Sun Jan 9 15:42:04 2000
From: skaller@maxtal.com.au (skaller)
Date: Mon, 10 Jan 2000 02:42:04 +1100
Subject: [Matrix-SIG] Numerical python on SourceForge?
References: <Pine.LNX.4.10.10001081933490.5375-100000@us2.mayo.edu>
Message-ID: <3878AC4C.276F69D@maxtal.com.au>
Travis Oliphant wrote:
>
> >
> > - What parts? Is it important to be compatible with jpython or viper?
> > If nD-arrays go into the core, become they part of the language?
>
> My vote is to eliminate Python Numeric Types and make them all rank-0
> arrays. This would possibly involve changing rank-0 arrays in Numeric so
> that don't have so much overhead.
No. This is wrong.
From the Fish tutorial, where #= means 'same shape':
--------- array shape combinators ---------------
zerodim sh #= {:sh}
undim {:int_shape } #= int_shape
succdim 7 {6:sh} #= {7,6:sh}
lendim {3,2:sh } = 3
preddim {3,2:sh } #= {2:sh}
numdim {4,3:sh} = 2
---------------------------------------------------
Here, 'fill .. with' is used to initialise an array:
---------------------------------------------------
>-|> let a3 = fill {:int_shape} with [5];;
a3 : [int]
#a3 = { : int_shape }
defines a zero dimensional array.
Just as a one dimensional array can be thought of as a line segment, or
vector,
a zero dimensional array can be construed a point with a single
associated value.
Such arrays should not be confused with the value of its unique entry
(which has a different
type) nor with the vector of length one, namely
>-|> let a4 = fill {1:int_shape} with [5];;
a4 : [int]
#a4 = { 1 : int_shape }
-----------------------------------------------------
PLEASE NOTE: a scalar is NOT a rank zero array.
Fish provides a 'get' function to get the single value
of a zero dimensional array.
The point is: there is no need to identify python
floats with a rank 0 array of float, in fact such identification
is WRONG. There is a distinct difference between
these two types, even though they are isomorphic
(and also isomorphic to a rank 1 array of dimension 1)
It is very important to get the shape calculus exactly right.
The Fish type/shape system was developed by one of the worlds
leading categories-in-computing theorists, Barry Jay.
In particular, the fears that the overhead of rank-0 NumPy
arrays are too high to identify them with Python numeric
scalars are unfounded, because the identification
itself is incorrect.
The right way to do this is as follows: in Python,
every 'scalar' type has a type object. We need a corresponding
'shape' object -- we can probably use the type object for this.
For arrays, the shape must consist of a list of lists of integers
and a scalar shape:
mk_shape([[7,6],[3,4]],FloatType)
or,
mk_shape(([7,6],[3,4]], "F") # "F" for float
or, alternatively, a list of integers and
any shape:
mk_shape([7,6], mk_shape([3,4], FloatShape))
Note that the second form would require scalar shape objects,
whereas the first will work with ordinary type objects
or perhaps a string code.
------------------------------------------
See
http://www-staff.mcs.uts.edu.au/~cbj/FISh/
for more information on Fish and array shape calculus.
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850
From Oliphant.Travis@mayo.edu Mon Jan 10 04:43:34 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sun, 9 Jan 2000 22:43:34 -0600 (CST)
Subject: [Matrix-SIG] Numerical python on SourceForge?
In-Reply-To: <38789EB2.A6AFD121@maxtal.com.au>
Message-ID: <Pine.LNX.4.10.10001092235250.7721-100000@us2.mayo.edu>
>
> There is _currently_ no risk at all of an incompatibility with
> Viper, since Viper does not even support the array module.
> Viper doesn't have any array handling at all.
>
> My problem is that NumPy doesn't _quite_ provide the
> technology required for Fish, which is the best array handling around.
> In particular, incorporation of Fish 1 style arrays into Viper,
> if it is possible, would provide it with the fastest array
> handling in the world.
Best is a pretty subjective measure. Fish may be fast but is it
convenient to use in an interactive setting? This is a more difficult
balance to achieve.
>
> Fish generates, compiles, and executes optimal code for array
> algorithms. This is MUCH faster than any subroutine library could
> ever be. Fish is also suitable for both vectorisation and
> distributed parallel processing.
What does it mean to generate and compile optimal code? Everytime I do an
array operation the compiler is called? How does that work in an
interactive session. What kinds of cross-platform issues are there?
>
> So there is an opportunity, perhaps, to make Python/Viper
> the premier _industrial_ array processing language (outperforming
> normal usage of fortran and C).
That sounds very good, but it would sound even better if it would not
require drastic changes to the basic NumPy syntax.
>
> The style of Fish array handling integrated with Python
> would be to use Python syntax to write array algorithms,
> NOT subroutines for things like componentwise addition.
>
> The reason is that such code can be 'inlined'
> and optimised in a way that is impossible with 'opaque' routines.
> Of course, some standard routines like componentwise addition
> would be provided, and have the same syntax (probably) as used
> by NumPy.
>
> Fish currently uses an ML like front end, and it is not
> clear that a Python like syntax can be used instead.
>
ML-like front ends have a hard time capturing the attention of
many scientists and engineers for day to day Numeric work. I have not had
much experience with them, but there is a reason that MATLAB is popular.
> If NumPy has a problem, it is that the 'type' of
> arrays is deficient: it is NOT enough to support just
> some numeric cases and PyObject: it is _essential_ that
> the type be recursive -- that is, NumPy arrays be allowed
> as well.
>
NumPy arrays are allowed currently. They are just another object that can
be placed in an array. What do you mean?
> I'd like to see the 'type-code' used in NumPy
> be replaced by a proper object representing an array shape:
> floats, PyObjects, etc, are degenerate cases of this.
>
I'm not sure what you mean here either. Could you sketch your idea of
what the C structure of the NumPy array should look like?
> I'm not sure this change can be made compatible
> with NumPy -- but it sound feasible [the existing type
> codes are a special encoding of degenerate cases of the
> more general types.
Again an example would help me see what you mean.
Travis
From Oliphant.Travis@mayo.edu Mon Jan 10 05:03:18 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sun, 9 Jan 2000 23:03:18 -0600 (CST)
Subject: [Matrix-SIG] Numerical python on SourceForge?
In-Reply-To: <3878AC4C.276F69D@maxtal.com.au>
Message-ID: <Pine.LNX.4.10.10001092248040.7721-100000@us2.mayo.edu>
>
> PLEASE NOTE: a scalar is NOT a rank zero array.
> Fish provides a 'get' function to get the single value
> of a zero dimensional array.
>
> The point is: there is no need to identify python
> floats with a rank 0 array of float, in fact such identification
> is WRONG. There is a distinct difference between
> these two types, even though they are isomorphic
> (and also isomorphic to a rank 1 array of dimension 1)
>
> It is very important to get the shape calculus exactly right.
> The Fish type/shape system was developed by one of the worlds
> leading categories-in-computing theorists, Barry Jay.
Well, I appreciate your insight, but frankly I don't really care whether
or not we are pedantic about the difference between a zero dimensional
array and a scalar. It may be an important disctinction for certain
algorithms; for me I do not see why it would make an algorithmic
difference for the current syntax.
What I do care about is that the current difference between rank-0 arrays
and Python basic types and the practice of always returning rank-0 arrays
as Python basic types means that it is an unnecessary pain to write code
that keeps all data in single precision. I have a colleague I'm trying to
convince to join us in the Python world who is very put off by this little
inconvenience. I wonder how many others there are like him.
Perhaps if arrays get into the core then even with the distinction between
NumPy arrays and basic types there will not be the problems there are
currently.
>
> The right way to do this is as follows: in Python,
> every 'scalar' type has a type object. We need a corresponding
> 'shape' object -- we can probably use the type object for this.
> For arrays, the shape must consist of a list of lists of integers
> and a scalar shape:
>
> mk_shape([[7,6],[3,4]],FloatType)
>
> or,
>
> mk_shape(([7,6],[3,4]], "F") # "F" for float
>
> or, alternatively, a list of integers and
> any shape:
>
> mk_shape([7,6], mk_shape([3,4], FloatShape))
>
I've looked at the FISh web pages and it does look impressive. I'm
missing how it could by applied to an interactive environment with Python
syntax? I know you've tried to explain FISh in the past. But I need a
little more help understanding how it would work with Python.
Thanks for your help,
Travis
From dubois1@llnl.gov Mon Jan 10 16:46:29 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Mon, 10 Jan 2000 08:46:29 -0800
Subject: [Matrix-SIG] LLNLDistribution13
In-Reply-To: <Pine.LNX.4.10.10001092217530.7721-100000@us2.mayo.edu>
Message-ID: <NDBBIEFMILBFPMDHJIMFIEKECBAA.dubois1@llnl.gov>
Dear Matrix-SIGERS,
ftp-icf.llnl.gov/pub/python/LLNLDistribution13.tgz is available for testing.
David and I have tested it on Linux and Windows.
Starting with this release, this distribution ONLY contains Numerical. It
includes the PDF version of the documentation and the tutorial in directory
"Doc".
Here are my plans:
1. Move the sources to an open server. Recent and planned LLNL security
measures have made LLNL a poor choice for locating open source software
sources. I will do this as soon as I can, probably right after IPC8, where I
can talk to some of you about the best way to do this.
2. In the next release, switch to using Distutils for building and
installing.
3. Set up the sources so that all other packages (both LLNL and yours) are
contributed separately. This will eventually include the ones now contained
in the Numerical distribution itself. The reasons are that there are
competing packages in some of these areas, and in fact I do not test or
modify those packages so dragging them along with the core is misleading.
The standards for packages will include documentation and Distutils
requirements, so that the user has an absolutely cookbook "python setup.py
build install" procedure for each package.
4. I do not intend to supply Windows installers. Once the sources are in an
open spot, I expect a champion to step forward who will do this. Start now.
The inertia of having to make Windows binary releases is a major cause for
my slow releases. I want to switch to Bazaar mode.
From turner@blueskystudios.com Mon Jan 10 17:08:29 2000
From: turner@blueskystudios.com (John A. Turner)
Date: Mon, 10 Jan 2000 12:08:29 -0500 (EST)
Subject: [Matrix-SIG] LLNLDistribution13
In-Reply-To: <NDBBIEFMILBFPMDHJIMFIEKECBAA.dubois1@llnl.gov>
References: <Pine.LNX.4.10.10001092217530.7721-100000@us2.mayo.edu>
<NDBBIEFMILBFPMDHJIMFIEKECBAA.dubois1@llnl.gov>
Message-ID: <14458.4621.490623.886653@waterloo.blueskystudios.com>
>>>>> "PFD" == Paul F Dubois <dubois1@llnl.gov> writes:
PFD> 1. Move the sources to an open server. Recent and planned LLNL security
PFD> measures have made LLNL a poor choice for locating open source
PFD> software sources. I will do this as soon as I can, probably right
PFD> after IPC8, where I can talk to some of you about the best way to
PFD> do this.
I realize that there are Python-oriented sites like Starship, but
another excellent alternative is the site VA Linux recently set up for
hosting open source projects, SourceForge:
http://sourceforge.net/
In addition to just hosting a site and providing disk space, it can
provide CVS access, bug-tracking system, etc. - full list of services
here:
http://sourceforge.net/docs/site/services.php
Anyway, something to think about, maybe...
-John Turner
From dubois1@llnl.gov Mon Jan 10 17:12:33 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Mon, 10 Jan 2000 09:12:33 -0800
Subject: [Matrix-SIG] LLNLDistribution13
In-Reply-To: <14458.4621.490623.886653@waterloo.blueskystudios.com>
Message-ID: <NDBBIEFMILBFPMDHJIMFCEKFCBAA.dubois1@llnl.gov>
I just failed in four attempts to set up the project at SourceForge. No
doubt this is due to my dreaded use of Internet Explorer...
Ah, well, I'll keep trying.
-----Original Message-----
From: John A. Turner [mailto:turner@blueskystudios.com]
Sent: Monday, January 10, 2000 9:08 AM
To: dubois1@llnl.gov
Cc: matrix-sig@python.org; williams13@llnl.gov; guido@python.org
Subject: Re: [Matrix-SIG] LLNLDistribution13
>>>>> "PFD" == Paul F Dubois <dubois1@llnl.gov> writes:
PFD> 1. Move the sources to an open server. Recent and planned LLNL security
PFD> measures have made LLNL a poor choice for locating open source
PFD> software sources. I will do this as soon as I can, probably right
PFD> after IPC8, where I can talk to some of you about the best way to
PFD> do this.
I realize that there are Python-oriented sites like Starship, but
another excellent alternative is the site VA Linux recently set up for
hosting open source projects, SourceForge:
http://sourceforge.net/
In addition to just hosting a site and providing disk space, it can
provide CVS access, bug-tracking system, etc. - full list of services
here:
http://sourceforge.net/docs/site/services.php
Anyway, something to think about, maybe...
-John Turner
From dubois1@llnl.gov Mon Jan 10 17:42:17 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Mon, 10 Jan 2000 09:42:17 -0800
Subject: [Matrix-SIG] File corrected
Message-ID: <NDBBIEFMILBFPMDHJIMFCEKHCBAA.dubois1@llnl.gov>
I fixed the LLNLDistribution13.tgz at 9:35 a.m. PST
The Include directory was omitted from the first tar.
This turned out to be because my source control system had messed up. I'm
trying to run it down an SSH tunnel because some unannounced security
changes here blew me out of the water, and all sorts of weird things are
happening...sorry for the mistake. It is very secure, though. Nobody can get
my stuff, including me.
As I said in a previous message, my attempt to set up the project on Source
Forge has failed and I await their reply. (This was going to be an attempt
to see if I liked it, not a final decision to do it that way).
From pauldubois@home.com Mon Jan 10 19:31:40 2000
From: pauldubois@home.com (Paul F. Dubois)
Date: Mon, 10 Jan 2000 11:31:40 -0800
Subject: [Matrix-SIG] This time for sure
Message-ID: <NDBBIEFMILBFPMDHJIMFAEKLCBAA.pauldubois@home.com>
As Bullwinkle says, "This time for sure."
At 11:30 a.m. PST 1/10/00 I tried to make a tar file that really does have
the whole thing in it.
If you are missing Include and/or Lib, refetch LLNLDistribution13.tgz from:
ftp-icf.llnl.gov/pub/python
I'm going to go hide under a rock for the rest of the day.
From Barrett@stsci.edu Mon Jan 10 19:46:13 2000
From: Barrett@stsci.edu (Paul Barrett)
Date: Mon, 10 Jan 2000 14:46:13 -0500 (EST)
Subject: [Matrix-SIG] Numerical python on SourceForge?
In-Reply-To: <Pine.LNX.4.10.10001092235250.7721-100000@us2.mayo.edu>
References: <38789EB2.A6AFD121@maxtal.com.au>
<Pine.LNX.4.10.10001092235250.7721-100000@us2.mayo.edu>
Message-ID: <14458.7958.737985.342132@nem-srvr.stsci.edu>
In the same vein of this discussion, I would also like to see several
fundamental enhancements to Numerical python:
1) I've yet to become competent using the Object type in Numeric.
I've seen the example in the documentation of creating an array of
Objects by ingesting a list of tuples, but have yet to understand
how to create such an array from a string or file, which appears to
me to be a more common - and faster - way of ingesting the data.
As a result I've implemented my own C-type called 'record' which is
basically a generalization of the struct module to arrays. The
record module enables quick and efficient access to sub-arrays and
subfields of the record. The implementation - though pretty basic
at this time - is very similar to Numeric. Instead of specifying a
single type code, you specify a list of type codes. Therefore it
would seem logical to merge my record module into Numeric, assuming
Numeric cannot do what my module can. I'm hoping that this is what
Max Skaller is suggesting.
2) The issue of up-casting of types has been mentioned in the Matrix
SIG many moons ago. This is still a very important issue for me
and others in the astronomical community. Astronomical images of
16 million pixels and larger are now routinely being taken. The
analysis of such images - at least on a first look basis - are not
very complicated, therefore simple array manipulation methods are
quite satisfactory. Yet the problem that we have is storing and
manipulating this images in memory. We're talking 128 MB of RAM
for just storing a double precision 16M pixel image, when 64 MB or
less will do. I see two solution here: 1) add an option to prevent
up-casting, 2) memory mapping of these large arrays, or 3) both. I
will likely have to implement my own Numeric module if this issue
is not implemented satisfactorily.
3) Enable Numeric arrays to accept another array as an array
argument. This would enable a more efficient implementation of
scatter/gather behavior. This issue appears to be more of a Python
language syntax issue that an implementation issue, I believe.
I'm open to other suggestions on these issues as long as they give
similar results and the syntax is not overly cumbersome. I've had
little time to work on these issues in the past, but hope to find some
time in the next few months to investigate these issues in greater
detail. To reiterate, for Numerical Python to be useful to the
astronomical community, these issues will have to be dealt with and the
soon they are, the better.
-- Paul
--
Dr. Paul Barrett Space Telescope Science Institute
Phone: 410-516-6714 ESS/DPT
FAX: 410-516-8615 Baltimore, MD 21218
From skaller@maxtal.com.au Mon Jan 10 20:20:49 2000
From: skaller@maxtal.com.au (skaller)
Date: Tue, 11 Jan 2000 07:20:49 +1100
Subject: [Matrix-SIG] Numerical python on SourceForge?
References: <38789EB2.A6AFD121@maxtal.com.au>
<Pine.LNX.4.10.10001092235250.7721-100000@us2.mayo.edu> <14458.7958.737985.342132@nem-srvr.stsci.edu>
Message-ID: <387A3F21.5E9B88AF@maxtal.com.au>
Paul Barrett wrote:
> Instead of specifying a
> single type code, you specify a list of type codes. Therefore it
> would seem logical to merge my record module into Numeric, assuming
> Numeric cannot do what my module can. I'm hoping that this is what
> Max Skaller is suggesting.
No: I'm suggesting arrays be generalised to allow the type
of element to be either a number or an array; more generally,
_any_ data type.
By using 'PyObjectType', this would make an array equivalent to
a tuple, but this isn't really the intent, so much as making arrays
of arrays of arrays of floats available (where _each_ array can
separately
be arbitrary rank)
The reason for doing this is that by manipulating
the shape of an array of arrays of float, we can decide where the
'data' sits, which affects how we can apply functions like 'map'
to the arrays. Note that the _storage_ for an array of arrays of
floats does NOT store any PyObjects: its just maps the shape
onto a linear array of floats. (Same as NumPy does now).
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller
voice: 61-2-9660-0850
From dubois1@llnl.gov Mon Jan 10 20:22:24 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Mon, 10 Jan 2000 12:22:24 -0800
Subject: [Matrix-SIG] thoughts about the future
In-Reply-To: <14458.7958.737985.342132@nem-srvr.stsci.edu>
Message-ID: <NDBBIEFMILBFPMDHJIMFAEKNCBAA.dubois1@llnl.gov>
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01BF5B65.5A1AE600
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
There are two separate concepts and NumPy attempts to do both of them:
1. Provide an "array" object that can store a large number of items of one
type in as small a space as possible.
2. Provide for rapid operations and fancy subscripting and shapes, etc.
I believe (1) belongs in the Python core. I think they should be 1-D only
with basic math operations. Both Python and C APIs would allow you to create
such arrays and to create ones that do not "own" the memory in question,
similar to the options in NumPy. Along with this the : notation would be
allowed outside of square brackets, so that r= 3:1000:10 would be a "range"
object. This allows these subscripts as function arguments, enabling
Fortran-like syntax and many other interesting applications. It is a design
question whether there is one array type with a variable data type or
different array types. I think it is really a generic parameter to the class
but Python lacks such a concept.
One or more facilities can then be build on top of (1) that satisfy
different needs. I'm convinced that no one design will ever satisfy
everyone. Those who need blinding speed and no upcasting are unlikely to
ever get along with the "safe and easy to use for my customers" group. But
for a start we could reproduce the semantics we have now.
An illustration of my reasoning is the number of "bug reports" I receive
about the fact that NumPy crashes with this or that bad input. The original
designer did not test for bad input in order not to compromise performance.
Considering this from a Design by Contract perspective, most NumPy operators
have strong preconditions. This would be fine except they aren't stated
using assertions so there is no "debug mode". We should go through NumPy and
add the assertions.
Another illustration is the x[i:j] question: is this a copy or a reference?
For non-speed users, the present "reference" semantics are terrible. But you
can hide that in a (2) facility. For reference I attach a copy of a "missing
value" class (not completely done yet) that illustrates the approach.
There are also many schools of thought about shape facilities and
subscripting in general. I have my own opinions and I'm sure each of you
does too.
I grant that it will be a pity to have more than one competing high-level
package, but if all packages share the common core array as their storage
mechanisms it ought not to be too bad to pass things back and forth.
------=_NextPart_000_0000_01BF5B65.5A1AE600
Content-Type: text/plain;
name="MA.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="MA.py"
"""MA facility Copyright 1999 Regents of the University of California.
Released for unlimited redistribution; see file Legal.htm in Numerical =
distribution."""
__version__ =3D 2.0
#This version gives up on the Extension Class stuff
import Numeric
from Precision import *
import string, types
class MAError (Exception):
def __init__ (self, args=3DNone):
self.args =3D args
def __str__(self):
return str(self.args)
__MaxElements =3D 300 #Maximum size for printing
def setMaxElements (m):
"Set the maximum # of elements for printing arrays. "
global __MaxElements
n =3D int(m)
if n <=3D 0: raise ValueError, "setMaxElements requires positive =
argument."
__MaxElements =3D n
def getMaxElements ():
"Get the maximum # of elements for printing arrays. "
global __MaxElements
return __MaxElements
def getmask (a):
"Mask of values in a, if any; None otherwise."
if isMA(a):=20
return a.mask()
else:=20
return None
def getmaskarray (a):
"Mask of values in a, ones if none."
m =3D getmask(a)
if m is None:
return Numeric.ones(shape(a))
else:
return m
def mask_or (m1, m2):
"Logical or of the masks m1 and m2, treating None as false."
if m1 is None: return m2
if m2 is None: return m1
return Numeric.logical_or(m1, m2)
def filled (a, value =3D None):
"""
a as a Numeric array with any masked areas replaced by value"
No data copied if no masked area and data is already an array.
"""
if isMA(a):
return a.filled(value)
else:
return Numeric.array(a, copy=3D0)
class masked_unary_operation:
def __init__ (self, aufunc, fill=3D0):
self.f =3D aufunc
self.fill =3D fill
def __call__ (self, a):
m =3D getmask(a)
d1 =3D filled(a)
if m is None:
return self.f(d1)
else:
return MA(self.f(d1), m)
class masked_binary_operation:
def __init__ (self, aufunc, fill=3D0):
self.f =3D aufunc
self.fill =3D fill
def __call__ (self, a, b):
d1 =3D filled(a, self.fill)
d2 =3D filled(b, self.fill)
m =3D mask_or(getmask(a), getmask(b))
if m is None:
return self.f(d1, d2)
else:
return MA(self.f(d1,d2), m)
def reduce (self, target, axis=3D0):
m =3D getmask(target)
if m is None:
return self.f.reduce (target, axis)
else:
t =3D target.filled(self.fill)
tr =3D self.f.reduce(t, axis)
m =3D Numeric.logical_and.reduce(m, axis)
return MA(tr, m)
class comparison:
"A comparison function that returns a plain mask after doing the =
comparison"
def __init__ (self, f, fill1, fill2):
self.f =3D f
self.fill1 =3D fill1
self.fill2 =3D fill2
def __call__ (self, a, b):
return self.f(filled(a, self.fill1), filled(b, self.fill2))
# class MA =20
# the use of filled in the constructor
# makes sure we don't get MA's in data or mask=20
# This prevents recursion
# and we can assume these are array objects (or None for mask).
# Note current implementation assumes mask is 1's and 0's
# so that we can use Numeric.choose in filled.
class MA:
"Arrays with possibly masked values."
default_real_fill_value =3D 0.0
default_complex_fill_value =3D 0.0 + 0.0j
default_character_fill_value =3D ' '
default_integer_fill_value =3D 0
default_unsigned_integer_fill_value =3D 0
default_object_fill_value =3D None
def __init__(self, data, mask=3DNone, **keys):
"""MA(data, mask=3DNone)"""
self.__data =3D filled(data)
if mask is None:
self.__mask =3D None
else:
self.__mask =3D filled(mask, 1)
def __getattr__ (self, name):
if name =3D=3D 'shape':
return self.get_shape()
else:
return self.__dict__[name]
def __setattr__ (self, name, value):
if name =3D=3D 'shape':
self.set_shape(value)
else:
self.__dict__[name] =3D value
def __str__(self):
return str(self.filled())
def __repr__(self):
if self.__mask is None:
return "MA(" + repr(filled(self)) + ")"
else:
return "MA(" + repr(filled(self)) + ", \n " + \
repr(self.__mask) + ")"
def __float__(self):
return MA (float(self.filled(0.0)), self.__mask)
def __int__(self):
return MA(int(self.filled(0)), self.__mask)
# Note copy semantics here differ from Numeric =20
def __getitem__(self, i):=20
m =3D self.__mask
if m is None:
return Numeric.array(self.__data[i])
else:
return MA(Numeric.array(self.__data[i]), =
Numeric.array(m[i]))
def __getslice__(self, i, j):=20
m =3D self.__mask
if m is None:
return Numeric.array(self.__data[i:j])
else:
return MA(Numeric.array(self.__data[i:j]), =
Numeric.array(m[i:j]))
# --------
def __setitem__(self, index, value):
self.__data[index] =3D filled(value)
self.__mask =3D mask_or(self.__mask, getmask(value))
=20
def __setslice__(self, i, j, value):
self.__data[i:j] =3D filled(value)
m =3D getmask(value)
if m is not None:
sm =3D getmaskarray(self)
sm[i:j] =3D mask_or(sm[i:j], m)
self.__mask =3D sm
def __len__ (self):
"Return total number of elements in array."
return self.size()
def __cmp__ (self, other):
raise MAError, "Cannot use comparison operators on MA =
instances."
=20
def __abs__(self):=20
return masked_unary_operation(Numeric.absolute)(self)
def __neg__(self):=20
return masked_unary_operation(Numeric.negative)(self)
def __add__(self, other):=20
return masked_binary_operation(Numeric.add)(self, other)
=20
__radd__ =3D __add__
def __sub__(self, other):=20
return masked_binary_operation(Numeric.subtract,0)(self, other)
def __rsub__(self, other):=20
return masked_binary_operation(Numeric.subtract,0)(other, self)
def __mul__(self, other):=20
return masked_binary_operation(Numeric.multiply,0)(self, other)
=20
__rmul__ =3D __mul__
def __div__(self, other):=20
return divide(self, other)
def __rdiv__(self, other):=20
return divide(other, self)
def __pow__(self,other, third=3DNone):=20
if third is not None:=20
raise MAException, "3 arg power unspoorted"
return masked_binary_operation(Numeric.power, 1)(self, other)
def __sqrt__(self):=20
return masked_unary_operation(Numeric.sqrt,0)(self)
def default_fill_value (self):
"Function to calculate default fill value for an array."
x =3D self.typecode()
if x in typecodes['Float']:
return MA.default_real_fill_value
if x in typecodes['Integer']:
return MA.default_integer_fill_value
if x in typecodes['Complex']:
return MA.default_complex_fill_value
if x in typecodes['Character']:
return MA.default_character_fill_value
if x in typecodes['UnsignedInteger']:
return Numeric.absolute(MA.default_integer_fill_value)
else:
return MA.default_object_fill_value
def set_fill_value (self, v):
"Set the fill value to v."
self.fill_value =3D v
def filled (self, value=3DNone):
""" Self with masked data replaced by value.
If value is None, self.fill_value used.
self.default_fill_value () used if value is None.
Not a copy if no masked data.
Result is romised to be a Numeric.array.
"""
if self.__mask is None:
return self.__data
else:
if value is None:
if hasattr(self, 'fill_value'):
v =3D self.fill_value
else:
v =3D self.default_fill_value ()
self.fill_value =3D v
else:
v =3D value
return Numeric.choose(self.__mask, (self.__data, v))
def get_shape(self):
"Return the tuple giving the current shape."
return self.__data.shape
def ids (self):
"""Return the ids of the data and mask areas"""
return (id(self.__data), id(self.__mask))
def mask(self):
"Return the data mask, or None."
return self.__mask
=20
def set_shape (self, *sizes):
"""shape(n, m, ...) sets the shape."""
self.__data.shape =3D sizes
if self.__mask is not None:
self.__mask.shape =3D sizes
=20
def size (self, axis =3D None):
"Number of elements in array, or in a particular axis."
s =3D self.shape
if axis is None:
return reduce(Numeric.multiply, s, 1)
else:
return s[axis]
=20
def typecode(self):
return self.__data.typecode()
# these are disgusting
def is_contiguous (self):
return self.data.is_contiguous()
def byte_swapped(self):
return self.data.byte_swapped()
=20
def isMA (x):
"Is x an instance of MA?"
return isinstance(x, MA)
def masked_array (data, masked_value, typecode=3DNone, copy=3D1, =
atol=3D1.e-8, rtol=3D1.e-8, notest=3D0):
"""Create a masked array for numerical data; no mask unless =
necessary
or if notest !=3D 0
"""
abs =3D Numeric.absolute
d =3D Numeric.array(data, typecode=3Dtypecode, copy=3Dcopy)
dm =3D Numeric.less(abs(d-masked_value), atol+rtol*abs(d))
if notest or Numeric.sometrue(Numeric.ravel(dm)):
result =3D MA(d, dm)
else:
result =3D MA(d)
result.set_fill_value(masked_value)
return result
=20
def masked_object (data, masked_value, copy=3D1):
"Create a masked array of places where exactly equal to masked =
value"
dm =3D Numeric.equal(data, masked_value, copy=3Dcopy)
return MA(data, dm)
=20
def rank (a):
"Get the rank of a"
return len(shape(a))
=20
def shape (a):
"Get the shape of a"
if isMA (a):
return a.get_shape()
else:
return Numeric.shape(a)
def size (a, axis=3DNone):
"Get the number of elements in a, or along a certain axis."
if isMA (a):
return a.size(axis)
else:
s =3D Numeric.shape(a)
if axis is None:
return reduce(Numeric.multiply, s, 1)
else:
return s[axis]
def count (a, axis =3D None):
"Count of the non-masked elements." =20
m =3D getmask(a)
if m is None:
return size(a, axis)
else:
n1 =3D size(a, axis)
n2 =3D sum (m, axis)
return n1 - n2
def sum (a, axis =3D None):
"Sum of all elements, or along a certain axis"
if axis is None:
return Numeric.add.reduce(Numeric.ravel(filled(a, 0)))
else:
return Numeric.add.reduce(filled(a, 0), axis)
=20
def product (a, axis =3D None):
"Product of all elements, or along a certain axis."
if axis is None:
return Numeric.add.reduce(Numeric.ravel(filled(a, 0)))
else:
return Numeric.add.reduce(filled(a, 0), axis)
def average(a, axis=3DNone):
"Average of the nonmasked elements of a"
c =3D 1.0 * count(a, axis)
a =3D sum(a, axis)=20
return divide(a, c)
=20
NewAxis =3D Numeric.NewAxis
arange =3D Numeric.arange
ones =3D Numeric.ones
zeros =3D Numeric.zeros
array =3D Numeric.array
#minimum, maximum?
#searchsorted?
sqrt =3D masked_unary_operation(Numeric.sqrt, 0.0)
sin =3D masked_unary_operation(Numeric.sin, 0.0)
cos =3D masked_unary_operation(Numeric.cos, 0.0)
absolute =3D masked_unary_operation(Numeric.absolute, 0)
negative =3D masked_unary_operation(Numeric.negative, 0)
absolute =3D masked_unary_operation(Numeric.absolute, 0)
nonzero =3D masked_unary_operation(Numeric.nonzero, 0)
add =3D masked_binary_operation(Numeric.add, 0)
subtract =3D masked_binary_operation(Numeric.subtract, 0)
multiply =3D masked_binary_operation(Numeric.multiply, 1)
power =3D masked_binary_operation(Numeric.power, 1)
sometrue =3D masked_unary_operation(Numeric.sometrue, 0)
alltrue =3D masked_unary_operation(Numeric.alltrue, 1)
# all these comparisons return false where masks are true =20
equal =3D comparison(Numeric.equal, 0, 1)
not_equal =3D comparison(Numeric.not_equal, 0, 0)
less_equal =3D comparison(Numeric.less_equal, 1, 0)
greater_equal =3D comparison(Numeric.greater_equal, 0, 1)
less =3D comparison(Numeric.less, 1, 0)
greater =3D comparison(Numeric.greater, 0, 1)
def choose (condition, t):
"Shaped like condition, values t[0] where condition true, t[1] =
otherwise"
d =3D Numeric.choose(filled(condition,0), map(filled, t))
m =3D Numeric.choose(filled(condition,0), map(getmaskarray, t))
return MA(d, m)
def where (condition, x, y):
return choose(Numeric.not_equal(condition, 0), (y, x))
def reshape (a, newshape):
"Copy of a with a new shape."
m =3D getmask(a)
d =3D Numeric.reshape(filled(a), newshape)
if m is None:
return d
else:
return MA(d, Numeric.reshape(m, newshape))
def ravel (a):
"a as one-dimensional, may share data and mask"
m =3D getmask(a)
d =3D Numeric.ravel(filled(a)) =20
if m is None:
return d
else:
return MA(d, Numeric.ravel(m))
def concatenate (somearrays, axis=3D0):
"concatenate the arrays along the given axis"
d =3D Numeric.concatenate(map(filled, somearrays), axis)
dm =3D Numeric.concatenate(map(getmaskarray, somearrays), axis)
return MA(d, dm)
def take (a, indices, axis=3D0):
m =3D getmask(a)
d =3D filled(a)
if m is None:
return Numeric.take(d, indices, axis)
else:
return MA(Numeric.take(d, indices, axis),=20
Numeric.take(m, indices, axis))
=20
def divide (x, y):
"a/b, masked where b was masked or zero"
a =3D filled(x, 0)
b =3D filled(y, 1)
bad_elements =3D equal(b, 0)
c_mask =3D mask_or(mask_or(getmask(a), getmask(b)), bad_elements)
return MA(Numeric.divide(a, b), c_mask)
=20
# This section is stolen from a post about how to limit array printing.
def limitedArrayRepr(a, max_line_width =3D None, precision =3D None, =
suppress_small =3D None):
global __MaxElements
s =3D a.shape
elems =3D Numeric.multiply.reduce(s)
if elems > __MaxElements:
if len(s) > 1:
return 'array (%s) , type =3D %s, has %d elements' % \
(string.join(map(str, s), ","), a.typecode(), elems)
else:
return Numeric.array2string (a[:__MaxElements], =
max_line_width, precision,
suppress_small,',',0) + \
('\n + %d more elements' % (elems - __MaxElements))
else:
return Numeric.array2string (a, max_line_width, precision,=20
suppress_small,',',0)
# replace the default with a smarter function for huge arrays
original_array_repr =3D Numeric.array_repr
original_array_str =3D Numeric.array_str
Numeric.array_repr =3D limitedArrayRepr
Numeric.array_str =3D limitedArrayRepr
# fixup multiarray, as well.
import multiarray
multiarray.set_string_function(limitedArrayRepr, 0)
multiarray.set_string_function(limitedArrayRepr, 1)
if __name__ =3D=3D '__main__':
import MAtest
------=_NextPart_000_0000_01BF5B65.5A1AE600--
From skaller@maxtal.com.au Mon Jan 10 21:05:02 2000
From: skaller@maxtal.com.au (skaller)
Date: Tue, 11 Jan 2000 08:05:02 +1100
Subject: [Matrix-SIG] thoughts about the future
References: <NDBBIEFMILBFPMDHJIMFAEKNCBAA.dubois1@llnl.gov>
Message-ID: <387A497E.C314991F@maxtal.com.au>
"Paul F. Dubois" wrote:
>
> There are two separate concepts and NumPy attempts to do both of them:
>
> 1. Provide an "array" object that can store a large number of items of one
> type in as small a space as possible.
>
> 2. Provide for rapid operations and fancy subscripting and shapes, etc.
Probably, this is right, but Python _already_ provides
an array module for linear arrays of a particular type.
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller
From jhauser@ifm.uni-kiel.de Mon Jan 10 21:17:18 2000
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Mon, 10 Jan 2000 22:17:18 +0100 (CET)
Subject: [Matrix-SIG] thoughts about the future
In-Reply-To: <NDBBIEFMILBFPMDHJIMFAEKNCBAA.dubois1@llnl.gov>
References: <14458.7958.737985.342132@nem-srvr.stsci.edu> <NDBBIEFMILBFPMDHJIMFAEKNCBAA.dubois1@llnl.gov>
Message-ID: <20000110211719.7911.qmail@lisboa.ifm.uni-kiel.de>
--myGD1QTv+O
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-Description: message body text
Regarding ``range objects''. Partly we have already such things with
the slice object. So you can write:
var=ones((50,10,20))
a=RangeObject[:30,0,:-10]
var[a]
It's written by Konrad Hinsen. I append the class which he calls
``indexing''. This needs to be extended if something like gathering is
implemented. Despites his comment it does work with:
[...],[:,3],[3,-3,...]
__Janko
--myGD1QTv+O
Content-type: application/octet-stream
Content-transfer-encoding: base64
Content-Disposition: attachment;
filename="indexing.py"
IyBBIG5pY2VyIHdheSB0byBidWlsZCB1cCBpbmRleCB0dXBsZXMgZm9yIGFycmF5cy4KIwoj
IFlvdSBjYW4gZG8gYWxsIHRoaXMgd2l0aCBzbGljZSgpIHBsdXMgYSBmZXcgc3BlY2lhbCBv
YmplY3RzLAojIGJ1dCB0aGVyZSdzIGEgbG90IHRvIHJlbWVtYmVyLiBUaGlzIHZlcnNpb24g
aXMgc2ltcGxlciBiZWNhdXNlCiMgaXQgdXNlcyB0aGUgc3RhbmRhcmQgYXJyYXkgaW5kZXhp
bmcgc3ludGF4LgojCiMgRm9yIGFueSBpbmRleCBjb21iaW5hdGlvbiwgaW5jbHVkaW5nIHNs
aWNpbmcgYW5kIGF4aXMgaW5zZXJ0aW9uLAojIGFbaW5kaWNlc10gaXMgdGhlIHNhbWUgYXMg
YVtpbmRleF9leHByZXNzaW9uW2luZGljZXNdXS4gSG93ZXZlciwKIyBpbmRleF9leHByZXNz
aW9uW2luZGljZXNdIGNhbiBiZSB1c2VkIGFueXdoZXJlIGluIFB5dGhvbiBjb2RlCiMgYW5k
IHJldHVybnMgYSB0dXBsZSBvZiBpbmRleGluZyBvYmplY3RzIHRoYXQgY2FuIGJlIHVzZWQg
aW4gdGhlCiMgY29uc3RydWN0aW9uIG9mIGNvbXBsZXggaW5kZXggZXhwcmVzc2lvbnMuCiMK
IyBTb2xlIHJlc3RyaWN0aW9uOiBTbGljZXMgbXVzdCBiZSBzcGVjaWZpZWQgaW4gdGhlIGRv
dWJsZS1jb2xvbgojIGZvcm0sIGkuZS4gYVs6Ol0gaXMgYWxsb3dlZCwgd2hlcmVhcyBhWzpd
IGlzIG5vdC4KIwojIFdyaXR0ZW4gYnkgS29ucmFkIEhpbnNlbiA8aGluc2VuQGlicy5pYnMu
ZnI+CiMgbGFzdCByZXZpc2lvbjogMTk5Ni0xMS0yNQojCgpjbGFzcyBfaW5kZXhfZXhwcmVz
c2lvbl9jbGFzczoKCiAgICBpbXBvcnQgc3lzCiAgICBtYXhpbnQgPSBzeXMubWF4aW50Cgog
ICAgZGVmIF9fZ2V0aXRlbV9fKHNlbGYsIGl0ZW0pOgogICAgICAgIGlmIHR5cGUoaXRlbSkg
IT0gdHlwZSgoKSk6CiAgICAgICAgICAgIHJldHVybiAoaXRlbSwpCiAgICAgICAgZWxzZToK
ICAgICAgICAgICAgcmV0dXJuIGl0ZW0KCiAgICBkZWYgX19sZW5fXyhzZWxmKToKCXJldHVy
biBzZWxmLm1heGludAoKICAgIGRlZiBfX2dldHNsaWNlX18oc2VsZiwgc3RhcnQsIHN0b3Ap
OgoJaWYgc3RvcCA9PSBzZWxmLm1heGludDoKCSAgICBzdG9wID0gTm9uZQoJcmV0dXJuIHNl
bGZbc3RhcnQ6c3RvcDpOb25lXQoKc2xfb3AgPSBfaW5kZXhfZXhwcmVzc2lvbl9jbGFzcygp
Cg==
--myGD1QTv+O--
From pauldubois@home.com Mon Jan 10 22:01:10 2000
From: pauldubois@home.com (Paul F. Dubois)
Date: Mon, 10 Jan 2000 14:01:10 -0800
Subject: [Matrix-SIG] Release 14
Message-ID: <NDBBIEFMILBFPMDHJIMFKEKNCBAA.pauldubois@home.com>
ftp-icf.llnl.gov/pub/python/Numerical-14.tgz is available for download.
This version is identical to 13 except that the installation procedure is
changed to use Distutils.
Thanks to the Distutils gang for the already-working setup.py file.
No more versions are planned for today. (:->.
Paul
From skaller@maxtal.com.au Tue Jan 11 08:33:23 2000
From: skaller@maxtal.com.au (skaller)
Date: Tue, 11 Jan 2000 19:33:23 +1100
Subject: [Matrix-SIG] Numerical python on SourceForge?
References: <Pine.LNX.4.10.10001092248040.7721-100000@us2.mayo.edu>
Message-ID: <387AEAD3.DFE43D41@maxtal.com.au>
Travis Oliphant wrote:
> > It is very important to get the shape calculus exactly right.
> > The Fish type/shape system was developed by one of the worlds
> > leading categories-in-computing theorists, Barry Jay.
>
> Well, I appreciate your insight, but frankly I don't really care whether
> or not we are pedantic about the difference between a zero dimensional
> array and a scalar.
> What I do care about is that the current difference between rank-0 arrays
> and Python basic types and the practice of always returning rank-0 arrays
> as Python basic types means that it is an unnecessary pain to write code
> that keeps all data in single precision.
So you DO care :-)
> Perhaps if arrays get into the core then even with the distinction between
> NumPy arrays and basic types there will not be the problems there are
> currently.
Well, arrays will get into the Viper core.
The reason they're not available at the moment is precisely
because I care a lot for numerical programming. So whatever
Guido does, there _will_ be a pythonic numerical programming
environment available: the issue for me at the moment is
whether to just stick with NumPy as is, or go for the broke,
and provide the best high performance system available.
> I've looked at the FISh web pages and it does look impressive.
I worked on Fish, and I'm impressed too.
That doesn't happen very often :-)
> I'm missing how it could by applied to an interactive environment with Python
> syntax? I know you've tried to explain FISh in the past. But I need a
> little more help understanding how it would work with Python.
you are asking two questions, about interactivity,
and about syntax.
Interactivity is not a problem: for _small_ problems,
Fish will be slower than even plain Python, but as the size
of the problems grows, it will begin to shine. The existing
Fish front end is already interactive, in fact, I did some
work to make it more suitable for _batch_ processing :-)
The syntax issue is _much_ harder: I do not know
the answer. What Fish does is as follows:
1a) Parse the Fish language, and ML like syntax with
Algol like semantics
2) Partially evaluate the resultant Abstract Syntax Tree,
reducing Fish language terms to a special sublanguage
called Turbot: this includes type and shape inference.
3) Translate the Turbot code into Fortran or C, compile it,
and execute it.
A large part of the work is done in the partial evaluator:
it does things like function inlining (beta reduction).
NumPy has various builtin operations which correspond
in a fairly obvious way to loops, folds, maps, and other
things which _could_ be written in Fish, so it seems possible
to translate it into Fish terms, and submit them to
partial evaluation: the hard bit is converting Python
functions applied to NumPy arrays, nor the actual array handling.
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller
From robin@jessikat.demon.co.uk Tue Jan 11 13:39:04 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Tue, 11 Jan 2000 13:39:04 +0000
Subject: [Matrix-SIG] Numerical python on SourceForge?
In-Reply-To: <387AEAD3.DFE43D41@maxtal.com.au>
References: <Pine.LNX.4.10.10001092248040.7721-100000@us2.mayo.edu>
<387AEAD3.DFE43D41@maxtal.com.au>
Message-ID: <ZHtXGDA4Jze4Ew6c@jessikat.demon.co.uk>
In article <387AEAD3.DFE43D41@maxtal.com.au>, skaller
<skaller@maxtal.com.au> writes
...
the idea of Python having to have a C/Fortran compiler sitting around to
work is a bit disturbing. Doesn't Fish/Turbot have an idealised machine
which could be built in C just once? If so python could compile/submit
code for it. NumPy is just about good enough for my problems.
Presumably a FishPy (?) extension could also be added.
--
Robin Becker
From hinsen@cnrs-orleans.fr Tue Jan 11 14:25:39 2000
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Tue, 11 Jan 2000 15:25:39 +0100
Subject: [Matrix-SIG] File corrected
In-Reply-To: <NDBBIEFMILBFPMDHJIMFCEKHCBAA.dubois1@llnl.gov>
References: <NDBBIEFMILBFPMDHJIMFCEKHCBAA.dubois1@llnl.gov>
Message-ID: <200001111425.PAA24139@chinon.cnrs-orleans.fr>
> I fixed the LLNLDistribution13.tgz at 9:35 a.m. PST
So which is now the most current NumPy version,
LLNLDistribution13.tgz or Numerical-14.tgz? Both have a date stamp
of Jan 10.
As for the ongoing discussion about distribution strategies and
inclusion of arrays in the Python distribution, I wonder if anyone
knows Guido's opinion about this. After all, we can discuss forever
what he should do, but in the end it doesn't matter...
Perhaps the main problem we need to discuss before anything can become
part of the Python disttribution is whether we are happy with NumPy
as it is, or at least with some subset. It seems that almost everyone
is unhappy about something, but we can't agree about what.
Upcasting: A while ago there was a lengthy discussion about this, and
there were some proposals that looked as if they could be acceptable
to everyone. Has anyone ever tried implementing them? It doesn't seem
worth continuing the discussion without some hands-on experience.
Rank 0 arrays: There are various philosophies as to whether rank-0
arrays should be the same as scalars or not. NumPy has followed the
APL tradition in which there is no difference, and I see no reason to
change this. So if NumPy arrays become part of Python, it would be
preferable to minimize any existing differences. This doesn't mean
that the implementation should be the same; the array overhead is
after all quite significant. But providing the basic array attributes
(shape, real, etc.) for Python scalars would be enough to remove the
distinction as seen by the Python programmer, and at the C extension
level the need for unification is much less obvious. Another annoying
difference, the different conventions for modulo calculations, should
be fixed in NumPy in my opinion. Perhaps one could add a
single-precision float scalar type to Python to increase compatibility
even further.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
From hinsen@cnrs-orleans.fr Tue Jan 11 14:27:38 2000
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Tue, 11 Jan 2000 15:27:38 +0100
Subject: [Matrix-SIG] thoughts about the future
In-Reply-To: <20000110211719.7911.qmail@lisboa.ifm.uni-kiel.de> (message from
Janko Hauser on Mon, 10 Jan 2000 22:17:18 +0100 (CET))
References: <14458.7958.737985.342132@nem-srvr.stsci.edu> <NDBBIEFMILBFPMDHJIMFAEKNCBAA.dubois1@llnl.gov> <20000110211719.7911.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <200001111427.PAA24143@chinon.cnrs-orleans.fr>
> Regarding ``range objects''. Partly we have already such things with
> the slice object. So you can write:
>
> var=ones((50,10,20))
> a=RangeObject[:30,0,:-10]
>
> var[a]
>
> It's written by Konrad Hinsen. I append the class which he calls
> ``indexing''. This needs to be extended if something like gathering is
This module is also part of ScientificPython, available at
http://starship.python.net/crew/hinsen/scientific.html
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
From pauldubois@home.com Tue Jan 11 18:04:06 2000
From: pauldubois@home.com (Paul F. Dubois)
Date: Tue, 11 Jan 2000 10:04:06 -0800
Subject: [Matrix-SIG] Pyfort-3.0
Message-ID: <NDBBIEFMILBFPMDHJIMFAELHCBAA.pauldubois@home.com>
Pyfort 3.0, the Python-Fortran connection tool, is available at
ftp://ftp-icf.llnl.gov/pub/python/Pyfort-3.0.tgz.
Documentation is included.
News:
Pyfort uses Distutils (www.python.org/sigs/distutils-sig) both to install
itself and to build and install extensions built with Pyfort.
There are many new features to control the behavior of the tool, including
provisions for optional automatic transposing, reversed-shape Fortran
arrays, and valued scalars.
A valued scalar is an integer argument to a Fortran routine that determines
all or part of the shape of another argument. This fact can now be declared
in the input. For example, if Fortran routine foo has arguments foo (n, x),
where x is a real array of length n, you have the option to declare this as:
subroutine foo (n, x)
integer n = size(x)
real x(n)
end
(size is the F90 intrinsic, and can take a second argument to indicate the
dimension if x has more than one)
Then the Python user would call foo as foo(x), and not need to specifiy the
redundant information that n is x's length.
Some persons do not want any of the features mentioned. They may rest
assured that declaring all arguments intent(inout) will result in what some
have called a "raw" interface.
REFERENCE:
<P><A HREF="http://dubois.simplenet.com/python">Pyfort 3.0</A> - Fortran /
Python Connection Tool. (11-Jan-2000)
From skaller@maxtal.com.au Tue Jan 11 20:04:42 2000
From: skaller@maxtal.com.au (skaller)
Date: Wed, 12 Jan 2000 07:04:42 +1100
Subject: [Matrix-SIG] Numerical python on SourceForge?
References: <Pine.LNX.4.10.10001092248040.7721-100000@us2.mayo.edu>
<387AEAD3.DFE43D41@maxtal.com.au> <ZHtXGDA4Jze4Ew6c@jessikat.demon.co.uk>
Message-ID: <387B8CDA.E8DEFD9@maxtal.com.au>
Robin Becker wrote:
> the idea of Python having to have a C/Fortran compiler sitting around to
> work is a bit disturbing.
Why? It is true it is an external tool, invoked by the shell,
which is very sloppy linkage. But then, Python hooks the file
system too, when importing modules. :-)
> Doesn't Fish/Turbot have an idealised machine
> which could be built in C just once?
Sure: the idealised machine is you native hardware.
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller
From Oliphant.Travis@mayo.edu Wed Jan 12 18:17:11 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Wed, 12 Jan 2000 12:17:11 -0600 (CST)
Subject: [Matrix-SIG] Altering NumPy in lieu of unifying Python scalars.
In-Reply-To: <Pine.LNX.4.10.10001112247430.2359-100000@us2.mayo.edu>
Message-ID: <Pine.LNX.4.10.10001121202200.3295-100000@us2.mayo.edu>
Guido and others interested,
Just a quick note to let you know that I started to implement a unified
scalar object and got far enough to convince myself that it was possible
to do without any real disruption, but then I started to realize that it
may only have asthetic value. My intent was to have a correspondence
between Python scalar types and NumPy array types, but this is a lot of
extra code to handle the rarely used single-precision-scalar cases. NumPy
rank-0 arrays currently do very well as single-precision-scalars --- they
just have quite a bit of overhead.
My colleague and I have decided instead to alter NumPy sufficiently to fix
our biggest woes. If Paul likes these changes then he is free to add them
to the main distribution. Otherwise, this is important enough to me and
others in the community that a minor fork is justified.
1) We will change the behavior so that rank-0 NumPy are only converted to
Python scalars with PyArray_Return if there is an exact correspondence in
the precision with the current Python scalars.
2) We will fill in the slots in the PyNumberMethods table for the
arrayobject corresponding to nb_int, nb_float, nb_long, nb_oct, and
nb_hex, so that rank-0 arrays can be converted to Python scalars using the
builtin functions int(), float(), long(), oct(), and hex() and at other
places within Python where it checks to see if the type knows how to be
an int.
We just wanted to let you and others know our plans in case somebody has
useful feedback or wants to offer their support.
Thanks,
Travis Oliphant
From Oliphant.Travis@mayo.edu Wed Jan 12 19:49:57 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Wed, 12 Jan 2000 13:49:57 -0600 (CST)
Subject: [Matrix-SIG] Patches for improved single precision handling in NumPy
Message-ID: <Pine.LNX.4.10.10001121345440.3782-200000@us2.mayo.edu>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---1463811840-820702757-947706597=:3782
Content-Type: TEXT/PLAIN; charset=US-ASCII
For anyone interested I'm attaching a patch against Numerical-14 which
changes NumPy to alleviate some of the difficulty with single precision
work. I implemented the changes I proposed previously plus altered
array_compare so that comparisons of rank-0 arrays work as expected.
I've tested the change and it appears to work nicely. With this change, I
can use single precision rank-0 arrays and not worry about operations with
them returning double precision scalars automatically. The rank-0 scalars
also act nicely in other contexts.
If anyone has comments or suggestions, I'd appreciate them.
Travis
---1463811840-820702757-947706597=:3782
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mypatch.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.10001121349570.3782@us2.mayo.edu>
Content-Description: Patch against Numerical-14 for single precision improvement
Content-Disposition: attachment; filename="mypatch.diff"
ZGlmZiAtY3IgTnVtZXJpY2FsLTE0Lm9yaWcvU3JjL2FycmF5b2JqZWN0LmMg
TnVtZXJpY2FsLTE0L1NyYy9hcnJheW9iamVjdC5jDQoqKiogTnVtZXJpY2Fs
LTE0Lm9yaWcvU3JjL2FycmF5b2JqZWN0LmMJTW9uIEphbiAxMCAxNjo0NTow
MyAyMDAwDQotLS0gTnVtZXJpY2FsLTE0L1NyYy9hcnJheW9iamVjdC5jCVdl
ZCBKYW4gMTIgMTM6NDI6NDEgMjAwMA0KKioqKioqKioqKioqKioqDQoqKiog
NDQ0LDQ1MSAqKioqDQogIAkJaWYgKG1wICE9IE5VTEwpIFB5X0RFQ1JFRiht
cCk7DQogIAkJcmV0dXJuIE5VTEw7DQogIAl9DQohIAlpZiAobXAtPm5kID09
IDApIHsNCiEgCQlvcCA9IGFycmF5X2l0ZW0obXAsIDApOw0KICAJCVB5X0RF
Q1JFRihtcCk7DQogIAkJcmV0dXJuIG9wOw0KICAJfSBlbHNlIHsNCi0tLSA0
NDQsNDUxIC0tLS0NCiAgCQlpZiAobXAgIT0gTlVMTCkgUHlfREVDUkVGKG1w
KTsNCiAgCQlyZXR1cm4gTlVMTDsNCiAgCX0NCiEgCWlmIChtcC0+bmQgPT0g
MCAmJiAobXAtPmRlc2NyLT50eXBlX251bSA9PSBQeUFycmF5X0xPTkcgfHwg
bXAtPmRlc2NyLT50eXBlX251bSA9PSBQeUFycmF5X0RPVUJMRSB8fCBtcC0+
ZGVzY3ItPnR5cGVfbnVtID09IFB5QXJyYXlfQ0RPVUJMRSkpIHsNCiEgICAg
ICAgIAkgICAgICAgIG9wID0gbXAtPmRlc2NyLT5nZXRpdGVtKG1wLT5kYXRh
KTsNCiAgCQlQeV9ERUNSRUYobXApOw0KICAJCXJldHVybiBvcDsNCiAgCX0g
ZWxzZSB7DQoqKioqKioqKioqKioqKioNCioqKiA5NzYsOTgxICoqKioNCi0t
LSA5NzYsMTA5MiAtLS0tDQogIH0NCiAgDQogIA0KKyAvKiBtZXRob2RzIGFk
ZGVkIGJ5IFRyYXZpcyBPbGlwaGFudCwgSmFuIDIwMDAgKi8NCisgc3RhdGlj
IFB5T2JqZWN0ICphcnJheV9pbnQoUHlBcnJheU9iamVjdCAqdikgeyAgICAg
ICAgDQorICAgICAgICAgUHlPYmplY3QgKnB2LCAqcHYyOw0KKyAgICAgICAg
IGlmICh2LT5uZCAhPSAwKSB7DQorIAkgICAgICAgIFB5RXJyX1NldFN0cmlu
ZyhQeUV4Y19UeXBlRXJyb3IsICJPbmx5IHJhbmstMCBhcnJheXMgY2FuIGJl
IGNvbnZlcnRlZCB0byBQeXRob24gc2NhbGFycy4iKTsNCisgCQlyZXR1cm4g
TlVMTDsNCisgCX0NCisgCXB2ID0gdi0+ZGVzY3ItPmdldGl0ZW0odi0+ZGF0
YSk7DQorIAlpZiAocHYgPT0gTlVMTCkgcmV0dXJuIE5VTEw7DQorIAlpZiAo
cHYtPm9iX3R5cGUtPnRwX2FzX251bWJlciA9PSAwKSB7DQorIAkgICAgICAg
IFB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3IsICJjYW5ub3QgY29u
dmVydCB0byBhbiBpbnQsIHNjYWxhciBvYmplY3QgaXMgbm90IGEgbnVtYmVy
LiIpOw0KKyAJCVB5X0RFQ1JFRihwdik7DQorICAgICAgICAgICAgICAgICBy
ZXR1cm4gTlVMTDsNCisgCX0NCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNf
bnVtYmVyLT5uYl9pbnQgPT0gMCkgew0KKyAJICAgICAgICBQeUVycl9TZXRT
dHJpbmcoUHlFeGNfVHlwZUVycm9yLCAiZG9uJ3Qga25vdyBob3cgdG8gY29u
dmVydCBzY2FsYXIgbnVtYmVyIHRvIGludCIpOw0KKyAJCVB5X0RFQ1JFRihw
dik7DQorICAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsNCisgCX0NCisg
DQorIAlwdjIgPSBwdi0+b2JfdHlwZS0+dHBfYXNfbnVtYmVyLT5uYl9pbnQo
cHYpOw0KKyAJUHlfREVDUkVGKHB2KTsNCisgCXJldHVybiBwdjI7ICAgICAg
ICANCisgfQ0KKyANCisgc3RhdGljIFB5T2JqZWN0ICphcnJheV9mbG9hdChQ
eUFycmF5T2JqZWN0ICp2KSB7ICAgICAgICANCisgICAgICAgICBQeU9iamVj
dCAqcHYsICpwdjI7DQorICAgICAgICAgaWYgKHYtPm5kICE9IDApIHsNCisg
CSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJvciwgIm9u
bHkgcmFuay0wIGFycmF5cyBjYW4gYmUgY29udmVydGVkIHRvIFB5dGhvbiBz
Y2FsYXJzLiIpOw0KKyAJCXJldHVybiBOVUxMOw0KKyAJfQ0KKyAJcHYgPSB2
LT5kZXNjci0+Z2V0aXRlbSh2LT5kYXRhKTsNCisgCWlmIChwdiA9PSBOVUxM
KSByZXR1cm4gTlVMTDsNCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNfbnVt
YmVyID09IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhj
X1R5cGVFcnJvciwgImNhbm5vdCBjb252ZXJ0IHRvIGFuIGludCwgc2NhbGFy
IG9iamVjdCBpcyBub3QgYSBudW1iZXIuIik7DQorIAkJUHlfREVDUkVGKHB2
KTsNCisgICAgICAgICAgICAgICAgIHJldHVybiBOVUxMOw0KKyAJfQ0KKyAJ
aWYgKHB2LT5vYl90eXBlLT50cF9hc19udW1iZXItPm5iX2Zsb2F0ID09IDAp
IHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJv
ciwgImRvbid0IGtub3cgaG93IHRvIGNvbnZlcnQgc2NhbGFyIG51bWJlciB0
byBmbG9hdCIpOw0KKyAJCVB5X0RFQ1JFRihwdik7DQorICAgICAgICAgICAg
ICAgICByZXR1cm4gTlVMTDsNCisgCX0NCisgCXB2MiA9IHB2LT5vYl90eXBl
LT50cF9hc19udW1iZXItPm5iX2Zsb2F0KHB2KTsNCisgCVB5X0RFQ1JFRihw
dik7DQorIAlyZXR1cm4gcHYyOyAgICAgICAgDQorIH0NCisgDQorIHN0YXRp
YyBQeU9iamVjdCAqYXJyYXlfbG9uZyhQeUFycmF5T2JqZWN0ICp2KSB7ICAg
ICAgICANCisgICAgICAgICBQeU9iamVjdCAqcHYsICpwdjI7DQorICAgICAg
ICAgaWYgKHYtPm5kICE9IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3Ry
aW5nKFB5RXhjX1R5cGVFcnJvciwgIm9ubHkgcmFuay0wIGFycmF5cyBjYW4g
YmUgY29udmVydGVkIHRvIFB5dGhvbiBzY2FsYXJzLiIpOw0KKyAJCXJldHVy
biBOVUxMOw0KKyAJfQ0KKyAJcHYgPSB2LT5kZXNjci0+Z2V0aXRlbSh2LT5k
YXRhKTsNCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNfbnVtYmVyID09IDAp
IHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJv
ciwgImNhbm5vdCBjb252ZXJ0IHRvIGFuIGludCwgc2NhbGFyIG9iamVjdCBp
cyBub3QgYSBudW1iZXIuIik7DQorICAgICAgICAgICAgICAgICByZXR1cm4g
TlVMTDsNCisgCX0NCisgCWlmIChwdi0+b2JfdHlwZS0+dHBfYXNfbnVtYmVy
LT5uYl9sb25nID09IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5n
KFB5RXhjX1R5cGVFcnJvciwgImRvbid0IGtub3cgaG93IHRvIGNvbnZlcnQg
c2NhbGFyIG51bWJlciB0byBsb25nIik7DQorICAgICAgICAgICAgICAgICBy
ZXR1cm4gTlVMTDsNCisgCX0NCisgCXB2MiA9IHB2LT5vYl90eXBlLT50cF9h
c19udW1iZXItPm5iX2xvbmcocHYpOw0KKyAJUHlfREVDUkVGKHB2KTsNCisg
CXJldHVybiBwdjI7ICAgICAgICANCisgfQ0KKyANCisgc3RhdGljIFB5T2Jq
ZWN0ICphcnJheV9vY3QoUHlBcnJheU9iamVjdCAqdikgeyAgICAgICAgDQor
ICAgICAgICAgUHlPYmplY3QgKnB2LCAqcHYyOw0KKyAgICAgICAgIGlmICh2
LT5uZCAhPSAwKSB7DQorIAkgICAgICAgIFB5RXJyX1NldFN0cmluZyhQeUV4
Y19UeXBlRXJyb3IsICJvbmx5IHJhbmstMCBhcnJheXMgY2FuIGJlIGNvbnZl
cnRlZCB0byBQeXRob24gc2NhbGFycy4iKTsNCisgCQlyZXR1cm4gTlVMTDsN
CisgCX0NCisgCXB2ID0gdi0+ZGVzY3ItPmdldGl0ZW0odi0+ZGF0YSk7DQor
IAlpZiAocHYtPm9iX3R5cGUtPnRwX2FzX251bWJlciA9PSAwKSB7DQorIAkg
ICAgICAgIFB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3IsICJjYW5u
b3QgY29udmVydCB0byBhbiBpbnQsIHNjYWxhciBvYmplY3QgaXMgbm90IGEg
bnVtYmVyLiIpOw0KKyAgICAgICAgICAgICAgICAgcmV0dXJuIE5VTEw7DQor
IAl9DQorIAlpZiAocHYtPm9iX3R5cGUtPnRwX2FzX251bWJlci0+bmJfb2N0
ID09IDApIHsNCisgCSAgICAgICAgUHlFcnJfU2V0U3RyaW5nKFB5RXhjX1R5
cGVFcnJvciwgImRvbid0IGtub3cgaG93IHRvIGNvbnZlcnQgc2NhbGFyIG51
bWJlciB0byBvY3QiKTsNCisgICAgICAgICAgICAgICAgIHJldHVybiBOVUxM
Ow0KKyAJfQ0KKyAJcHYyID0gcHYtPm9iX3R5cGUtPnRwX2FzX251bWJlci0+
bmJfb2N0KHB2KTsNCisgCVB5X0RFQ1JFRihwdik7DQorIAlyZXR1cm4gcHYy
OyAgICAgICAgDQorIH0NCisgDQorIHN0YXRpYyBQeU9iamVjdCAqYXJyYXlf
aGV4KFB5QXJyYXlPYmplY3QgKnYpIHsgICAgICAgIA0KKyAgICAgICAgIFB5
T2JqZWN0ICpwdiwgKnB2MjsNCisgICAgICAgICBpZiAodi0+bmQgIT0gMCkg
ew0KKyAJICAgICAgICBQeUVycl9TZXRTdHJpbmcoUHlFeGNfVHlwZUVycm9y
LCAib25seSByYW5rLTAgYXJyYXlzIGNhbiBiZSBjb252ZXJ0ZWQgdG8gUHl0
aG9uIHNjYWxhcnMuIik7DQorIAkJcmV0dXJuIE5VTEw7DQorIAl9DQorIAlw
diA9IHYtPmRlc2NyLT5nZXRpdGVtKHYtPmRhdGEpOw0KKyAJaWYgKHB2LT5v
Yl90eXBlLT50cF9hc19udW1iZXIgPT0gMCkgew0KKyAJICAgICAgICBQeUVy
cl9TZXRTdHJpbmcoUHlFeGNfVHlwZUVycm9yLCAiY2Fubm90IGNvbnZlcnQg
dG8gYW4gaW50LCBzY2FsYXIgb2JqZWN0IGlzIG5vdCBhIG51bWJlci4iKTsN
CisgICAgICAgICAgICAgICAgIHJldHVybiBOVUxMOw0KKyAJfQ0KKyAJaWYg
KHB2LT5vYl90eXBlLT50cF9hc19udW1iZXItPm5iX2hleCA9PSAwKSB7DQor
IAkgICAgICAgIFB5RXJyX1NldFN0cmluZyhQeUV4Y19UeXBlRXJyb3IsICJk
b24ndCBrbm93IGhvdyB0byBjb252ZXJ0IHNjYWxhciBudW1iZXIgdG8gaGV4
Iik7DQorICAgICAgICAgICAgICAgICByZXR1cm4gTlVMTDsNCisgCX0NCisg
CXB2MiA9IHB2LT5vYl90eXBlLT50cF9hc19udW1iZXItPm5iX2hleChwdik7
DQorIAlQeV9ERUNSRUYocHYpOw0KKyAJcmV0dXJuIHB2MjsgICAgICAgIA0K
KyB9DQorIA0KKyAvKiBlbmQgb2YgbWV0aG9kcyBhZGRlZCBieSBUcmF2aXMg
T2xpcGhhbnQgKi8NCisgDQorIA0KICBzdGF0aWMgUHlOdW1iZXJNZXRob2Rz
IGFycmF5X2FzX251bWJlciA9IHsNCiAgCShiaW5hcnlmdW5jKWFycmF5X2Fk
ZCwgLypuYl9hZGQqLw0KICAJKGJpbmFyeWZ1bmMpYXJyYXlfc3VidHJhY3Qs
IC8qbmJfc3VidHJhY3QqLw0KKioqKioqKioqKioqKioqDQoqKiogOTk1LDEw
MDUgKioqKg0KICAJKGJpbmFyeWZ1bmMpYXJyYXlfYml0d2lzZV94b3IsCQkv
Km5iX3hvciovDQogIAkoYmluYXJ5ZnVuYylhcnJheV9iaXR3aXNlX29yLAkJ
LypuYl9vciovDQogIAkoY29lcmNpb24pYXJyYXlfY29lcmNlLCAvKm5iX2Nv
ZXJjZSovDQohIAkwLCAvKm5iX2ludCovDQohIAkwLCAvKm5iX2xvbmcqLw0K
ISAJMCwgLypuYl9mbG9hdCovDQohIAkwLAkJLypuYl9vY3QqLw0KISAJMCwJ
CS8qbmJfaGV4Ki8NCiAgfTsNCiAgDQogIHN0YXRpYyBQeVNlcXVlbmNlTWV0
aG9kcyBhcnJheV9hc19zZXF1ZW5jZSA9IHsNCi0tLSAxMTA2LDExMTYgLS0t
LQ0KICAJKGJpbmFyeWZ1bmMpYXJyYXlfYml0d2lzZV94b3IsCQkvKm5iX3hv
ciovDQogIAkoYmluYXJ5ZnVuYylhcnJheV9iaXR3aXNlX29yLAkJLypuYl9v
ciovDQogIAkoY29lcmNpb24pYXJyYXlfY29lcmNlLCAvKm5iX2NvZXJjZSov
DQohIAkodW5hcnlmdW5jKWFycmF5X2ludCwgLypuYl9pbnQqLw0KISAJKHVu
YXJ5ZnVuYylhcnJheV9sb25nLCAvKm5iX2xvbmcqLw0KISAJKHVuYXJ5ZnVu
YylhcnJheV9mbG9hdCwgLypuYl9mbG9hdCovDQohIAkodW5hcnlmdW5jKWFy
cmF5X29jdCwJLypuYl9vY3QqLw0KISAJKHVuYXJ5ZnVuYylhcnJheV9oZXgs
CS8qbmJfaGV4Ki8NCiAgfTsNCiAgDQogIHN0YXRpYyBQeVNlcXVlbmNlTWV0
aG9kcyBhcnJheV9hc19zZXF1ZW5jZSA9IHsNCioqKioqKioqKioqKioqKg0K
KioqIDEzMTgsMTMyNyAqKioqDQogIAlyZXR1cm4gUHlBcnJheV9Db3B5KHNl
bGYpOw0KICB9DQogIA0KICBpbnQgYXJyYXlfY29tcGFyZShQeUFycmF5T2Jq
ZWN0ICpzZWxmLCBQeU9iamVjdCAqb3RoZXIpIHsNCiEgCVB5RXJyX1NldFN0
cmluZyhQeUV4Y19UeXBlRXJyb3IsDQohIAkJIkNvbXBhcmlzb24gb2YgbXVs
dGlhcnJheSBvYmplY3RzIGlzIG5vdCBpbXBsZW1lbnRlZC4iKTsNCiEgCXJl
dHVybiAtMTsNCiAgfQ0KICANCiAgDQotLS0gMTQyOSwxNDU3IC0tLS0NCiAg
CXJldHVybiBQeUFycmF5X0NvcHkoc2VsZik7DQogIH0NCiAgDQorIA0KKyAv
KiBDaGFuZ2VkIGJ5IFRyYXZpcyBPbGlwaGFudCBKYW4sIDIwMDAgKi8NCiAg
aW50IGFycmF5X2NvbXBhcmUoUHlBcnJheU9iamVjdCAqc2VsZiwgUHlPYmpl
Y3QgKm90aGVyKSB7DQohICAgICAgICAgUHlBcnJheU9iamVjdCAqYW90aGVy
Ow0KISAgICAgICAgIFB5T2JqZWN0ICpvMSwgKm8yOw0KISAgICAgICAgIGlu
dCB2YWwsIHJlc3VsdDsNCiEgICAgICAgICBhb3RoZXIgPSAoUHlBcnJheU9i
amVjdCAqKW90aGVyOw0KISAgICAgICAgIGlmIChzZWxmLT5uZCAhPSAwIHx8
IGFvdGhlci0+bmQgIT0gMCkgew0KISAJICAgICAgICBQeUVycl9TZXRTdHJp
bmcoUHlFeGNfVHlwZUVycm9yLA0KISAJCSAiQ29tcGFyaXNvbiBvZiBtdWx0
aWFycmF5IG9iamVjdHMgb3RoZXIgdGhhbiByYW5rLTAgYXJyYXlzIGlzIG5v
dCBpbXBsZW1lbnRlZC4iKTsNCiEgCSAgICAgICAgcmV0dXJuIC0xOw0KISAJ
fQ0KISAgICAgICAgIG8xID0gc2VsZi0+ZGVzY3ItPmdldGl0ZW0oc2VsZi0+
ZGF0YSk7DQohIAlvMiA9IGFvdGhlci0+ZGVzY3ItPmdldGl0ZW0oYW90aGVy
LT5kYXRhKTsNCiEgCWlmIChvMSA9PSBOVUxMIHx8IG8yID09IE5VTEwpIHJl
dHVybiAtMTsNCiEgICAgICAgICB2YWwgPSBQeU9iamVjdF9DbXAobzEsbzIs
JnJlc3VsdCk7DQohIAlQeV9ERUNSRUYobzEpOw0KISAgICAgICAgIFB5X0RF
Q1JFRihvMik7DQohICAgICAgICAgaWYgKHZhbCA8IDApIHsNCiEgCSAgUHlF
cnJfU2V0U3RyaW5nKFB5RXhjX1R5cGVFcnJvciwgIm9iamVjdHMgY2Fubm90
IGJlIGNvbXBhcmVkLiIpOw0KISAgICAgICAgICAgcmV0dXJuIC0xOw0KISAJ
fQ0KISAJcmV0dXJuIHJlc3VsdDsNCiAgfQ0KICANCg==
---1463811840-820702757-947706597=:3782--
From Oliphant.Travis@mayo.edu Thu Jan 13 01:55:17 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Wed, 12 Jan 2000 19:55:17 -0600 (CST)
Subject: [Matrix-SIG] New i386 and SRC RPM's for Numerical Python Version 14
Message-ID: <Pine.LNX.4.10.10001121952220.5694-100000@us2.mayo.edu>
This is just a quick note to announce the availability of RPM's for
Numerical Python Version 14 at http://oliphant.netpedia.net
In this release Gist and RNG have been separated out.
I have applied some patches to the LLNL Version 14 Release which alleviate
some of the single-precision difficulties and fix a segmentation fault
bug. The patch is also available here:
http://oliphant.netpedia.net/packages/Numerical-14.patch
--Travis
From hoel@germanlloyd.org Thu Jan 13 14:54:16 2000
From: hoel@germanlloyd.org (Berthold Hoellmann)
Date: Thu, 13 Jan 2000 15:54:16 +0100
Subject: [Matrix-SIG] pyfort for Windows NT?
Message-ID: <387DE718.C15117C6@GermanLloyd.org>
Hello,
Has anyone made the neccessary changes to use pyfort under Windows NT?
Cheers
Berthold
--
email: hoel@GermanLloyd.org
)
(
C[_] These opinions might be mine, but never those of my employer.
From hoel@germanlloyd.org Thu Jan 13 14:57:43 2000
From: hoel@germanlloyd.org (Berthold Hoellmann)
Date: Thu, 13 Jan 2000 15:57:43 +0100
Subject: [Matrix-SIG] small pyfort fix
Message-ID: <387DE7E7.639AE4E7@GermanLloyd.org>
Hello,
There are really C compiler that reject newlines in string constants
(which is correct IMHO). I changed the function "fixup" in
"generator.py" of Pyfort3 to overcome problems resulting from this when
Pyfort is generating doc strings:
def fixup (acomment):
"Fix the comment so it can be a C string literal."
out = string.replace (acomment, '"', r'\"')
out = string.join(string.split(out, "\n"), "\\n\\\n")
return out
Cheers
Berthold
(I accidentially send this to matrix-sig-admin@python.org before)
--
email: hoel@GermanLloyd.org
)
(
C[_] These opinions might be mine, but never those of my employer.
From cgw@fnal.gov Thu Jan 13 22:34:00 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Thu, 13 Jan 2000 16:34:00 -0600 (CST)
Subject: [Matrix-SIG] Numeric.__version__
Message-ID: <14462.21208.709591.811265@buffalo.fnal.gov>
I just downloaded and installed the recently-announced
Numerical-14.tgz and find that Numeric.__version__ and
Numeric.__LLNLDistribution__ both say "11".
From dubois1@llnl.gov Thu Jan 13 23:21:22 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 13 Jan 2000 15:21:22 -0800
Subject: [Matrix-SIG] Numeric.__version__
In-Reply-To: <14462.21208.709591.811265@buffalo.fnal.gov>
Message-ID: <NDBBIEFMILBFPMDHJIMFKEMPCBAA.dubois1@llnl.gov>
Proves the folly of this sort of thing. Thanks for reporting it.
-----Original Message-----
From: matrix-sig-admin@python.org [mailto:matrix-sig-admin@python.org]On
Behalf Of Charles G Waldman
Sent: Thursday, January 13, 2000 2:34 PM
To: matrix-sig@python.org
Subject: [Matrix-SIG] Numeric.__version__
I just downloaded and installed the recently-announced
Numerical-14.tgz and find that Numeric.__version__ and
Numeric.__LLNLDistribution__ both say "11".
_______________________________________________
Matrix-SIG maillist - Matrix-SIG@python.org
http://www.python.org/mailman/listinfo/matrix-sig
From da@ski.org Thu Jan 13 23:34:06 2000
From: da@ski.org (David Ascher)
Date: Thu, 13 Jan 2000 15:34:06 -0800
Subject: [Matrix-SIG] Numeric.__version__
In-Reply-To: <NDBBIEFMILBFPMDHJIMFKEMPCBAA.dubois1@llnl.gov>
Message-ID: <000401bf5e1e$aed22260$c355cfc0@ski.org>
> Proves the folly of this sort of thing. Thanks for reporting it.
Any suggestion for how to help people identify the version? I'm not
defending the wisdom of having it in a runtime file, but I think folks like
to be able to find out from a binary installation what version they're
using.
--da
From pauldubois@home.com Fri Jan 14 05:26:01 2000
From: pauldubois@home.com (Paul F. Dubois)
Date: Thu, 13 Jan 2000 21:26:01 -0800
Subject: [Matrix-SIG] We gotta web site.
Message-ID: <NDBBIEFMILBFPMDHJIMFIENCCBAA.pauldubois@home.com>
Web site up with required logo.
http://numpy.sourceforge.net
From skaller@maxtal.com.au Fri Jan 14 14:48:38 2000
From: skaller@maxtal.com.au (skaller)
Date: Sat, 15 Jan 2000 01:48:38 +1100
Subject: [Matrix-SIG] Numeric.__version__
References: <000401bf5e1e$aed22260$c355cfc0@ski.org>
Message-ID: <387F3746.1FD543FC@maxtal.com.au>
David Ascher wrote:
>
> > Proves the folly of this sort of thing. Thanks for reporting it.
>
> Any suggestion for how to help people identify the version? I'm not
> defending the wisdom of having it in a runtime file, but I think folks like
> to be able to find out from a binary installation what version they're
> using.
Sure: My suggestion is that this question be referred to the experts
in the field: Dist-SIG.
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
homepage: http://www.maxtal.com.au/~skaller
download: ftp://ftp.cs.usyd.edu/au/jskaller
From jhauser@ifm.uni-kiel.de Fri Jan 14 19:25:05 2000
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Fri, 14 Jan 2000 20:25:05 +0100 (CET)
Subject: [Matrix-SIG] Anonymous co working?
Message-ID: <20000114192505.18703.qmail@lisboa.ifm.uni-kiel.de>
Is the anonymous checkout at sourceforge already working? Then I noted
that there is a probably obsolete module numpy in the repository.
__Janko
From dubois1@llnl.gov Fri Jan 14 19:28:12 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Fri, 14 Jan 2000 11:28:12 -0800
Subject: [Matrix-SIG] Anonymous co working?
In-Reply-To: <20000114192505.18703.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <NDBBIEFMILBFPMDHJIMFCENICBAA.dubois1@llnl.gov>
Should be working. The numpy tree is empty. It was the result of a first
attempt at following confusing directions. One I saw what it did I was able
to do it right, but I am unclear how to blow numpy away. When I have control
of the repository locally I just go remove the directory but I don't have
that capability on SF. If anybody knows how, give a holler, please.
It would be nice if I just RTFM but there are a lot of M's. I last used CVS
about four years ago and I'm rusty.
-----Original Message-----
From: matrix-sig-admin@python.org [mailto:matrix-sig-admin@python.org]On
Behalf Of Janko Hauser
Sent: Friday, January 14, 2000 11:25 AM
To: Matrix-Sig
Subject: [Matrix-SIG] Anonymous co working?
Is the anonymous checkout at sourceforge already working? Then I noted
that there is a probably obsolete module numpy in the repository.
__Janko
_______________________________________________
Matrix-SIG maillist - Matrix-SIG@python.org
http://www.python.org/mailman/listinfo/matrix-sig
From acornet@emory.edu Sun Jan 16 00:30:17 2000
From: acornet@emory.edu (Ben Cornett)
Date: Sat, 15 Jan 2000 16:30:17 -0800
Subject: [Matrix-SIG] Irix 6.5 build problems
Message-ID: <38811119.86C5E023@emory.edu>
Hello,
I am trying to build Numeric on an SGI Octane running Irix 6.5.6m. I run
'python setup.py build install' as instructed in the 'README' and
everthing appears to compile without problems. However, when I try to
import Numeric I get a core dump. I would greatly appreciate any
suggestions anyone can give me.
Thanks,
Best,
Ben
From acornet@emory.edu Sun Jan 16 02:09:43 2000
From: acornet@emory.edu (Ben Cornett)
Date: Sat, 15 Jan 2000 18:09:43 -0800
Subject: [Matrix-SIG] Irix 6.5 build problems
References: <D3D015A6FA03D31189D70008C7247D426BFB83@pnlmse15.pnl.gov>
Message-ID: <38812867.A7ECE4AF@emory.edu>
That did it.
Many thanks, that would have taken me a good while to figure out on my
own.
Ben
"Harrison, Robert J" wrote:
>
> Run python under the debugger and see where the
> failure happens. If it is code to do with setting up complex
> arithmetic, try compiling complexobject.c in the Python tree
> without any optimization. This fixed the import problem for me.
>
> It's on the Python platform bugs list.
>
> Robert
>
> -----Original Message-----
> From: Ben Cornett [mailto:acornet@emory.edu]
> Sent: Saturday, January 15, 2000 4:30 PM
> To: matrix-sig@python.org
> Subject: [Matrix-SIG] Irix 6.5 build problems
>
> Hello,
>
> I am trying to build Numeric on an SGI Octane running Irix 6.5.6m. I run
> 'python setup.py build install' as instructed in the 'README' and
> everthing appears to compile without problems. However, when I try to
> import Numeric I get a core dump. I would greatly appreciate any
> suggestions anyone can give me.
> Thanks,
>
> Best,
>
> Ben
>
> _______________________________________________
> Matrix-SIG maillist - Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
From Oliphant.Travis@mayo.edu Sun Jan 16 05:56:57 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sat, 15 Jan 2000 23:56:57 -0600 (CST)
Subject: [Matrix-SIG] Proposal for further single-precision clean-up.
Message-ID: <Pine.LNX.4.10.10001152326340.11698-100000@us2.mayo.edu>
Recently I submitted patches that in my view alleviate some of the
difficulties encountered when working with single precision arrays. I am
now submitting a proposal for immediate changes that could be made to
Numerical Python to further improve single precision work. For the
future I am in support of modifying Python so that scalars are the same as
rank-0 arrays, but any move in that direction is certainly several months
or even years away.
Instead of waiting for something to happen, we should establish a
consistent usage that allows single-precision work in Numerical Python to
proceed. The problem has always been that Python does not define
single-precision scalars. I suggest, that as far as NumPy is concerned, we
define single-precision scalars to be the corresponding rank-0 array.
This is the direction I was going with the recent patches to NumPy. I'm
now proposing that we finish the job so that for any operation on a
single-precision array that returns a scalar for which no Python scalar of
equivalent precision exists, NumPy returns a rank-0 array.
Some have expressed concerns that rank-0 arrays won't behave correctly as
scalars and will therefore be useless as return values. Because of
Python's abstract object interface, rank-0 arrays can be defined to act
like Python scalars in nearly every way (the only exception I can think of
right now is list indexing -- and that could be fixed in Python).
Some have also objected that rank-0 arrays are not scalars so that
equating them will cause confusion. I can respect those concerns but feel
that in the current state of Numerical Python the association between
rank-0 arrays and scalars is valid and useful.
At its core, my proposal requires changes to the getitem function of
single-precision types in arraytypes.c and then a careful checking to make
sure that everytime that function is used, the following code accepts the
philosophy that the returned objects are either rank-0 arrays or Python
scalars of the corresponding precision.
In my mind, this fix is not ideal, but I think it will help
single-precision users and establish a practical consistency for the time
being.
I can fix the code and patch the source tree after receiving approval from
Paul who will listen to the responses on this list. So, if you can think
of example code that such a change would break, or if you agree with
these changes please post to the list.
Thanks,
Travis
From Oliphant.Travis@mayo.edu Sun Jan 16 06:48:29 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sun, 16 Jan 2000 00:48:29 -0600 (CST)
Subject: [Matrix-SIG] Proposal: Move array_map and array_set into NumPy core
Message-ID: <Pine.LNX.4.10.10001160040430.11815-100000@us2.mayo.edu>
There are several useful utilities that would work nicely in the NumPy
core. The first is the array_set function from gist, which allows setting
elements of an array using the index. The second is an array_map method
which I recently wrote and placed in SpecialFunctions (cepes) that allows
"vectorizing" an arbitrary Python function -- i.e. it is a map that
implements the universal function broadcasting rules.
Comments?
Travis
From ransom@cfa.harvard.edu Sun Jan 16 15:44:27 2000
From: ransom@cfa.harvard.edu (Scott M. Ransom)
Date: Sun, 16 Jan 2000 15:44:27 +0000
Subject: [Matrix-SIG] Proposal for further single-precision clean-up.
References: <Pine.LNX.4.10.10001152326340.11698-100000@us2.mayo.edu>
Message-ID: <3881E75B.B4380AFF@cfa.harvard.edu>
Travis Oliphant wrote:
> Instead of waiting for something to happen, we should establish a
> consistent usage that allows single-precision work in Numerical Python to
> proceed. The problem has always been that Python does not define
> single-precision scalars. I suggest, that as far as NumPy is concerned, we
> define single-precision scalars to be the corresponding rank-0 array.
As an astronomer, I would love to increase my use of NumPy -- but have
proceded very slowly due to the "single precision" problems. I often
need to access _huge_ arrays of single precision floats (generated by
Fortran or C code), and the upcasting to double is a killer for my
appliations.
Since I am not terribly familiar with the NumPy code base (and I'm sure
that many on this list aren't either), I would like to request that
someone more knowlegable please post a summary of the pros and cons for
treating single precision scalars as rank-0 arrays (or as something
different -- i.e. a new Python intrinsic).
I am really interested to learn what the differences in functionality
and performance would be when using the various different
implementations on NumPy arrays -- using ufuncs, the Python math module,
matrix operations, casting, etc.
I am highly encouraged by the recent interest in moving NumPy forward,
and with the correct changes, I think the user base among Scientists
will increase dramatically.
Thanks in advance,
Scott
--
Scott M. Ransom
Phone: (781) 320-9867 Address: 75 Sanderson Ave.
email: ransom@cfa.harvard.edu Dedham, MA 02026
PGP Fingerprint: D2 0E D0 10 CD 95 06 DA EF 78 FE 2B CB 3A D3 53
From Oliphant.Travis@mayo.edu Sun Jan 16 16:21:41 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Sun, 16 Jan 2000 10:21:41 -0600 (CST)
Subject: [Matrix-SIG] Proposal for further single-precision clean-up.
In-Reply-To: <3881E75B.B4380AFF@cfa.harvard.edu>
Message-ID: <Pine.LNX.4.10.10001160953080.13825-100000@us2.mayo.edu>
>
> As an astronomer, I would love to increase my use of NumPy -- but have
> proceded very slowly due to the "single precision" problems. I often
> need to access _huge_ arrays of single precision floats (generated by
> Fortran or C code), and the upcasting to double is a killer for my
> appliations.
It would benefit me if you could post an explanation and/or examples of
what you think the "single precision" problem is. I have been thinking of
ways to improve the situation according to the difficulties, I've
encountered in my own work, but it would be beneficial if others posted
example code.
With the latest changes to NumPy (Release 15.X) one can define single
precision scalars as NumPy arrays of rank-0 and they will not be converted
behind the scenes to double-precision Python scalars, somewhere along the
line causing an upcast.
The one problem remaining that I see (let me know if you see others), is
that retrieving an element from a single precision array still returns
a double-precision Python scalar. This would still cause upcasting. I
think this could be fixed and is what I proposed to do in my previous
post.
Another idea I've tossed around with a colleague is to introduce the
concept of passive casting. The idea is to introduce another flag that
allows the user to specify that an array is passive in it's casting
requirements. So, if a passive-casting array operates with an
active-casting array, the active-casting array always determines the type.
If two passive-casting arrays operate on each other, the normal rules
apply and a passive-casting array is returned. The other piece that would
make this useful is to make all Python scalars automatically
passive-casting (since their precision cannot be specified).
>
> Since I am not terribly familiar with the NumPy code base (and I'm sure
> that many on this list aren't either), I would like to request that
> someone more knowlegable please post a summary of the pros and cons for
> treating single precision scalars as rank-0 arrays (or as something
> different -- i.e. a new Python intrinsic).
Python allows you to define new types that behave in nearly all respects
just like Python scalars. Much of C-code in Python is written so that if
the C-routine expects say a Python integer it checks to see if the object
is an integer and if not it checks to see if the object can act like an
integer (i.e. it returns a Python Integer if you say in Python
int(object)). There are a few places in the code where this is not
followed and the code must have a Python integer (list indexing is an
example --- I don't know why this couldn't be changed, however). Because
Python does not itself define the concept of single-precision scalars, we
can and should decide on a Numerical Python definition of them.
Right now rank-0 arrays fit as a definition for single-precision scalars
very well and with a few changes could be a consisten view throughout the
current code. There is significant, unnecessary overhead for rank-0
arrays, however, that could be a practical argument for a separate scalar
type that supports the concept of single-precision. This would probably
also make some folks happy to separate the concepts of scalars and rank-0
arrays. Such a type could later become a unifying concept for all of
Python's scalars (it would necessarily have more overhead than curent
implementation of Integers though which may make it hard for Guido to buy
into)
But, defining a new type would mean more code---very easy to write
code---but time consuming. This code would also increase the size of
Numerical Python. I don't mind that but I'm not sure of others' opinions
>
> I am really interested to learn what the differences in functionality
> and performance would be when using the various different
> implementations on NumPy arrays -- using ufuncs, the Python math module,
> matrix operations, casting, etc.
Currently, all Python scalars are converted to rank-0 arrays before any
operations are done in NumPy, so there are no real performance issues.
The Python math module only works with Python scalars so you would have to
convert any single-precision array to a Python scalar (using int(),
float(), etc.) before using one of those). Of course the Python math
module is faster for a scalar than ufuncs are for a scalar computation
(there is more overhead for the ufunc).
> I am highly encouraged by the recent interest in moving NumPy forward,
> and with the correct changes, I think the user base among Scientists
> will increase dramatically.
I'm glad to hear that. I would like to see the user base increase, too.
Travis
From pearu@ioc.ee Sun Jan 16 16:48:22 2000
From: pearu@ioc.ee (Pearu Peterson)
Date: Sun, 16 Jan 2000 18:48:22 +0200 (EET)
Subject: [Matrix-SIG] Release 14
In-Reply-To: <NDBBIEFMILBFPMDHJIMFKEKNCBAA.pauldubois@home.com>
Message-ID: <Pine.HPX.4.05.10001161842001.2095-100000@egoist.ioc.ee>
I just installed Numerical-14 and I noticed that the new installation
procedure does not install arrayobject.h and other header files.
I copied them by hand to the required place but shouldn't it be done by
setup.py?
Pearu
On Mon, 10 Jan 2000, Paul F. Dubois wrote:
> ftp-icf.llnl.gov/pub/python/Numerical-14.tgz is available for download.
>
> This version is identical to 13 except that the installation procedure is
> changed to use Distutils.
> Thanks to the Distutils gang for the already-working setup.py file.
>
> No more versions are planned for today. (:->.
>
> Paul
>
>
> _______________________________________________
> Matrix-SIG maillist - Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
>
From pauldubois@home.com Sun Jan 16 20:43:53 2000
From: pauldubois@home.com (Paul F. Dubois)
Date: Sun, 16 Jan 2000 12:43:53 -0800
Subject: [Matrix-SIG] Numerical Python Project
Message-ID: <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>
The Numerical Python Project is in the process of establishing itself at
SourceForge, http://numpy.sourceforge.net.
To register as a user of SourceForge go to http://sourceforge.net.
Use the Numerical Python webpage above to get to the Numerical Python
Project page at SourceForge. On that page you will find links to current
releases, the CVS repository, bug tracking facility, etc. We are just
getting up and running but you can check out the sources using anonymous CVS
by following directions given in the CVS link. (Note: unlike FTP, the
anonymous password required is blank -- just use the Enter key. They say
this but up above the lines that catch your eye).
The project developers are David Ascher, Travis Oliphant, and myself. Once
we are settled in we will entertain requests to become codevelopers.
However, for now we would like to keep it simple.
The remainder of the LLNL-distributed packages will be relocated as well
during the next two months. The current web server, xfiles.llnl.gov, is both
unstable and about to disappear behind a firewall. The ftp site
ftp-icf.llnl.gov will be redirected to a new machine at that time. The
situation now is: Numerical only is located at SourceForge; other packages
haven't been updated and so the LLNLDistribution11.tgz file is the "latest"
for those.
Due to the new firewall plans, it is better not to try to distribute this
software from LLNL itself, and by some miracle SourceForge has appeared in
the nick of time and offers us a truly superior location. This switch does
not represent any diminution of LLNL's participation or interest in the
Python scene.
Parties willing to make and install binary releases for Windows and Mac will
be needed. For the moment, only source is available at the SourceForge site.
From robin@jessikat.demon.co.uk Mon Jan 17 10:52:06 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Mon, 17 Jan 2000 10:52:06 +0000
Subject: [Matrix-SIG] Numerical Python Project
In-Reply-To: <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>
References: <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>
Message-ID: <R6ypTFAWRvg4EwIO@jessikat.demon.co.uk>
In article <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>, Paul F. Dubois
<pauldubois@home.com> writes
>The Numerical Python Project is in the process of establishing itself at
>SourceForge, http://numpy.sourceforge.net.
>
>To register as a user of SourceForge go to http://sourceforge.net.
>
>Use the Numerical Python webpage above to get to the Numerical Python
>Project page at SourceForge. On that page you will find links to current
...
I'm trying to build 15 with win32 vc++ 6.0 distutils 0.1.2 I get the following output which is
messed up by my lack of a proper shell. The upshot is that it fails to find libpython15.lib
which is obviously a unixism since I do have python15.lib in my libs area. Is this a Numerical
setup error or is it in distutils?
(Numerical-15.1) 1 % python setup.py build
_numpymodule.c
arrayobject.c
ufuncobject.c
LINK : fatal error LNK1181: cannot open input file "libpython15.lib"
running build
running build_py
creating build
creating build\lib
copying Lib\ArrayPrinter.py -> build\lib
copying Lib\FFT.py -> build\lib
copying Lib\LinearAlgebra.py -> build\lib
copying Lib\MLab.py -> build\lib
copying Lib\Matrix.py -> build\lib
copying Lib\Numeric.py -> build\lib
copying Lib\Precision.py -> build\lib
copying Lib\RandomArray.py -> build\lib
copying Lib\UserArray.py -> build\lib
running build_ext
C:\PROGRA~1\MICROS~1\VC98\BIN\cl.exe /nologo -IC:\PYTHON\include\python1.5 -IC:\PYTHON\include -
IInclude /c /FoSrc/_numpymodule.obj /TcSrc/_numpymodule.c
C:\PROGRA~1\MICROS~1\VC98\BIN\cl.exe /nologo -IC:\PYTHON\include\python1.5 -IC:\PYTHON\include -
IInclude /c /FoSrc/arrayobject.obj /TcSrc/arrayobject.c
C:\PROGRA~1\MICROS~1\VC98\BIN\cl.exe /nologo -IC:\PYTHON\include\python1.5 -IC:\PYTHON\include -
IInclude /c /FoSrc/ufuncobject.obj /TcSrc/ufuncobject.c
creating build\platlib
C:\PROGRA~1\MICROS~1\VC98\BIN\link.exe /DLL /nologo /LIBPATH:C:\PYTHON\libs libpython15.lib
Src/_numpymodule.obj Src/arrayobject.obj Src/ufuncobject.obj /OUT:build\platlib\_numpy.dll
/DEF:Src\_numpy.def
Traceback (innermost last):
File "setup.py", line 29, in ?
ext_modules = [('_numpy',
File "C:\PYTHON\distutils\core.py", line 96, in setup
dist.run_commands ()
File "C:\PYTHON\distutils\core.py", line 442, in run_commands
self.run_command (cmd)
File "C:\PYTHON\distutils\core.py", line 491, in run_command
cmd_obj.run ()
File "C:\PYTHON\distutils\command\build.py", line 52, in run
self.run_peer ('build_ext')
File "C:\PYTHON\distutils\core.py", line 802, in run_peer
self.distribution.run_command (command)
File "C:\PYTHON\distutils\core.py", line 491, in run_command
cmd_obj.run ()
File "C:\PYTHON\distutils\command\build_ext.py", line 146, in run
self.build_extensions (self.extensions)
File "C:\PYTHON\distutils\command\build_ext.py", line 243, in build_extensions
extra_postargs=extra_args)
File "C:\PYTHON\distutils\msvccompiler.py", line 180, in link_shared_object
self.spawn ( [ self.link ] + ld_args )
File "C:\PYTHON\distutils\ccompiler.py", line 421, in spawn
spawn (cmd, verbose=self.verbose, dry_run=self.dry_run)
File "C:\Python\distutils\spawn.py", line 37, in spawn
_spawn_nt (cmd, search_path, verbose, dry_run)
File "C:\Python\distutils\spawn.py", line 68, in _spawn_nt
raise DistutilsExecError("command failed: %d" % rc)
distutils.errors.DistutilsExecError: command failed: 1181
--
Robin Becker
From robin@jessikat.demon.co.uk Mon Jan 17 11:35:55 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Mon, 17 Jan 2000 11:35:55 +0000
Subject: [Matrix-SIG] bugs in MSVCCompiler ?
Message-ID: <6qBjnFAb6vg4Ewt2@jessikat.demon.co.uk>
I've just found what appears to be a bug in 0.1.2 in the MSVCCompiler
class.
at line 267 the library_filename functions should look like
def library_filename (self, libname):
"""Return the static library filename corresponding to the
specified library name."""
return "%s%s" %( libname, self._static_lib_ext )
def shared_library_filename (self, libname):
"""Return the shared library filename corresponding to the
specified library name."""
return "%s%s" %( libname, self._shared_lib_ext )
the original format strings were "lib%s%s" leading to errors such as
trying to use libpython15.lib during the build.
--
Robin Becker
From robin@jessikat.demon.co.uk Mon Jan 17 11:49:29 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Mon, 17 Jan 2000 11:49:29 +0000
Subject: [Matrix-SIG] Numerical Python Project
In-Reply-To: <R6ypTFAWRvg4EwIO@jessikat.demon.co.uk>
References: <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>
<R6ypTFAWRvg4EwIO@jessikat.demon.co.uk>
Message-ID: <GVFcoAAJHwg4Ew5h@jessikat.demon.co.uk>
The 15.1 numpy.pdf file seems to be broken.
--
Robin Becker
From robin@jessikat.demon.co.uk Mon Jan 17 11:37:42 2000
From: robin@jessikat.demon.co.uk (Robin Becker)
Date: Mon, 17 Jan 2000 11:37:42 +0000
Subject: [Matrix-SIG] Numerical Python Project
In-Reply-To: <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>
References: <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>
Message-ID: <962iTAAG8vg4Ewts@jessikat.demon.co.uk>
In article <NDBBIEFMILBFPMDHJIMFCEOACBAA.pauldubois@home.com>, Paul F.
Dubois <pauldubois@home.com> writes
I have now found a bug in my version of distutils and after fixing have
managed to build all the way through. What should I do to help the
cause?
--
Robin Becker
From gward@cnri.reston.va.us Mon Jan 17 20:31:32 2000
From: gward@cnri.reston.va.us (Greg Ward)
Date: Mon, 17 Jan 2000 15:31:32 -0500
Subject: [Matrix-SIG] Re: [Distutils] bugs in MSVCCompiler ?
In-Reply-To: <6qBjnFAb6vg4Ewt2@jessikat.demon.co.uk>; from robin@jessikat.demon.co.uk on Mon, Jan 17, 2000 at 11:35:55AM +0000
References: <6qBjnFAb6vg4Ewt2@jessikat.demon.co.uk>
Message-ID: <20000117153131.B9793@cnri.reston.va.us>
On 17 January 2000, Robin Becker said:
> I've just found what appears to be a bug in 0.1.2 in the MSVCCompiler
> class.
>
> at line 267 the library_filename functions should look like
>
> def library_filename (self, libname):
> """Return the static library filename corresponding to the
> specified library name."""
> return "%s%s" %( libname, self._static_lib_ext )
>
> def shared_library_filename (self, libname):
> """Return the shared library filename corresponding to the
> specified library name."""
> return "%s%s" %( libname, self._shared_lib_ext )
>
>
> the original format strings were "lib%s%s" leading to errors such as
> trying to use libpython15.lib during the build.
Yep, someone else already caught that -- fixed now.
Greg
From cgw@fnal.gov Mon Jan 17 23:15:33 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Mon, 17 Jan 2000 17:15:33 -0600 (CST)
Subject: [Matrix-SIG] Bugfix for instantiation of type 'O' arrays
Message-ID: <14467.41621.438874.379779@buffalo.fnal.gov>
The bug:
Python 1.5.2+ (#7, Jan 13 2000, 16:18:27) [GCC 2.95.2 19991024 (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> x=array(["abc","def","ghi"],'O')
>>> x
array([[abc , abc , abc ],
[def , def , def ],
[ghi , ghi , ghi ]],'O')
>>>
The fix:
Index: Src/arrayobject.c
===================================================================
RCS file: /cvsroot/numpy/Numerical/Src/arrayobject.c,v
retrieving revision 1.2
diff -u -r1.2 arrayobject.c
--- Src/arrayobject.c 2000/01/14 18:53:24 1.2
+++ Src/arrayobject.c 2000/01/17 23:10:33
@@ -1778,7 +1778,7 @@
PyErr_SetString(PyExc_ValueError,"expect source sequence");
return NULL;
}
- if (!((nd=discover_depth(s,99, type == PyArray_OBJECT)) > 0)) {
+ if (!((nd=discover_depth(s,99, type == PyArray_OBJECT || type == 'O')) > 0)) {
PyErr_SetString(PyExc_ValueError, "invalid input sequence");
return NULL;
}
And, while we're at it, a typo fix:
Index: README
===================================================================
RCS file: /cvsroot/numpy/Numerical/README,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 README
56c56
< UserArray.py: changed indentation to all spaces for consistency. Fixed many bugs in UserArray.py and Matrix.py (Charles Wadman)
---
> UserArray.py: changed indentation to all spaces for consistency. Fixed many bugs in UserArray.py and Matrix.py (Charles Waldman)
From vanandel@ucar.edu Tue Jan 18 16:12:22 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Tue, 18 Jan 2000 09:12:22 -0700
Subject: [Matrix-SIG] Proposal for further single-precision clean-up.
References: <Pine.LNX.4.10.10001160953080.13825-100000@us2.mayo.edu>
Message-ID: <388490E6.A6DCA53@atd.ucar.edu>
Travis: you asked for examples of the 'single precision problem'.
I am also working with huge arrays of single precision variables. I
really can not afford the extra memory to have any intermediate
calculations stored in double precision. I use statements like:
summedOutput = SameSizeAs(weight[i],out)*out
# from David Ascher's Numeric Python Tutorial
def SameSizeAs(input, ref):
return Numeric.array(input, ref.typecode())
This is pretty ugly and not at all intuitive. I'm glad that I can "get
by" with this solution in the short term, but I certainly hope that
Numeric Python can be changed to make this sort of kludge unnecessary.
These sort of kludges are barrier to understanding the code and tends
to prevent other scientists and programmers from adopting Numeric
Python.
Having passive casting be a (default) option for Numeric arrays sounds
like a fine solution.
--
Joe VanAndel
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
From Oliphant.Travis@mayo.edu Wed Jan 19 05:19:17 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Tue, 18 Jan 2000 23:19:17 -0600 (CST)
Subject: [Matrix-SIG] I have working code that implements active-casting concept.
Message-ID: <Pine.LNX.4.10.10001182305170.2600-100000@us2.mayo.edu>
I'm pleased to relate that I've been able to successfully implement the
active-casting concept briefly discussed in a previous post, using the
current Numerical Python. Preliminary testing shows it to work quite well
and seems to "remove the single-precision problem." if used.
I can patch the current tree as soon as I receive approval from Paul
Dubois, but he will likely want to hear opinions from this list, so speak
up if you hate the idea or love the idea. If no-one responds I will
assume that means a show of favor :-)
Here is the idea that I implemented:
Every array has an active attribute that defaults to 0, but can be set
in Python to 1 (if approved I would change code so the flag could be set
as a keyword to array()).
When a universal function involving NumPy arrays is encountered, if all
arrays are passive (active flag = 0) then the current coercion rules are
used. If any of the arguments to the function are active arrays, then the
active array with the largest typecode (enumerated types in arrayobject.h)
determines the output types. All other arrays are automatically cast
(even if it means loss of precision) to that type, before the operation
begins. The output arrays from the function are all active arrays.
Example:
a = array([1,2,3,4],'f')
b = a*4 # default casting rules make b double
a.active = 1
c = a*4 # now a governs the casting and c is float
The changes are not extensive, and should not break any old
code, so the only real question is does this provide a suitable fix?
Comments, critiques are welcome,
Travis
From rlw@stsci.edu Wed Jan 19 14:29:56 2000
From: rlw@stsci.edu (Rick White)
Date: Wed, 19 Jan 2000 09:29:56 -0500 (EST)
Subject: [Matrix-SIG] I have working code that implements active-casting concept.
Message-ID: <200001191429.JAA09201@sundog.stsci.edu>
Travis Oliphant writes:
>I'm pleased to relate that I've been able to successfully implement the
>active-casting concept briefly discussed in a previous post, using the
>current Numerical Python. Preliminary testing shows it to work quite well
>and seems to "remove the single-precision problem." if used.
>
>I can patch the current tree as soon as I receive approval from Paul
>Dubois, but he will likely want to hear opinions from this list, so speak
>up if you hate the idea or love the idea. If no-one responds I will
>assume that means a show of favor :-)
I think this is great -- I'm delighted to see Travis moving this
forward! For my work, at least, his proposal will make Numeric much
more useful.
If I could add one thing, it would be nice to have some standard
convenience functions (in Numeric.py) for creating active arrays.
Certainly it is not a big deal, but I'm sure people that create active
arrays will write their own such functions, so we might as well
standardize them.
Travis's changes (including moving array_set into the Numeric module,
etc.) are big steps toward removing the major shortcomings of Numeric
for our work (astronomical data analysis and image processing).
Rick
----
Richard L. White rlw@stsci.edu http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD
From ransom@cfa.harvard.edu Wed Jan 19 14:53:06 2000
From: ransom@cfa.harvard.edu (Scott M. Ransom)
Date: Wed, 19 Jan 2000 14:53:06 +0000
Subject: [Matrix-SIG] I have working code that implements active-casting
concept.
References: <200001191429.JAA09201@sundog.stsci.edu>
Message-ID: <3885CFD2.C63F056A@cfa.harvard.edu>
Rick White wrote:
>
> Travis's changes (including moving array_set into the Numeric module,
> etc.) are big steps toward removing the major shortcomings of Numeric
> for our work (astronomical data analysis and image processing).
Hear! Hear! I completely agree.
And I would like to thank Travis for stepping up to the plate and making
the changes.
With these changes, I will almost certainly become a more active member
of the NumPy community -- and will attempt to spread the NumPy gospel
among my astronomer colleagues. (Down with IDL!)
As for a request for particular "single precision problems", I think
Travis' current changes have addressed them completely (at least in my
case).
The main problem came from passing single precision arrays to/from NumPy
from/to C (or Fortran) library functions. While this was certainly
possible in the past, it became a royal pain if you wanted to manipulate
these arrays in Python before or after calling the library functions --
the arrays were up-cast to double (I got around this before by writing a
simple C function to downcast double precision NumPy arrays to single
precision).
Hopefully this is now a problem of the past.
Thanks again Travis,
Scott
--
Scott M. Ransom Address: Harvard-Smithsonian CfA
Phone: (617) 495-4142 60 Garden St. MS 10
email: ransom@cfa.harvard.edu Cambridge, MA 02138
PGP Fingerprint: D2 0E D0 10 CD 95 06 DA EF 78 FE 2B CB 3A D3 53
From Oliphant.Travis@mayo.edu Wed Jan 19 17:21:58 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Wed, 19 Jan 2000 11:21:58 -0600 (CST)
Subject: [Matrix-SIG] Active arrays
Message-ID: <Pine.LNX.4.10.10001191112240.4605-100000@us2.mayo.edu>
If active arrays were to become part of Numerical Python, I've been
thinking of a couple of ways to make them easy to use.
Of course there is the attribute setting approach as explained before.
I've thought of two other possibilities:
(1) An attribute that returns an active version of the array (pointing to
the same data) so that (for example) b.asactive returns a reference to the
data in b as an active array.
(2) An argument to the general array() command along with another command,
e.g. activearray() which sets this argument.
One final request: If someone as a better idea as to what to call this
property instead of active, I'm open to suggestions.
Thanks,
Travis
From hinsen@cnrs-orleans.fr Wed Jan 19 18:05:57 2000
From: hinsen@cnrs-orleans.fr (Konrad Hinsen)
Date: Wed, 19 Jan 2000 19:05:57 +0100
Subject: [Matrix-SIG] I have working code that implements active-casting concept.
In-Reply-To: <Pine.LNX.4.10.10001182305170.2600-100000@us2.mayo.edu> (message
from Travis Oliphant on Tue, 18 Jan 2000 23:19:17 -0600 (CST))
References: <Pine.LNX.4.10.10001182305170.2600-100000@us2.mayo.edu>
Message-ID: <200001191805.TAA27409@chinon.cnrs-orleans.fr>
> I can patch the current tree as soon as I receive approval from Paul
> Dubois, but he will likely want to hear opinions from this list, so speak
> up if you hate the idea or love the idea. If no-one responds I will
> assume that means a show of favor :-)
It definitely sounds as if it would
1) solve the problems
2) not cause problems for those who had none before.
I suggest you prepare a beta release that will let everyone interested
test the idea and the implementation before inclusion in an "official"
release.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
From n8gray@earthlink.net Wed Jan 19 18:40:24 2000
From: n8gray@earthlink.net (Nathaniel Gray)
Date: Wed, 19 Jan 2000 10:40:24 -0800
Subject: [Matrix-SIG] Active arrays
References: <Pine.LNX.4.10.10001191112240.4605-100000@us2.mayo.edu>
Message-ID: <38860518.DEF74DFC@earthlink.net>
Travis Oliphant wrote:
>
> One final request: If someone as a better idea as to what to call this
> property instead of active, I'm open to suggestions.
>
It would be nice to see something a bit more descriptive than 'active',
although I can't think of anything better off the top of my head. Since
the issue at hand (I believe) is controlling precision, something along
the lines of 'precise' or 'strongPrecision' would be more informative.
Maybe 'strongCasting' would be better, since casting is the process
being controlled. In any case, I would like to suggest that some
thought be given to the name -- there are already too many 'active'
doodads in computing today.
--
Nathaniel A. Gray
--
"But the sun is going down!"
"No, no, you're all confused. The horizon is moving up."
-The Firesign Theatre
--
PGP Key:
http://certserver.pgp.com:11371/pks/lookup?op=get&search=0x95345747
For PGP: http://www.pgpi.com/
From minxu@scisun.sci.ccny.cuny.edu Wed Jan 19 19:23:41 2000
From: minxu@scisun.sci.ccny.cuny.edu (Min Xu)
Date: Wed, 19 Jan 2000 14:23:41 -0500 (EST)
Subject: [Matrix-SIG] Active arrays
Message-ID: <200001191923.OAA21391@scisun.sci.ccny.cuny.edu>
Hi,
Is it better to call as: stick?
We have: a.stick=1
b = a.asstick()
c = stick(a)
etc.
Min Xu
From n8gray@earthlink.net Wed Jan 19 19:30:53 2000
From: n8gray@earthlink.net (Nathaniel Gray)
Date: Wed, 19 Jan 2000 11:30:53 -0800
Subject: [Matrix-SIG] Active arrays
References: <200001191923.OAA21391@scisun.sci.ccny.cuny.edu>
Message-ID: <388610ED.4B1858D8@earthlink.net>
Min Xu wrote:
>
> Hi,
>
> Is it better to call as: stick?
>
Maybe 'sticky' or 'stickyCasting'.
--
Nathaniel A. Gray
--
"But the sun is going down!"
"No, no, you're all confused. The horizon is moving up."
-The Firesign Theatre
--
PGP Key:
http://certserver.pgp.com:11371/pks/lookup?op=get&search=0x95345747
For PGP: http://www.pgpi.com/
From da@ski.org Wed Jan 19 21:20:31 2000
From: da@ski.org (David Ascher)
Date: Wed, 19 Jan 2000 13:20:31 -0800
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <Pine.LNX.4.10.10001191447480.5256-100000@us2.mayo.edu>
Message-ID: <003e01bf62c3$041f7b20$c355cfc0@ski.org>
> > Never tried DocBook.
> >
>
> Me neither, but lots of people use it. It is SGML at it's core, though.
As I'm sure Travis knows but maybe Paul and others don't, Docbook is an
XML/SGML markup, it's not an editor. I would hate to have to write tables
with it. Serious writing w/ docbook requires a serious SGML/XML editor,
although I suppose most users are just using emacs. I also suspect that
DocBook is overkill for NumPy doc, if it's overkill for Python's main doc
(in the opinion of Fred Drake, IIRC).
> So what is it about Frame that keeps people from munging the basic
> structure? It is hard to write documentation with multiple people
> involved using a binary-only file. Aren't the problems you encountered
> with LaTeX the same as those encountered with any group alteration of a
> source? The same thing could happen with the C and Python code, too.
LaTeX allows people to define macros and makes writers think like
programmers. Bad idea. =) Many many folks don't know LaTeX but would be
able to pick up a WYSIWYG editor easily.
> I'm not convinced that LaTeX or DocBook wouldn't be a more useful group
> documentation format. I use LaTeX an awful lot, and really like it.
> Admitedly, the only multiple-author writing I've done is a paper where we
> both knew and loved LaTeX. It worked great :-)
I refuse to use LaTeX. Can't even justify why, it's a gut reaction after
writing too many papers, a several-hundred page dissertation with it,
spending waaaayy too many hours debugging poorly written LaTeX macros,
fussing with DVI, PS, EPS, bounding boxes, BibTeX, fussy installations,
missing fonts, bad HTML conversion, etc.
That said, I don't like Frame on the PC either, after having written the
current document. The UI was designed for the mac, and it works much better
on the mac (I've typeset two significant books with very complex tagging and
hundreds of plates on the Mac about 4 years ago, and it was far easier than
producing the NumPy doc). As it stands FrameMaker's UI violates many of the
assumptions of the average Windows user (I can't remember what keystroke
sequence that I use all the time in other software causes a line to be
deleted w/o any possibility to recover) Overall I think that the state of
the world is pretty rotten when it comes to collaborative authorship outside
of the world of Microsoft, which I realize we can't use.
DocBook or other XML/SGML markup is probably the way to go, but I'm still
quite frustrated with the authoring tools. Whenever I have to match tags I
feel like i'm back on the IBM VM/CMS machine on a 3278 terminal. There's a
*reason* we have megapixel displays! There's *a point* to the megabytes of
memory being used by graphics subsystems! There's *value* in the decades of
work in user interfaces. There's *truth* to the feeling my mom has that the
Mac is easier to use than Unix. </deep breath>. Sorry, I had to get that
off my chest.
Finally, there's StarOffice, but it seemed quite immature the last time I
checked. It is available free for Unix and Windows.
http://www.sun.com/staroffice/
I propose that this discussion be shelved until Developer Day at the
conference, and that we figure out in the DOC-SIG section what Python's
going to do for its core doc, and follow along. Synergy.
--david
From KRodgers@ryanaero.com Wed Jan 19 21:35:21 2000
From: KRodgers@ryanaero.com (Rodgers, Kevin)
Date: Wed, 19 Jan 2000 13:35:21 -0800
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
Message-ID: <0D8C1A50C283D311ABB800508B612E5354B334@ryanaero.com>
David Ascher wrote:
[deleted]
>sequence that I use all the time in other software causes a line to
be
>deleted w/o any possibility to recover) Overall I think that the
state of
>the world is pretty rotten when it comes to collaborative
authorship outside
>of the world of Microsoft, which I realize we can't use.
Far and away the best tool I've ever used for this sort of thing is
Interleaf. It was designed from the ground up to be an environment for
production of long, structured documents by many authors collaborating. It
works on Windows and Unix (I don't know about Mac). It is pretty expensive,
though. True story: my former company was putting together a technical
proposal in 1996, using Word. They had lots of problems, and called up
Microsoft. M$ said something along the lines of, "You idiots, Word wasn't
intended to do large, structured documents! Use Interleaf, or something
like that!"
I suspect one of the main points against FrameMaker (and Interleaf,
Word, etc) is that they COST MONEY. I tend to agree that it's kinda icky to
use expensive proprietary tools to document an open source collaborative
effort (the Python Reference Manual is a different story, since Guido is
more or less solely responsible for that). But I don't have any solutions
either.
Since I won't be at the Conference, I'll be looking forward to
anything that materializes there.
Kevin Rodgers
krodgers@ryanaero.com
From Oliphant.Travis@mayo.edu Wed Jan 19 21:38:17 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Wed, 19 Jan 2000 15:38:17 -0600 (CST)
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org>
Message-ID: <Pine.LNX.4.10.10001191528330.5256-100000@us2.mayo.edu>
> As I'm sure Travis knows but maybe Paul and others don't, Docbook is an
> XML/SGML markup, it's not an editor. I would hate to have to write tables
> with it. Serious writing w/ docbook requires a serious SGML/XML editor,
> although I suppose most users are just using emacs. I also suspect that
> DocBook is overkill for NumPy doc, if it's overkill for Python's main doc
> (in the opinion of Fred Drake, IIRC).
>
Probably, true, but what is Fred using for Python's documentation :-)?
>
> LaTeX allows people to define macros and makes writers think like
> programmers. Bad idea. =) Many many folks don't know LaTeX but would be
> able to pick up a WYSIWYG editor easily.
>
Not necessarily. You don't have to write macros. In fact, I rarely do.
Actually, I would suggest trying LyX (although it probably doesn't run on
the MaC). I use it constantly and I've really grown to like it. It is a
WYSIWYM (What you see is what you mean) editor where you enter text
in a format that looks a lot like it will print --- it just doesn't try to
perfectly typeset as you go.
It is very easy to pick up, and entering math is beautiful. I'm actually
able to derive complicated expressions using this tool which has saved
lot's of scratch paper :-)
For me it works great, but different people have different needs, of
course.
>
> DocBook or other XML/SGML markup is probably the way to go, but I'm still
> quite frustrated with the authoring tools. Whenever I have to match tags I
> feel like i'm back on the IBM VM/CMS machine on a 3278 terminal. There's a
> *reason* we have megapixel displays! There's *a point* to the megabytes of
> memory being used by graphics subsystems! There's *value* in the decades of
> work in user interfaces. There's *truth* to the feeling my mom has that the
> Mac is easier to use than Unix. </deep breath>. Sorry, I had to get that
> off my chest.
>
> Finally, there's StarOffice, but it seemed quite immature the last time I
> checked. It is available free for Unix and Windows.
> http://www.sun.com/staroffice/
I've used it and it works like Word (which is why I don't use it :-) ),
equations are a pain to enter and it want's me to fuss with how the final
format is going to look when I just want to fuss with the content.
>
> I propose that this discussion be shelved until Developer Day at the
> conference, and that we figure out in the DOC-SIG section what Python's
> going to do for its core doc, and follow along. Synergy.
No problem. Fill me in on how the discussion goes.
Travis
From cspence@sarnoff.com Wed Jan 19 22:31:46 2000
From: cspence@sarnoff.com (Clay Spence x3039)
Date: Wed, 19 Jan 2000 17:31:46 -0500
Subject: [Matrix-SIG] Build problem under Solaris 2.6
Message-ID: <38863B52.B0B12747@sarnoff.com>
Hi,
I'm having a problem building release 14 under Solaris 2.6 with Sun's C
compiler. The following occurs:
cholla 332% python setup.py build install
running build
<snip>
Src/_numpymodule.c:
"Src/_numpymodule.c", line 48: undefined symbol:
PyArray_FromDimsAndDataAndDescr_NUM
"Src/_numpymodule.c", line 48: undefined symbol:
PyArray_FromDimsAndDataAndDescr
cc: acomp failed for Src/_numpymodule.c
It does not seem to be a limitation on preprocessor symbol names. I can
define PyArray_FromDimsAndDataAndDescr_NUM myself in a very short test
program and it compiles with no problem. However, the following file
gives the same error:
-----------
#include <stdio.h>
#include "Python.h"
#define _ARRAY_MODULE
#include "arrayobject.h"
int
main()
{
printf("%d\n", PyArray_Type_NUM);
printf("%d\n", PyArray_FromDimsAndDataAndDescr_NUM);
return 0;
}
-----------
It doesn't complain about PyArray_Type_NUM. The presence or absence of
"#define _ARRAY_MODULE" doesn't affect the error. Older versions (I
think 11 was the last I tried) compiled fine. Any ideas?
Thanks,
Clay
From zow@pensive.llnl.gov Wed Jan 19 23:28:23 2000
From: zow@pensive.llnl.gov (Zow Terry Brugger)
Date: Wed, 19 Jan 2000 15:28:23 -0800
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: Message from "Rodgers, Kevin" <KRodgers@ryanaero.com>
of "Wed, 19 Jan 2000 13:35:21 PST." <0D8C1A50C283D311ABB800508B612E5354B334@ryanaero.com>
Message-ID: <200001192327.SAA15242@python.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
> Far and away the best tool I've ever used for this sort of thing is
> Interleaf. It was designed from the ground up to be an environment for
> production of long, structured documents by many authors collaborating. It
Whoa! They used Interleaf for the documentation at the last company I worked
with and their experience with it was enough to sway me away from it
permanently. The documentation department was just two people, but both were
highly intelligent, competent people (so I'm ruling out user error).
First of all, Interleaf is very expensive and very complicated. To use it for
the NumPy documentation would be like suggesting we use ClearCase for the
revision control. It would require a large amount of outlay of cash and
training for everyone involved, which is obviously not feasible.
Secondly, Interleaf was going down-hill last I heard (about two years ago) -
bugs were going unfixed for years at a time, new functionality wasn't being
added, etc. The theory was that too much of their customer base was moving to
more cost-effective solutions, like Frame Maker, which is what that company
was doing when I left.
I'm left with the impression that Interleaf is probably still a good solution
if you have tens or hundreds of people working on the same documents and a
full time staff devoted to maintaining Interleaf, but for a distributed,
collaborative project, I don't think there's any way it could work.
I think what we really need to do is examine exactly what we're looking for a
documentation tool. Maybe some of the simpler word processors like Star Office
or Abi Word do everything we really need. Or maybe HTML is sufficient for our
needs: anyone can edit it and most people have an HTML editor they're very
comfortable with. Everyone has an HTML viewer they're happy with, and most of
those can generate very acceptable printed pages. On the flip side, I can just
see the wars starting over, "You're Frontpage completely ruined the formating
of this document!" "Well, I had to do that because I don't want to be bothered
with the tags like you are in vi!" Food for thought.
Terry
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOIZIk6fuGVwXgOQkEQLDcgCfR6O5tFr42dKyqWazzIXWBsiAgY4AoOZz
WUaXNqnCAyKrIg1zYTy3HgrJ
=KWap
-----END PGP SIGNATURE-----
From jhauser@ifm.uni-kiel.de Wed Jan 19 23:51:01 2000
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Thu, 20 Jan 2000 00:51:01 +0100 (CET)
Subject: [Matrix-SIG] Active arrays
In-Reply-To: <Pine.LNX.4.10.10001191112240.4605-100000@us2.mayo.edu>
References: <Pine.LNX.4.10.10001191112240.4605-100000@us2.mayo.edu>
Message-ID: <20000119235102.11212.qmail@lisboa.ifm.uni-kiel.de>
Two, no three things I want to add to the discussion.
1. I welcome the addition of the new casting machinery to Numpy. It
seems, as this needs to go into the core, so some files needs to be
changed. It's totally different than the older proposals (typing
like the longs in standard python), but it seems to be suitable for
the problems one had until now.
I would suggest to have a new flag to asarray(), like
a=ones((10,8))
b=asarray(a, nocast=1) # nocast is not an optimal name.
The current idea with asarray is to guarantee something, without
doing a copy if not wanted or necessary. asarray is probably used
in many functions already, where one wants that a given parameter
fulfills some constraints.
Then a way is needed to ask for this property, and perhaps I have
missed it but nobody mentioned the removing of this property. It
would be good to do this without a copy of the data.
2. As we see with this addition to NumPy we need a policy for the
cvs-development. Should this be added in a branch, what happens if
two people work on the same files, but with different branches. How
can interested people easily get an overview about the different
developments and check out a complete ``cutting edge'' version?
The piddle folks are already working at such a policy, although
they have a more modular code base with different main developers
for every module. Perhaps we should look into this.
3. I would also like to include array_map and array_set into the main
code base. But in an own util module. array_set is not the complete
solution to the gather/... thing. So it should be made clear, that
perhaps there will be some other more general way to do this. Also
with array_map. I really like this, but I need to build constructs
to use it with lower dimensional functions. Like applying a one
dimensional spline interpolation to every vertical profile in my
three dimensional temperature field. These are involving globals,
and I actually haven't really timed it, but it seems to work
well. So what I mean, these things are evolving, perhaps changing,
so we should make them accessible but keep them separate, at least
for some time.
Then some names for this `active' thingy.
typed
keeptype
hold
holdtype
rulez :-) # Heh NumPy rulez
__Janko
From dubois1@llnl.gov Wed Jan 19 23:36:35 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Wed, 19 Jan 2000 15:36:35 -0800
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
References: <200001192327.SAA15242@python.org>
Message-ID: <00011915515100.00571@almanac>
I started this as a private thread between David and Travis and I, so thi=
s
public discussion is missing the following background:
The current doc for Numerical is in Frame. I made this choice because it =
is a
WSYWIG tool that can make HTML and PDF if needed. Also, Frame is relative=
ly
easy to learn, and is the only choice for books really. And Numerical Pyt=
hon
the Manual could easily become Numerical Python the Book. It has 17 chapt=
ers
already.=20
I have done collaborative manuals before in LateX (disaster) and a
similar product LLNL had (disaster). ANY document system that used struc=
tures
edited by humans invariably results in the structures being screwed up by
somebody and the next poor person who actually tries to make the output e=
nds up
searching by bisection for the errors. Latex in particular suffered from
non-portability between authors who had slightly different installations,=
as
someone else mentioned.
While I am quite open to change, the only thing really wrong with Frame i=
s that
it costs money and doesn't run on Linux for one. But it does run on Mac,
Windows, and Solaris, which enables a lot of people.
Anyway, I hardly think any other solution that involves money would be an=
y
better. I disagree that HTML is ok; even if everyone uses a WYSIWIG, the
language is sufficiently inexpressive that it is a problem (especially fo=
r
writing about a language in which indentation counts). Besides, I want to=
ols
that help me make and maintain the index and TOC.
From jhauser@ifm.uni-kiel.de Wed Jan 19 23:54:05 2000
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Thu, 20 Jan 2000 00:54:05 +0100 (CET)
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org>
References: <Pine.LNX.4.10.10001191447480.5256-100000@us2.mayo.edu> <003e01bf62c3$041f7b20$c355cfc0@ski.org>
Message-ID: <20000119235405.11218.qmail@lisboa.ifm.uni-kiel.de>
We need to separate the documentation. We need a technical
documentation explaining the functions, classes and the parameters. I
would keep this in the same format like the standard python library
documentation. There will be tools to parse these files and extract
the info directly at the interpreter prompt, or link to them in a help
browser of the system. This info can have internal and external links
and put into many different output formats.
This has also the benefit, that module writers can do this kind of
documentation much easier (from a authoring perspective) than a
complete and right mathematical documentation. If we mix these two
kinds together it will take longer to document everything.
The pure module documentation (let's call it reference) can also be
included into the CVS. The tutorial and the mathematical rich
documents can be authored externally (and will probably only by the
actual author) with more suitable tools and will probably only be
available as PDF's.
Just some suggestions,
__Janko (who likes LaTeX a lot :-)
From jhauser@ifm.uni-kiel.de Thu Jan 20 00:03:44 2000
From: jhauser@ifm.uni-kiel.de (Janko Hauser)
Date: Thu, 20 Jan 2000 01:03:44 +0100 (CET)
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <00011915515100.00571@almanac>
References: <200001192327.SAA15242@python.org> <00011915515100.00571@almanac>
Message-ID: <20000120000345.11248.qmail@lisboa.ifm.uni-kiel.de>
Just a note about Framemaker. There is a beta downloadable for linux,
although I have it not running. On the other side, I have mixed
feelings about fmaker, because they stopped to support the digital
alpha platform. Or have said, they will not provide a version for the
new TrueAlpha releases.
__Janko
From turner@blueskystudios.com Thu Jan 20 00:15:37 2000
From: turner@blueskystudios.com (John A. Turner)
Date: Wed, 19 Jan 2000 19:15:37 -0500 (EST)
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org>
References: <Pine.LNX.4.10.10001191447480.5256-100000@us2.mayo.edu>
<003e01bf62c3$041f7b20$c355cfc0@ski.org>
Message-ID: <14470.21417.858962.47725@denmark.blueskystudios.com>
>>>>> "DA" == David Ascher <da@ski.org> writes:
DA> Finally, there's StarOffice, but it seemed quite immature the last
DA> time I checked. It is available free for Unix and Windows.
DA> http://www.sun.com/staroffice/
well, if "Unix" is defined to be "Solaris and Linux"
>>>>> "PFD" == Paul F Dubois <dubois1@llnl.gov> writes:
PFD> Anyway, I hardly think any other solution that involves money
PFD> would be any better. I disagree that HTML is ok; even if everyone
PFD> uses a WYSIWIG, the language is sufficiently inexpressive that it
PFD> is a problem (especially for writing about a language in which
PFD> indentation counts).
agreed
PFD> Besides, I want tools that help me make and maintain the index
PFD> and TOC.
for me, the name of that tool is spelled "LaTeX"
--
John A. Turner, Senior Research Associate
Blue Sky Studios, One South Rd, Harrison, NY 10528
http://www.blueskystudios.com/ (914) 381-8400
From vanandel@ucar.edu Thu Jan 20 00:32:25 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Wed, 19 Jan 2000 17:32:25 -0700
Subject: [Matrix-SIG] Active arrays
References: <Pine.LNX.4.10.10001191112240.4605-100000@us2.mayo.edu> <20000119235102.11212.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <38865799.188493B0@atd.ucar.edu>
-- Then some names for this `active' thingy.
>typed
>keeptype
>hold
>holdtype
How about 'promote', set to '0' if promotion to double is not wanted?
Joe VanAndel
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
From roitblat@hawaii.edu Thu Jan 20 01:02:55 2000
From: roitblat@hawaii.edu (Herbert L. Roitblat)
Date: Wed, 19 Jan 2000 15:02:55 -1000
Subject: [Matrix-SIG] Active arrays
Message-ID: <02d201bf62e2$167ee890$8fd6afcf@0gl1u.pixi.com>
Are we talking about fixed precision? Maybe use fixed or some variant?
-----Original Message-----
From: Joe Van Andel <vanandel@atd.ucar.edu>
To: Janko Hauser <jhauser@ifm.uni-kiel.de>
Cc: Matrix-Sig <Matrix-sig@python.org>
Date: Wednesday, January 19, 2000 2:34 PM
Subject: Re: [Matrix-SIG] Active arrays
>
>-- Then some names for this `active' thingy.
>
>>typed
>>keeptype
>>hold
>>holdtype
>
>How about 'promote', set to '0' if promotion to double is not wanted?
>
>
>Joe VanAndel
>National Center for Atmospheric Research
>http://www.atd.ucar.edu/~vanandel/
>Internet: vanandel@ucar.edu
>
>_______________________________________________
>Matrix-SIG maillist - Matrix-SIG@python.org
>http://www.python.org/mailman/listinfo/matrix-sig
>
From ransom@cfa.harvard.edu Thu Jan 20 01:39:10 2000
From: ransom@cfa.harvard.edu (Scott M. Ransom)
Date: Thu, 20 Jan 2000 01:39:10 +0000
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
References: <Pine.LNX.4.10.10001191447480.5256-100000@us2.mayo.edu>
<003e01bf62c3$041f7b20$c355cfc0@ski.org> <14470.21417.858962.47725@denmark.blueskystudios.com>
Message-ID: <3886673E.7418F058@cfa.harvard.edu>
"John A. Turner" wrote:
>
> PFD> Anyway, I hardly think any other solution that involves money
> PFD> would be any better. I disagree that HTML is ok; even if everyone
> PFD> uses a WYSIWIG, the language is sufficiently inexpressive that it
> PFD> is a problem (especially for writing about a language in which
> PFD> indentation counts).
>
> agreed
>
> PFD> Besides, I want tools that help me make and maintain the index
> PFD> and TOC.
>
> for me, the name of that tool is spelled "LaTeX"
I would have to agree that CVS'd LaTeX is the lesser of all of the
evils. It has the advantage of being free and available in one form or
another on virtually every system out there.
If a simple document class is chosen (and all required style files are
included in CVS) I don't see why this would lead to a disaster.
I have successfully managed to use CVS LaTeX in a collaborative manner
before -- it is not the easiest thing to manage, but it is not difficult
either.
Other benefits include automatic TOC and Indices as well as exporting to
about any format you can think of.
Other problems could be minimized by a couple page "Author's Guide" to
the NumPy documentation.
Just my two bits,
Scott
--
Scott M. Ransom
Phone: (781) 320-9867 Address: 75 Sanderson Ave.
email: ransom@cfa.harvard.edu Dedham, MA 02026
PGP Fingerprint: D2 0E D0 10 CD 95 06 DA EF 78 FE 2B CB 3A D3 53
From ffjhl@uaf.edu Thu Jan 20 03:34:23 2000
From: ffjhl@uaf.edu (Jonah Lee)
Date: Wed, 19 Jan 2000 18:34:23 -0900 (AKST)
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <3886673E.7418F058@cfa.harvard.edu>
Message-ID: <Pine.OSF.3.95.1000119182137.15499C-100000@mealpha.engr.uaf.edu>
On Thu, 20 Jan 2000, Scott M. Ransom wrote:
>
> I would have to agree that CVS'd LaTeX is the lesser of all of the
> evils. It has the advantage of being free and available in one form or
> another on virtually every system out there.
>
> If a simple document class is chosen (and all required style files are
> included in CVS) I don't see why this would lead to a disaster.
>
> I have successfully managed to use CVS LaTeX in a collaborative manner
> before -- it is not the easiest thing to manage, but it is not difficult
> either.
I've used LyX to do the same (on several unix variants) and find it to
work quite well in a collaborative manner (using CVS). LyX is at a little
bit higher level than LaTeX so may have less problems in compatibility
among cvs users. One potential downside is that it may not be as easy to
install on non-Unix platforms. I never tried LyX on non-unix platforms,
but the installation instructions for LyX on those platforms seem somewhat
involved.
>
> Other problems could be minimized by a couple page "Author's Guide" to
> the NumPy documentation.
This is a good idea.
Regards,
Jonah
From pavlos@gaaros.com Thu Jan 20 05:25:18 2000
From: pavlos@gaaros.com (Pavlos Christoforou)
Date: Thu, 20 Jan 2000 00:25:18 -0500 (EST)
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <003e01bf62c3$041f7b20$c355cfc0@ski.org>
Message-ID: <Pine.LNX.4.04.10001200022240.10346-100000@gaaros.msrc.sunysb.edu>
On Wed, 19 Jan 2000, David Ascher wrote:
>
> I refuse to use LaTeX. Can't even justify why, it's a gut reaction after
> writing too many papers, a several-hundred page dissertation with it,
> spending waaaayy too many hours debugging poorly written LaTeX macros,
> fussing with DVI, PS, EPS, bounding boxes, BibTeX, fussy installations,
> missing fonts, bad HTML conversion, etc.
Hmmm maybe you got carried away with too many macros. In my department
nobody writes macros and the latest latex distributions (at least the
default Red Hat Linux one) seem to be quite complete. Afew people are laso
using LyX which is not bad.
Just a comment
Pavlos
From rob@hooft.net Thu Jan 20 06:52:18 2000
From: rob@hooft.net (Rob W. W. Hooft)
Date: Thu, 20 Jan 2000 07:52:18 +0100 (MET)
Subject: [Matrix-SIG] I have working code that implements active-casting concept.
In-Reply-To: <Pine.LNX.4.10.10001182305170.2600-100000@us2.mayo.edu>
References: <Pine.LNX.4.10.10001182305170.2600-100000@us2.mayo.edu>
Message-ID: <14470.45218.362848.247846@vleet.chem.uu.nl>
>>>>> "TO" == Travis Oliphant <Oliphant.Travis@mayo.edu> writes:
TO> When a universal function involving NumPy arrays is encountered,
TO> if all arrays are passive (active flag = 0) then the current
TO> coercion rules are used. If any of the arguments to the function
TO> are active arrays, then the active array with the largest
TO> typecode (enumerated types in arrayobject.h) determines the
Ah, so not the one with the greatest activity...
TO> output types. All other arrays are automatically cast (even if
TO> it means loss of precision) to that type, before the operation
TO> begins. The output arrays from the function are all active
TO> arrays.
This is a great idea, and it will certainly simplify my code. However,
I'd like to raise one point of concern:
I am using some functions that use 2 arrays: a small one, used repeatedly
and a big one that changes on every invocation. If the small array is
passive-d and the big one is active-f, this will cast the small one
to 'f' on every invocation. Without the active/passive patch, I'd find
out about this inefficiency because the result would be of type 'd'. Would
there be any way of warning the programmer for this kind of inefficient
casting with the new code?
Regards,
Rob Hooft
--
===== rob@hooft.net http://www.xs4all.nl/~hooft/rob/ =====
===== R&D, Nonius BV, Delft http://www.nonius.nl/ =====
===== PGPid 0xFA19277D ========================== Use Linux! =========
From Oliphant.Travis@mayo.edu Thu Jan 20 07:08:32 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Thu, 20 Jan 2000 01:08:32 -0600 (CST)
Subject: [Matrix-SIG] Space-saving arrays and authoring tools.
Message-ID: <Pine.LNX.4.10.10001200030300.6194-100000@us2.mayo.edu>
Well, the changes to NumPy to provide space-saving (I used to call them
active) are in CVS. Anyone who wants to try them out can check out the
current source tree from sourceforge.net
Three new syntax items:
1) array() now takes a savespace keyword (default is 0) which if non-zero
specifies that the constructed array be a "spacesaver" array. This has
two effects: first, construction from Python (nested) lists and scalars
produces single-precision arrays, and second, the new array has the
savespace flag set so that it will control the casting in ufunc
operations.
Suppose a is a NumPy array
2) a.savespace(flag=value) sets the savespace flag to value (1 or 0)
3) a.spacesaver() queries the flag.
Currently, the behavior if two spacesaving arrays are found in an
operation is to cast to the largest precision spacesaving array. However,
when a similar proposal was made several months ago by Michael Hudson,
several people said that it would be better to throw an exception under
such circumstances. I would like more opinions on this. I haven't had
enough experience to decide which is better, but I'm leaning towards the
throwing-the-exception option.
**** Proposal buried in the next paragraph ****
Eventually we have to fix this rank-0 array/ scalar question. Right now
rank-0 arrays are sort of scalars and sort of not which makes things messy
both from a users point of view and a programmers point of view. I think
rank-0 arrays should be given their rightful existence and be the return
type for all indexing operations, math operations, etc. (basically, get
rid of Pyarray_Return). Because Python allows you to define methods to
determine how your types are interpreted as numbers, the rank-0 arrays
will behave rather nicely. We could even use them to index into NumPy
arrays with little trouble. Then, we define a method .toscalar() that
gets the appropriate Python scalar for those times when you really need
it.
The truth is NumPy arrays are not Python numbers, lists, or dictionaries,
even though they can act like them (often seemlessly) sometimes. I don't
think it is confusing to separate the concepts for the user (since the
differences will get you someday if you don't understand them).
About authoring tools.
I find it interesting that 5 people have said that a controlled LaTeX or
LyX would be a good option for documentation (and I know of another 2 as
well). Are David and Paul the only ones that don't like the idea of using
LaTeX or are the rest of you remaining silent?
There are important points to consider regarding the opposition to LaTeX:
1) LyX reduces the learning curve to LaTeX dramatically.
2) LaTeX installations have matured: teTeX is standard package that
contains what you really need.
From Oliphant.Travis@mayo.edu Thu Jan 20 07:17:27 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Thu, 20 Jan 2000 01:17:27 -0600 (CST)
Subject: [Matrix-SIG] I have working code that implements active-castingconcept.
In-Reply-To: <14470.45218.362848.247846@vleet.chem.uu.nl>
Message-ID: <Pine.LNX.4.10.10001200110290.6194-100000@us2.mayo.edu>
>
> This is a great idea, and it will certainly simplify my code. However,
> I'd like to raise one point of concern:
>
> I am using some functions that use 2 arrays: a small one, used repeatedly
> and a big one that changes on every invocation. If the small array is
> passive-d and the big one is active-f, this will cast the small one
> to 'f' on every invocation. Without the active/passive patch, I'd find
> out about this inefficiency because the result would be of type 'd'. Would
> there be any way of warning the programmer for this kind of inefficient
> casting with the new code?
Let me see if I understand: You want to be able to catch that you are
casting the passive array on every function call (presumably so you can
change it and cast once)?
Right now you have to check the output type, correct?
With the current changes in CVS, the result would be of type 'active-f'
which is not the type of the small input array, so you could just check to
make sure the types are the same. What am I missing?
Another person wanted two "active" arrays of different types to raise an
exception, so with that change you would make both arrays active and if
they were not the same type an error would occur. What do you think?
Travis
From rob@hooft.net Thu Jan 20 09:24:37 2000
From: rob@hooft.net (Rob W. W. Hooft)
Date: Thu, 20 Jan 2000 10:24:37 +0100 (MET)
Subject: [Matrix-SIG] I have working code that implements active-castingconcept.
In-Reply-To: <Pine.LNX.4.10.10001200110290.6194-100000@us2.mayo.edu>
References: <14470.45218.362848.247846@vleet.chem.uu.nl>
<Pine.LNX.4.10.10001200110290.6194-100000@us2.mayo.edu>
Message-ID: <14470.54357.484569.958626@vleet.chem.uu.nl>
>>>>> "TO" == Travis Oliphant <Oliphant.Travis@mayo.edu> writes:
>> I am using some functions that use 2 arrays: a small one, used
>> repeatedly and a big one that changes on every invocation. If the
>> small array is passive-d and the big one is active-f, this will
>> cast the small one to 'f' on every invocation. Without the
>> active/passive patch, I'd find out about this inefficiency because
>> the result would be of type 'd'. Would there be any way of warning
>> the programmer for this kind of inefficient casting with the new
>> code?
TO> Let me see if I understand: You want to be able to catch that you
TO> are casting the passive array on every function call (presumably
TO> so you can change it and cast once)?
TO> Right now you have to check the output type, correct?
Right now I know I have a problem when the program slows down to 0 Kelvin.
Then I start looking for a d-array that makes everything go d.
TO> With the current changes in CVS, the result would be of type
TO> 'active-f' which is not the type of the small input array, so you
TO> could just check to make sure the types are the same. What am I
TO> missing?
You're speaking about the program checking, I used to detect the
problems using "wall-clock-profiling".
TO> Another person wanted two "active" arrays of different types to
TO> raise an exception, so with that change you would make both
TO> arrays active and if they were not the same type an error would
TO> occur. What do you think?
That would be one way to do it, but most tricks require me to think
whenever I use a new array, and if I am thinking, I can just as well
add ",'f'" to the instantiation in the first place..... I'm trying
to catch thinkos.
Dumb alternative suggestions:
- active=-1 means complain if you need to down-cast another array
(i.e. non-scalar).
- in some sort of debugging mode, keep a count of the number of times
each array is down-casted, and raise InefficientCode("Frequent
down-cast") if this happens often.
Don't get me wrong here: I really think your code is a great improvement,
and the point I'm raising is really of secondary importance (even to me).
Rob
--
===== rob@hooft.net http://www.xs4all.nl/~hooft/rob/ =====
===== R&D, Nonius BV, Delft http://www.nonius.nl/ =====
===== PGPid 0xFA19277D ========================== Use Linux! =========
From rlw@stsci.edu Thu Jan 20 15:26:34 2000
From: rlw@stsci.edu (Rick White)
Date: Thu, 20 Jan 2000 10:26:34 -0500 (EST)
Subject: [Matrix-SIG] Space-saving arrays and authoring tools.
Message-ID: <200001201526.KAA12848@sundog.stsci.edu>
Travis Oliphant writes:
>Currently, the behavior if two spacesaving arrays are found in an
>operation is to cast to the largest precision spacesaving array. However,
>when a similar proposal was made several months ago by Michael Hudson,
>several people said that it would be better to throw an exception under
>such circumstances. I would like more opinions on this. I haven't had
>enough experience to decide which is better, but I'm leaning towards the
>throwing-the-exception option.
My 2-cents worth: *please* don't make raising an exception the only
behavior. The standard promotion rules (within the savespace
hierarchy) will be useful for most applications for the same reason
they are useful for normal scalar expressions. And for dynamically
typed languages like Python, it just does not make sense to me to start
throwing exceptions when the types disagree.
In our applications (image processing) we use a variety of types (1, 2,
& 4-byte integers, single & double precision floats). A typical
operation is to start with raw data from a detector in an integer
format and to divide it by the detector's 'flat-field' response to
correct for sensitivity variations. The image gets converted to
floating-point in the process. If the Numeric code is raising
exceptions for mixed type expressions, I'm going to be forced to write
very ugly-looking code to test myself for the types of the input
quantities and explicitly promote them to the right output types. Then
I'll lose many of the advantages of having dynamically typed
variables.
Personally I'd be happy if the only behavior was Travis's original
version that promotes within the savespace hierarchy. But if some
people really want the exception-throwing behavior then I think Rob
Hooft's proposal of allowing savespace=-1 sounds like a possible
solution. That sufficiently complicates the behavior that I'd do
without it if it were up to me.
Rick
---
Richard L. White rlw@stsci.edu http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD
From vanandel@ucar.edu Thu Jan 20 16:30:20 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Thu, 20 Jan 2000 09:30:20 -0700
Subject: [Matrix-SIG] patch to arrayfnsmodule.c
Message-ID: <3887381C.EB0DAADA@atd.ucar.edu>
This is a multi-part message in MIME format.
--------------F0B944AE7954161E2C4B63D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've attached a patch to LLNL/Graphics/Arrayfcns/Src/arrayfnsmodule.c
that
1) Allows interp() to operate on multi-dimensional arrays
2) Provides interpf(), to return a single precision array
Could someone apply this patch to the standard LLNL distribution?
Thanks much.
--
Joe VanAndel
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
--------------F0B944AE7954161E2C4B63D6
Content-Type: text/plain; charset=us-ascii;
name="arrayfnsmodule.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="arrayfnsmodule.diff"
*** arrayfnsmodule.c 1999/04/14 22:58:32 1.1
--- arrayfnsmodule.c 1999/08/12 23:27:28
***************
*** 6,11 ****
--- 6,13 ----
#include <stdio.h>
#include <stdlib.h>
+ #define MAX_INTERP_DIMS 6
+
static PyObject *ErrorObject;
/* Define 2 macros for error handling:
***************
*** 34,39 ****
--- 36,43 ----
#define A_DIM(a,i) (((PyArrayObject *)a)->dimensions[i])
#define GET_ARR(ap,op,type,dim) \
Py_Try(ap=(PyArrayObject *)PyArray_ContiguousFromObject(op,type,dim,dim))
+ #define GET_ARR2(ap,op,type,min,max) \
+ Py_Try(ap=(PyArrayObject *)PyArray_ContiguousFromObject(op,type,min,max))
#define ERRSS(s) ((PyObject *)(PyErr_SetString(ErrorObject,s),0))
#define SETERR(s) if(!PyErr_Occurred()) ERRSS(errstr ? errstr : s)
#define DECREF_AND_ZERO(p) do{Py_XDECREF(p);p=0;}while(0)
***************
*** 571,576 ****
--- 575,613 ----
return result ;
}
+ static int
+ binary_searchf(float dval, float dlist [], int len)
+ {
+ /* binary_search accepts three arguments: a numeric value and
+ * a numeric array and its length. It assumes that the array is sorted in
+ * increasing order. It returns the index of the array's
+ * largest element which is <= the value. It will return -1 if
+ * the value is less than the least element of the array. */
+ /* self is not used */
+ int bottom , top , middle, result;
+
+ if (dval < dlist [0])
+ result = -1 ;
+ else {
+ bottom = 0;
+ top = len - 1;
+ while (bottom < top) {
+ middle = (top + bottom) / 2 ;
+ if (dlist [middle] < dval)
+ bottom = middle + 1 ;
+ else if (dlist [middle] > dval)
+ top = middle - 1 ;
+ else
+ return middle ;
+ }
+ if (dlist [bottom] > dval)
+ result = bottom - 1 ;
+ else
+ result = bottom ;
+ }
+
+ return result ;
+ }
static char arr_interp__doc__[] =
""
;
***************
*** 597,609 ****
Py_DECREF(ay);
Py_DECREF(ax);
return NULL ;}
! GET_ARR(az,oz,PyArray_DOUBLE,1);
lenz = A_SIZE (az);
dy = (double *) A_DATA (ay);
dx = (double *) A_DATA (ax);
dz = (double *) A_DATA (az);
! Py_Try (_interp = (PyArrayObject *) PyArray_FromDims (1, &lenz,
! PyArray_DOUBLE));
dres = (double *) A_DATA (_interp) ;
slopes = (double *) malloc ( (leny - 1) * sizeof (double)) ;
for (i = 0 ; i < leny - 1; i++) {
--- 634,647 ----
Py_DECREF(ay);
Py_DECREF(ax);
return NULL ;}
! GET_ARR2(az,oz,PyArray_DOUBLE,1,MAX_INTERP_DIMS);
lenz = A_SIZE (az);
dy = (double *) A_DATA (ay);
dx = (double *) A_DATA (ax);
dz = (double *) A_DATA (az);
! /* create output array with same size as 'Z' input array */
! Py_Try (_interp = (PyArrayObject *) PyArray_FromDims
! (A_NDIM(az), az->dimensions, PyArray_DOUBLE));
dres = (double *) A_DATA (_interp) ;
slopes = (double *) malloc ( (leny - 1) * sizeof (double)) ;
for (i = 0 ; i < leny - 1; i++) {
***************
*** 627,632 ****
--- 665,724 ----
return PyArray_Return (_interp);
}
+ /* return float, rather than double */
+
+ static PyObject *
+ arr_interpf(PyObject *self, PyObject *args)
+ {
+ /* interp (y, x, z) treats (x, y) as a piecewise linear function
+ * whose value is y [0] for x < x [0] and y [len (y) -1] for x >
+ * x [len (y) -1]. An array of floats the same length as z is
+ * returned, whose values are ordinates for the corresponding z
+ * abscissae interpolated into the piecewise linear function. */
+ /* self is not used */
+ PyObject * oy, * ox, * oz ;
+ PyArrayObject * ay, * ax, * az , * _interp;
+ float * dy, * dx, * dz , * dres, * slopes;
+ int leny, lenz, i, left ;
+
+ Py_Try(PyArg_ParseTuple(args, "OOO", &oy, &ox, &oz));
+ GET_ARR(ay,oy,PyArray_FLOAT,1);
+ GET_ARR(ax,ox,PyArray_FLOAT,1);
+ if ( (leny = A_SIZE (ay)) != A_SIZE (ax)) {
+ SETERR ("interp: x and y are not the same length.");
+ Py_DECREF(ay);
+ Py_DECREF(ax);
+ return NULL ;}
+ GET_ARR2(az,oz,PyArray_FLOAT,1,MAX_INTERP_DIMS);
+ lenz = A_SIZE (az);
+ dy = (float *) A_DATA (ay);
+ dx = (float *) A_DATA (ax);
+ dz = (float *) A_DATA (az);
+ /* create output array with same size as 'Z' input array */
+ Py_Try (_interp = (PyArrayObject *) PyArray_FromDims
+ (A_NDIM(az), az->dimensions, PyArray_FLOAT));
+ dres = (float *) A_DATA (_interp) ;
+ slopes = (float *) malloc ( (leny - 1) * sizeof (float)) ;
+ for (i = 0 ; i < leny - 1; i++) {
+ slopes [i] = (dy [i + 1] - dy [i]) / (dx [i + 1] - dx [i]) ;
+ }
+ for ( i = 0 ; i < lenz ; i ++ )
+ {
+ left = binary_searchf (dz [i], dx, leny) ;
+ if (left < 0)
+ dres [i] = dy [0] ;
+ else if (left >= leny - 1)
+ dres [i] = dy [leny - 1] ;
+ else
+ dres [i] = slopes [left] * (dz [i] - dx [left]) + dy [left];
+ }
+
+ free (slopes);
+ Py_DECREF(ay);
+ Py_DECREF(ax);
+ Py_DECREF(az);
+ return PyArray_Return (_interp);
+ }
static int incr_slot_ (float x, double *bins, int lbins)
{
int i ;
***************
*** 1295,1300 ****
--- 1387,1393 ----
{"array_set", arr_array_set, 1, arr_array_set__doc__},
{"index_sort", arr_index_sort, 1, arr_index_sort__doc__},
{"interp", arr_interp, 1, arr_interp__doc__},
+ {"interpf", arr_interpf, 1, arr_interp__doc__},
{"digitize", arr_digitize, 1, arr_digitize__doc__},
{"zmin_zmax", arr_zmin_zmax, 1, arr_zmin_zmax__doc__},
{"reverse", arr_reverse, 1, arr_reverse__doc__},
--------------F0B944AE7954161E2C4B63D6--
From dubois1@llnl.gov Thu Jan 20 16:46:36 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Thu, 20 Jan 2000 08:46:36 -0800
Subject: [Matrix-SIG] RE: patch to arrayfnsmodule.c
In-Reply-To: <3887381C.EB0DAADA@atd.ucar.edu>
Message-ID: <NDBBIEFMILBFPMDHJIMFCEPPCBAA.dubois1@llnl.gov>
I'll do it.
Paul
-----Original Message-----
From: vanandel@atd.ucar.edu [mailto:vanandel@atd.ucar.edu]
Sent: Thursday, January 20, 2000 8:30 AM
To: dubois1@llnl.gov
Cc: matrix-sig@python.org
Subject: patch to arrayfnsmodule.c
I've attached a patch to LLNL/Graphics/Arrayfcns/Src/arrayfnsmodule.c
that
1) Allows interp() to operate on multi-dimensional arrays
2) Provides interpf(), to return a single precision array
Could someone apply this patch to the standard LLNL distribution?
Thanks much.
--
Joe VanAndel
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
From mwh21@cam.ac.uk Thu Jan 20 17:09:47 2000
From: mwh21@cam.ac.uk (Michael Hudson)
Date: 20 Jan 2000 17:09:47 +0000
Subject: [Matrix-SIG] Space-saving arrays and authoring tools.
In-Reply-To: Travis Oliphant's message of "Thu, 20 Jan 2000 01:08:32 -0600 (CST)"
References: <Pine.LNX.4.10.10001200030300.6194-100000@us2.mayo.edu>
Message-ID: <m3snzssm90.fsf@atrus.jesus.cam.ac.uk>
Travis Oliphant <Oliphant.Travis@mayo.edu> writes:
> Currently, the behavior if two spacesaving arrays are found in an
> operation is to cast to the largest precision spacesaving array. However,
> when a similar proposal was made several months ago by Michael Hudson,
I don't *think* that was me. I'd be perfectly willing to accept
evidence to the contrary, but if it was I've forgotten it.
not-that-I-mind-taking-the-credit-ly y'rs
Michael
> several people said that it would be better to throw an exception under
> such circumstances. I would like more opinions on this. I haven't had
> enough experience to decide which is better, but I'm leaning towards the
> throwing-the-exception option.
From Oliphant.Travis@mayo.edu Thu Jan 20 17:57:53 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Thu, 20 Jan 2000 11:57:53 -0600 (CST)
Subject: [Matrix-SIG] Credit where credit is due.
Message-ID: <Pine.LNX.4.10.10001201150030.6874-100000@us2.mayo.edu>
I apologize to Scott Ransom and Michael Haggerty for incorrectly citing
Michael Hudson as originator of the idea for an attribute that causes no
upcasting.
I went back and reviewed the discussion on this list of June and July last
year and saw that it was really the conversation between Scott Ransom, Tim
Hochberg, Rick White, and Michael Haggerty that produced the idea of a
typecode attribute to help in the upcasting problem. Their idea is
essentially what was implemented.
I also saw that the disagreement about how to handle the case of two
arrays with this property was also present in the discussion :-)
--Travis
From taylor@rhino.llnl.gov Thu Jan 20 18:58:44 2000
From: taylor@rhino.llnl.gov (Lee Taylor)
Date: Thu, 20 Jan 2000 10:58:44 -0800 (PST)
Subject: [Matrix-SIG] Build problem under Solaris 2.6
In-Reply-To: <38863B52.B0B12747@sarnoff.com>
Message-ID: <Pine.GSO.3.96.1000120105351.9507A-100000@rhino.llnl.gov>
Make sure you're using the new version of arrayobject.h.
It is now in directory Numeric instead of numeric.
I usually use:
#include "Numeric/arrayobject.h"
instead of:
#include "arrayobject.h"
and then use -I$(prefix)/include/python1.5/Numeric on the compile line.
Lee Taylor
ltaylor@llnl.gov
On Wed, 19 Jan 2000, Clay Spence x3039 wrote:
> Hi,
>
> I'm having a problem building release 14 under Solaris 2.6 with Sun's C
> compiler. The following occurs:
>
> cholla 332% python setup.py build install
> running build
> <snip>
> Src/_numpymodule.c:
> "Src/_numpymodule.c", line 48: undefined symbol:
> PyArray_FromDimsAndDataAndDescr_NUM
> "Src/_numpymodule.c", line 48: undefined symbol:
> PyArray_FromDimsAndDataAndDescr
> cc: acomp failed for Src/_numpymodule.c
>
> It does not seem to be a limitation on preprocessor symbol names. I can
> define PyArray_FromDimsAndDataAndDescr_NUM myself in a very short test
> program and it compiles with no problem. However, the following file
> gives the same error:
>
> -----------
> #include <stdio.h>
> #include "Python.h"
> #define _ARRAY_MODULE
> #include "arrayobject.h"
>
> int
> main()
> {
> printf("%d\n", PyArray_Type_NUM);
> printf("%d\n", PyArray_FromDimsAndDataAndDescr_NUM);
> return 0;
> }
> -----------
>
> It doesn't complain about PyArray_Type_NUM. The presence or absence of
> "#define _ARRAY_MODULE" doesn't affect the error. Older versions (I
> think 11 was the last I tried) compiled fine. Any ideas?
>
> Thanks,
> Clay
>
>
>
> _______________________________________________
> Matrix-SIG maillist - Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
>
From perry_stoll@yahoo.com Thu Jan 20 19:02:59 2000
From: perry_stoll@yahoo.com (Perry Stoll)
Date: Thu, 20 Jan 2000 11:02:59 -0800 (PST)
Subject: [Matrix-SIG] Credit where credit is due.
Message-ID: <20000120190259.6512.qmail@web705.mail.yahoo.com>
Well, just for historical accuracy ;), check out the
thread starting here for more on this topic:
http://www.python.org/pipermail/matrix-sig/1996-January/003421.html
-Perry
--- Travis Oliphant <Oliphant.Travis@mayo.edu> wrote:
>
> I apologize to Scott Ransom and Michael Haggerty for
> incorrectly citing
> Michael Hudson as originator of the idea for an
> attribute that causes no
> upcasting.
>
> I went back and reviewed the discussion on this list
> of June and July last
> year and saw that it was really the conversation
> between Scott Ransom, Tim
> Hochberg, Rick White, and Michael Haggerty that
> produced the idea of a
> typecode attribute to help in the upcasting problem.
> Their idea is
> essentially what was implemented.
>
> I also saw that the disagreement about how to handle
> the case of two
> arrays with this property was also present in the
> discussion :-)
>
> --Travis
>
>
>
> _______________________________________________
> Matrix-SIG maillist - Matrix-SIG@python.org
> http://www.python.org/mailman/listinfo/matrix-sig
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From cspence@sarnoff.com Thu Jan 20 19:04:05 2000
From: cspence@sarnoff.com (Clay Spence x3039)
Date: Thu, 20 Jan 2000 14:04:05 -0500
Subject: [Matrix-SIG] Re: Build problem under Solaris 2.6
References: <20000120003154.494041CF71@dinsdale.python.org>
Message-ID: <38875C25.30C4F12E@sarnoff.com>
I wrote:
> I'm having a problem building release 14 under Solaris 2.6 with Sun's C
> compiler. The following occurs:
>
> cholla 332% python setup.py build install
> running build
> <snip>
> Src/_numpymodule.c:
> "Src/_numpymodule.c", line 48: undefined symbol:
> PyArray_FromDimsAndDataAndDescr_NUM
> "Src/_numpymodule.c", line 48: undefined symbol:
> PyArray_FromDimsAndDataAndDescr
> cc: acomp failed for Src/_numpymodule.c
and more stuff. Travis Oliphant suggested the solution: The compiler was finding the header file arrayobject.h from my
installation of an older version, because the python include directory appears first in the sequence of -I's. Deleting
the old arrayobject.h (which was a link anyway) fixed the problem.
I'll leave it to others to decide whether something about the distribution should be changed to handle this situation.
(Or maybe I didn't read the installation instructions carefully enough?)
Clay
From cgw@fnal.gov Thu Jan 20 19:59:13 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Thu, 20 Jan 2000 13:59:13 -0600 (CST)
Subject: [Matrix-SIG] More fixes for type 'O' arrays
Message-ID: <14471.26897.390486.756553@buffalo.fnal.gov>
The bug:
Python 1.5.2+ (#7, Jan 13 2000, 16:18:27) [GCC 2.95.2 19991024 (release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from Numeric import *
>>> x=array(['a','b','c'],'O')
>>> y=array(['d','e','f'],'O')
>>> dot(x,y)
Segmentation fault
The fix: (the patch to multiarraymodule is the real fix, the patch to
Numeric.py is just to give a more meaningful message with the exception)
Index: Lib/Numeric.py
===================================================================
RCS file: /cvsroot/numpy/Numerical/Lib/Numeric.py,v
retrieving revision 1.7
diff -u -r1.7 Numeric.py
--- Lib/Numeric.py 2000/01/19 23:13:41 1.7
+++ Lib/Numeric.py 2000/01/20 19:56:38
@@ -212,11 +212,11 @@
"""
try:
return multiarray.innerproduct(a,b)
- except(TypeError):
+ except TypeError,detail:
if array(a).shape == () or array(b).shape == ():
return a*b
else:
- raise TypeError, "invalid types for dot"
+ raise TypeError, detail or "invalid types for dot"
def dot(a, b):
"""dot(a,b) returns matrix-multiplication between a and b. The product-sum
Index: Src/multiarraymodule.c
===================================================================
RCS file: /cvsroot/numpy/Numerical/Src/multiarraymodule.c,v
retrieving revision 1.5
diff -u -r1.5 multiarraymodule.c
--- Src/multiarraymodule.c 2000/01/19 23:13:41 1.5
+++ Src/multiarraymodule.c 2000/01/20 19:56:39
@@ -574,10 +574,14 @@
PyObject *tmp1, *tmp2, *tmp;
for(i=0;i<n;i++,ip1+=is1,ip2+=is2) {
tmp1 = PyNumber_Multiply(*((PyObject **)ip1), *((PyObject **)ip2));
+ if (!tmp1)
+ return;
if (i == 0) {
tmp = tmp1;
} else {
tmp2 = PyNumber_Add(tmp, tmp1);
+ if (!tmp2)
+ return;
Py_XDECREF(tmp);
tmp = tmp2;
Py_XDECREF(tmp1);
From hinsen@dirac.cnrs-orleans.fr Fri Jan 21 15:40:55 2000
From: hinsen@dirac.cnrs-orleans.fr (hinsen@dirac.cnrs-orleans.fr)
Date: Fri, 21 Jan 2000 16:40:55 +0100
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
In-Reply-To: <00011915515100.00571@almanac> (dubois1@llnl.gov)
References: <200001192327.SAA15242@python.org> <00011915515100.00571@almanac>
Message-ID: <200001211540.QAA12735@chinon.cnrs-orleans.fr>
> searching by bisection for the errors. Latex in particular suffered from
> non-portability between authors who had slightly different installations, as
> someone else mentioned.
I remember such problems from the early days of LaTeX, but since LaTeX
2e has become the standard, and since everyone uses one out a small
number of standard distributions, they have disappeared. The remaining
problem to watch out for in collaborative work is personal macros; one
solution is to require personal macros to begin with the initials of
the author.
LaTeX seems the only documentation system at the moment that is free
and open. Yes, it is sometimes difficult to solve some LaTeX problem,
but it is always possible because you have all the sources. With any
proprietary system, you sooner or later reach a point where you just
can't go on because you'd have to fix the program, and can't.
DocBook is also open and free, including some tools to work on it, but
also extremely complicated, and the amount of markup for a typical
text is sufficient to make typing extremely unpleasant with a standard
text editor, even if it is Emacs with SGML support. I used DocBook for
the ScientificPython and MMTK manuals, and I would most definitely not
make that choice again. I ended up modifying the original DTD because
there was no decent markup for documenting Python, and then I wrote
my own translators to HTML and LaTeX because this seemed much simpler
than understanding DSSSL and debugging JadeTeX.
Another option is to develop a special (and simple) DTD for Python
documentation and write translators to other formats (in Python,
of course). This would make sense if the whole Python community
were interested in such a development.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
From pauldubois@home.com Fri Jan 21 17:18:45 2000
From: pauldubois@home.com (Paul F. Dubois)
Date: Fri, 21 Jan 2000 09:18:45 -0800
Subject: [Matrix-SIG] Note on using IE on Numerical Python website
Message-ID: <NDBBIEFMILBFPMDHJIMFKEBBCCAA.pauldubois@home.com>
I have reported the following bug to SourceForge -- when you use Internet
Explorer (or at least IE5) on the site, in SSL logged-in mode, there are a
lot of failures when you change pages. However, a "refresh" at that point
will usually succeed. There was a follow up indicating they are aware of it.
From amullhau@zen-pharaohs.com Fri Jan 21 18:29:50 2000
From: amullhau@zen-pharaohs.com (Andrew P. Mullhaupt)
Date: Fri, 21 Jan 2000 13:29:50 -0500
Subject: [Matrix-SIG] RE: Authoring tools (was Active arrays)
References: <003e01bf62c3$041f7b20$c355cfc0@ski.org>
Message-ID: <046301bf643d$82511dc0$5063cb0a@amullhau>
> > > Never tried DocBook.
>
> LaTeX allows people to define macros and makes writers think like
> programmers. Bad idea. =) Many many folks don't know LaTeX but would be
> able to pick up a WYSIWYG editor easily.
So use Scientific Word which produces LaTeX output but is basically a word
processor if you want that. You can essentially dial up how much LaTeX pain
you want to enjoy. I've written thousands of pages of LaTeX and I started
refusing to know TeX before there was LaTeX. TeX is ridiculous, of course,
what else would you expect from a guy who still wants his own assembler
language in that book?
> I refuse to use LaTeX. Can't even justify why, it's a gut reaction after
> writing too many papers, a several-hundred page dissertation with it,
> spending waaaayy too many hours debugging poorly written LaTeX macros,
> fussing with DVI, PS, EPS, bounding boxes, BibTeX, fussy installations,
> missing fonts, bad HTML conversion, etc.
Next time try Scientific Word.
Later,
Andrew Mullhaupt
From guido@CNRI.Reston.VA.US Fri Jan 21 19:01:08 2000
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 21 Jan 2000 14:01:08 -0500
Subject: [Matrix-SIG] Python Conference weather
Message-ID: <200001211901.OAA29501@eric.cnri.reston.va.us>
If you're traveling to the Python Conference, be advised that winter
has finally arrived in the Washington, DC area. We're currently
experiencing *high* temperatures of 22 degrees F (-6 degrees C); with
the wind chill it will feel much colder. So be sure to pack warm
clothes.
Yesterday, about 6 inches of snow fell, disrupting air travel; more is
expected on Sunday, so expect delays flying into DC. Local
transportation should be fully operational, but may experience some
delays.
We've placed a weather advisory in the local section of the conference
website:
http://www.python.org/workshops/2000-01/local.html
Over 250 people have registered for the conference. See you all there!
--Guido van Rossum (home page: http://www.python.org/~guido/)
From bryce.k.gardner@jpl.nasa.gov Fri Jan 21 19:24:55 2000
From: bryce.k.gardner@jpl.nasa.gov (Bryce Gardner)
Date: Fri, 21 Jan 2000 11:24:55 -0800
Subject: [Matrix-SIG] Active arrays
In-Reply-To: <38865799.188493B0@atd.ucar.edu>
References: <Pine.LNX.4.10.10001191112240.4605-100000@us2.mayo.edu>
<20000119235102.11212.qmail@lisboa.ifm.uni-kiel.de>
Message-ID: <4.1.20000121103552.00acfee0@mail1.jpl.nasa.gov>
>-- Then some names for this `active' thingy.
>
>>typed
>>keeptype
>>hold
>>holdtype
>
>How about 'promote', set to '0' if promotion to double is not wanted?
I was thinking 'dominant_type' because we want this type to attempt to
control the
final type of an expression. Something that lends the idea that this type
is intended
to control the type of the output.
Some other words could be overriding_type, prevailing_type, principal_type.
just my two-cents worth.
Bryce
From steriana@gvsu.edu Fri Jan 21 19:40:16 2000
From: steriana@gvsu.edu (Andrew Sterian)
Date: Fri, 21 Jan 2000 14:40:16 -0500
Subject: [Matrix-SIG] RE: (Matrix-SIG) Active arrays
In-Reply-To: <921810574@gvsu.edu>
Message-ID: <000401bf6447$583531c0$0a243d94@gvsu.edu>
> >-- Then some names for this `active' thingy.
> >
> >>typed
> >>keeptype
> >>hold
> >>holdtype
> >
> >How about 'promote', set to '0' if promotion to double is not wanted?
>
> I was thinking 'dominant_type' because we want this type to attempt to
> control the
> final type of an expression. Something that lends the idea
> that this type
> is intended
> to control the type of the output.
Given that we want this matrix to be dominant, it is a dominant matrix
so perhaps this attribute should be called 'dominatrix' :)
(Sorry...couldn't resist)
Andrew Sterian | <mailto:steriana@gvsu.edu>
Assistant Professor | <http://claymore.engineer.gvsu.edu/~steriana>
Padnos School of Engineering | (616) 771-6756
Grand Valley State University
From pearu@ioc.ee Tue Jan 25 14:53:37 2000
From: pearu@ioc.ee (Pearu Peterson)
Date: Tue, 25 Jan 2000 16:53:37 +0200
Subject: [Matrix-SIG] f2py 1.116: The Fortran to Python Interface Generator
Message-ID: <388DB8F1.F0E1F218@ioc.ee>
I am pleased to announce the first public release of f2py 1.116:
Writing Python C/API wrappers for Fortran routines can be a very
tedious task, especially if a Fortran routine takes more than 20
arguments but only few of them are relevant for the problems that they
solve.
The Fortran to Python Interface Generator, or FPIG for short, is a
command line tool (f2py) for generating Python C/API modules for
wrapping Fortran 77 routines, accessing common blocks from Python, and
calling Python functions from Fortran (call-backs).
The tool can be downloaded from
http://cens.ioc.ee/projects/f2py2e/
where you can find also information about f2py features and its User's
Guide.
f2py is released under the LGPL license.
With regards,
Pearu Peterson <pearu@ioc.ee>
<P><A HREF="http://cens.ioc.ee/projects/f2py2e/">f2py 1.116</A> - The
Fortran to Python Interface Generator (25-Jan-00)
From pearu@ioc.ee Wed Jan 26 11:04:54 2000
From: pearu@ioc.ee (Pearu Peterson)
Date: Wed, 26 Jan 2000 13:04:54 +0200 (EET)
Subject: [Matrix-SIG] Re: regarding f2py
In-Reply-To: <388E2334.30065BB6@first.gmd.de>
Message-ID: <Pine.HPX.4.05.10001261155470.21306-100000@egoist.ioc.ee>
On Tue, 25 Jan 2000, Thilo Ernst wrote:
> Dear Pearu,
>=20
> in search for useful tools for my new project, which involves integrating
> scientific-computing (largely Fortran)
> codes via Python, I saw your f2py announcement & web page. I find f2py v=
ery
> interesting, I only have one
> problem. As you are using Python and NumPy, you are certainly aware of Pa=
ul
> Dubois=B4 PyFort tool which seems
> to be quite related to your work. OTOH, there seem to be important
> differences: E.g. I didn=B4t notice support for
> Fortran->Python callbacks when scanning the PyFort docs (superficially as=
of
> yet, I have to admit).
> This makes it difficult for me as a prospective "customer" of these two t=
ools
> to decide which to use.
> I think it would be very helpful if you as the author, and obviously a "d=
omain
> expert" could put some words
> of comparison on the f2py web page.=20
I think, Paul Dubois and me started to develop such a tool approximately
at the same time (summer 1999) but independently and having different
goals in mind.
My goal was to have tool that would scan large number of
fortran codes (in Netlib libraries such as
blas,lapack,minpack,odepack,etc) and produce raw wrappings of the Fortran
77 codes so that they could be called from Python in a similar way as you
would call them from C or Fortran.=20
Since many of these routines take `external' arguments, the
call-back mechanism was needed in the very early stage of the
development. Thanks to Travis Oliphant who implement the first call-back
mechanism for f2py.=20
During the development f2py has undergone three iterations, each has
be rewritten from scratch. By now it has reached to a quite stable stage.
Though, f2py has currently one shortcoming: using multi-dimensional arrays
is not very user-friendly --- the user must be aware of differences that
are how the multidimensional arrays are stored in Python/C (raw major
order) and in Fortran (column major order).
I think, Paul has found a more user-friendlier solution to this problem.
In fact, the next goal for f2py is to find a better solution to the
problem. That is to eliminate the differences between Python and Fortran
multi-D arrays in the wrapper level so that the user need not to know
about C/Fortran differences.
I hope that Paul is willing to give a nice comment on his tool. From the
documentation of Pyfort I find that his main goal is to wrap Fortran 95
codes to Python, in future.
> One more question: how did you construct the Fortran parser?
Well, I took XL Fortran 5.1 Language Reference Guide and by
following it carefully, implemented the fortran code "cracker" (see
crackfortran.py). The Python Regular Expression module re turned out to be =
=20
most useful for parsing fortran code lines. Note also that I was able to
produce such a parser partly because the syntax of Fortran 77/90/95=20
language is relatively simple (compared to C, for instance) and because
Python is such a nice language (that you all know anyway ;-)
Pearu=20
=20
From vanandel@ucar.edu Fri Jan 28 23:08:05 2000
From: vanandel@ucar.edu (Joe Van Andel)
Date: Fri, 28 Jan 2000 16:08:05 -0700
Subject: [Matrix-SIG] Space-saving arrays and authoring tools.
References: <Pine.LNX.4.10.10001200030300.6194-100000@us2.mayo.edu>
Message-ID: <38922155.3CCA14F8@atd.ucar.edu>
I've just tried the spacesaver option, and it seems to do just what I
want.
This is great, I'm very pleased I don't have to sprinkle functions in my
code to avoid up-casting.
For consistency and convenience, could the Numeric 'ones' and 'zeros'
functions accept a savespace argument, which defaults to 0?
Thanks much.
--
Joe VanAndel
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
From Oliphant.Travis@mayo.edu Sat Jan 29 00:01:16 2000
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Fri, 28 Jan 2000 18:01:16 -0600 (CST)
Subject: [Matrix-SIG] Space-saving arrays and authoring tools.
In-Reply-To: <38922155.3CCA14F8@atd.ucar.edu>
Message-ID: <Pine.LNX.4.10.10001281800150.4697-100000@us2.mayo.edu>
> I've just tried the spacesaver option, and it seems to do just what I
> want.
>
> This is great, I'm very pleased I don't have to sprinkle functions in my
> code to avoid up-casting.
>
>
> For consistency and convenience, could the Numeric 'ones' and 'zeros'
> functions accept a savespace argument, which defaults to 0?
>
> Thanks much.
This is a good idea. I'll put it on sourceforge soon.
Thanks for the feedback.
-Travis
From gpk@bell-labs.com Mon Jan 31 15:49:30 2000
From: gpk@bell-labs.com (Greg Kochanski)
Date: Mon, 31 Jan 2000 10:49:30 -0500
Subject: [Matrix-SIG] Zeros
References: <20000129170022.CF1A81CE60@dinsdale.python.org>
Message-ID: <3895AF0A.B9D9AF63@bell-labs.com>
Speaking of redefining Numeric.zeros(),
I've had the need to create an array
of Nones, then fill up some of the entries.
It would be reasonably nice if Numeric.zeros(size, Numeric.PyObject)
produced an array of Nones, rather than the current
behavior of producing an array of integer zero python objects.
After all, a 'zero' PyObject isn't well defined:
you could want a string ('0'), an int (0), a float (0.0),
or a complex (0+0j). How is the poor package supposed to
read your mind? Better if it produces an array of Nones.
Often, one intends Numeric.zeros() to make an 'empty' array,
and an array of Nones is as empty as one can get.
From dubois1@llnl.gov Mon Jan 31 16:06:30 2000
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Mon, 31 Jan 2000 08:06:30 -0800
Subject: [Matrix-SIG] Zeros
In-Reply-To: <3895AF0A.B9D9AF63@bell-labs.com>
Message-ID: <NDBBIEFMILBFPMDHJIMFAEFACCAA.dubois1@llnl.gov>
Your suggestion is not acceptable to me. I understand your reasoning but do
not agree with it.
I question seriously whether Numerical should have any support for
non-numeric types, actually. It causes serious complications for very little
real gain. There is an array object in the core that might suit your needs.
Also, the Python list type will do what you want perfectly well: [None] * n.
If you have an application where n is so large that storage is an issue it
would be surprising. And no, I don't accept the proposition that storage is
always an issue.
If you are only filling up "some" of the entries, it is clear you aren't
subsequently doing arithmetic on the arrays.
Best regards,
Paul
-----Original Message-----
From: matrix-sig-admin@python.org [mailto:matrix-sig-admin@python.org]On
Behalf Of Greg Kochanski
Sent: Monday, January 31, 2000 7:50 AM
To: matrix-sig@python.org
Subject: [Matrix-SIG] Zeros
Speaking of redefining Numeric.zeros(),
I've had the need to create an array
of Nones, then fill up some of the entries.
It would be reasonably nice if Numeric.zeros(size, Numeric.PyObject)
produced an array of Nones, rather than the current
behavior of producing an array of integer zero python objects.
After all, a 'zero' PyObject isn't well defined:
you could want a string ('0'), an int (0), a float (0.0),
or a complex (0+0j). How is the poor package supposed to
read your mind? Better if it produces an array of Nones.
Often, one intends Numeric.zeros() to make an 'empty' array,
and an array of Nones is as empty as one can get.
_______________________________________________
Matrix-SIG maillist - Matrix-SIG@python.org
http://www.python.org/mailman/listinfo/matrix-sig
From emmanuel.viennet@lipn.univ-paris13.fr Mon Jan 31 16:17:35 2000
From: emmanuel.viennet@lipn.univ-paris13.fr (Emmanuel Viennet)
Date: Mon, 31 Jan 2000 17:17:35 +0100
Subject: [Matrix-SIG] Zeros
References: <NDBBIEFMILBFPMDHJIMFAEFACCAA.dubois1@llnl.gov>
Message-ID: <3895B59F.D1F292AD@lipn.univ-paris13.fr>
Paul wrote:
> I question seriously whether Numerical should have any support for
> non-numeric types, actually. It causes serious complications for very little
> real gain. There is an array object in the core that might suit your needs.
>
But one could use multi-dimensional NumPy Object arrays just
to take advantage of the sophisticated indexing methods (like ...)
which are not available on standard lists.
I know that the Objet typecode is currently poorly supported
in NumPy, but it may make sense to use it.
Emmanuel
From gpk@bell-labs.com Mon Jan 31 16:49:45 2000
From: gpk@bell-labs.com (Greg Kochanski)
Date: Mon, 31 Jan 2000 11:49:45 -0500
Subject: [Matrix-SIG] Zeros
Message-ID: <3895BD29.D5EACB6F@bell-labs.com>
"Paul F. Dubois" wrote:
>
> I question seriously whether Numerical should have any support for
> non-numeric types, actually.
> It causes serious complications for very little
> real gain. There is an array object in the core that might suit your needs.
True enough. However, I use _Numeric_ instead of _array_, to reduce the
number
of modules that need to be imported. Personally, I see little
reason for the array module to continue to exist, given Numeric.
One characteristic of a good programming language is that it
minimizes the amount of stuff the programmer needs to memorize.
Why have two nearly equivalent array modules, and force people
to memorize the differences and special cases?
Programming is not just a case of MFLOPS and storage efficiency:
often development and maintenance time is the limiting factor,
which is why I'd rather bring in one module instead of two.
> Also, the Python list type will do what you want perfectly well: [None] * n.
> If you have an application where n is so large that storage is an issue it
> would be surprising.
The issue is not storage so much as having a uniform programming
interface.
From gpk@bell-labs.com Mon Jan 31 17:30:55 2000
From: gpk@bell-labs.com (Greg Kochanski)
Date: Mon, 31 Jan 2000 12:30:55 -0500
Subject: [Matrix-SIG] Bug in LinearAlgebra.linear_least_squares()
Message-ID: <3895C6CF.49659840@bell-labs.com>
The documentation string states:
If the rank of A is less than the number of columns of A
or greater than the numer of rows, then residuals will be
returned as an empty array otherwise resids = sum((b-dot(A,x)**2).
This is not quite correct.
One can have a fit that has a low rank,
(i.e., the basis functions are degenerate) that still
doesn't completely explain the data.
For instance, fitting the sequence [1.1, 2, 3, 4]
with basis functions [1, 2, 3, 4] and [0, 0, 0, 0]
will yield a rank of 1,
and ought to yield a nonzero residual.
Granted, LAPACK is the lazy one, failing to calculate
the residual,
and the LinearAlgebra module is just passing it on,
but the absence of the residual
ought to be fixed or at least noted as a bug in the
documentation.
>>>
>>> a
array([[ 1., 0.],
[ 2., 0.],
[ 3., 0.],
[ 4., 0.]])
>>> b
array([ 1.1, 2. , 3. , 4. ])
>>>
>>> LinearAlgebra.linear_least_squares(a, b)
(array([ 1.00333333, 0. ]),
zeros((0,), 'd'),
1,
array([ 5.47722558, 0. ]))
>>>
>>> Numeric.matrixmultiply(a, [ 1.00333333, 0. ])
array([ 1.00333333, 2.00666666, 3.00999999, 4.01333332])
>>> # Note that we don't quite recover the original sequence,
# so the residuals are nonzero.
From frohne@gci.net Mon Jan 31 17:57:28 2000
From: frohne@gci.net (Ivan Frohne)
Date: Mon, 31 Jan 2000 08:57:28 -0900
Subject: [Matrix-SIG] Zeros
In-Reply-To: <3895BD29.D5EACB6F@bell-labs.com>
Message-ID: <4.3.0.33.0.20000131085225.00a78550@mail.gci.net>
At 07:49 31-01-00 , Greg Kochanski wrote:
> Personally, I see little
>reason for the array module to continue to exist, given Numeric.
Whoa now! Hands off the array module. For single dimension calculations,
(which is all they're good for, I know), Python arrays are significantly
faster than Numeric arrays. Sometimes it's faster to convert a Numeric
array to a Python array before processing it.
--Ivan
Frohne
From cgw@fnal.gov Mon Jan 31 19:00:32 2000
From: cgw@fnal.gov (Charles G Waldman)
Date: Mon, 31 Jan 2000 13:00:32 -0600 (CST)
Subject: [Matrix-SIG] Zeros
In-Reply-To: <NDBBIEFMILBFPMDHJIMFAEFACCAA.dubois1@llnl.gov>
References: <3895AF0A.B9D9AF63@bell-labs.com>
<NDBBIEFMILBFPMDHJIMFAEFACCAA.dubois1@llnl.gov>
Message-ID: <14485.56272.978010.825744@buffalo.fnal.gov>
Paul F. Dubois writes:
> I question seriously whether Numerical should have any support for
> non-numeric types, actually. It causes serious complications for very little
> real gain. There is an array object in the core that might suit your needs.
I would like to see even more support for non-numeric types, for the
following reason: I could use the same NumPy code to approach problems
from either a symbolic and a numerical approach. E.g. I would like to
create a symbolic "Polynomial" class, populate a matrix with these
objects, then call some Numeric functions to perform symbolic algebra.
Then when I'm happy with that, I can plug in numeric values and have a
fast number-crunching engine.
For instance:
>>> from Numeric import *
>>> from LinearAlgebra import determinant
>>> det=determinant
>>> class Poly:
... def __init__(self,val):
... self.val=val
... def __add__(self,other):
... return Poly("%s+%s"%(self.val,other.val))
... def __mul__(self,other):
... return Poly("%s*%s"%(self.val,other.val))
... def __repr__(self):
... return self.val
... def __str__(self):
... return self.val
...
>>> a,b,c,d=map(Poly,'abcd')
>>> a
a
>>> a+b
a+b
>>> m=array([a,b,c,d],'O')
>>> m.shape=2,2
>>> m
array([[a , b ],
[c , d ]],'O')
>>> m*m
array([[a*a , b*b ],
[c*c , d*d ]],'O')
>>> m2=array([w,x,y,z],'O')
>>> m2.shape=2,2
>>> dot(m,m2)
array([[a*w+b*y , a*x+b*z ],
[c*w+d*y , c*x+d*z ]],'O')
This, IMO, is a great way to test code and see that your matrix
calculations are actually doing what you want them to. Seems to me
like the combination of unlimited Python dynamism and speed when you
need it, is something really unique to NumPy.... the possibility that
you could create arrays of rational numbers, or elements of a finite
field, etc, and compute with those is something I'd not like to see go
away.
Unfortunately, as has been pointed out many times,
the support for type 'O' arrays is not uniform:
>>> det(m)
Traceback (innermost last):
File "<stdin>", line 1, in ?
File "/usr/lib/python1.5/site-packages/Numeric/LinearAlgebra.py", line 228, in determinant
t =_commonType(a)
File "/usr/lib/python1.5/site-packages/Numeric/LinearAlgebra.py", line 27, in _commonType
kind = max(kind, _array_kind[t])
KeyError: O
I think the solution to this is not to eliminate type 'O' but to do
some work to make it work better.
Of course I realize whom the burden of such work rests upon...