From guido@CNRI.Reston.Va.US  Tue Apr  1 03:23:50 1997
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Mon, 31 Mar 1997 22:23:50 -0500
Subject: [PYTHON MATRIX-SIG] Re: Conversion
In-Reply-To: Your message of "Mon, 31 Mar 1997 15:02:08 EST."
 <01BC3DE4.81E4BAE0@misha.lcs.mit.edu>
References: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu>
Message-ID: <199704010323.WAA05513@monty>

> Guido writes:
> ...
> > > Looking at the source, I see that complex numbers have a 3rd
> > > data attribute, "conj", which returns the same as the .conjugate()
> > > method. I don't like this very much (because there's already the
> > > method, and because it really isn't a "component" of the complex
> > > number like its real and imag components are) but am afraid to
> > > remove it out of fear of breaking anything.  Am I overly worried?

Tim Peters replies:

> > I'll yield to Jim & the Matrix folks on that -- I didn't know even know 
> > .conj existed, and agree that "it shouldn't".

Jum Hugunin:

> In my opinion, .conj shouldn't exist.  I tried to get Konrad to take it out 
> at some early point in the development of complexobject.c.  I wouldn't 
> worry about breaking anything, but I'm cross-posting to the matrix-sig to 
> give others a chance to shout if you'll be breaking their code.

OK, I'll take .conj out unless I hear from you again.

> Note: for NumPy arrays there is neither a ".conj" attribute nor a 
> ".conjugate()" method.  Instead there is a "conjugate(a)" function which 
> will work on any number-like python object in the right manner.  There 
> seemed to be agreement within the SIG that this function is what everybody 
> really wanted anyway.

I have a feeling that for orthogonality, conjugate() should have to be
a built-in function (like abs()); and that there should be some other
built-in function (angle()?) that returns ``the other polar
coordinate'' so that (abs(z), angle(z)) are an alternate
representation of z.  But you can tell that I'm not a complex number
expert :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From furnish@laura.llnl.gov  Tue Apr  1 18:02:13 1997
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Tue, 1 Apr 1997 10:02:13 -0800
Subject: [PYTHON MATRIX-SIG] Re: Conversion
In-Reply-To: <199704010323.WAA05513@monty>
References: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu>
 <199704010323.WAA05513@monty>
Message-ID: <199704011805.NAA29716@python.org>

Guido van Rossum writes:
 > I have a feeling that for orthogonality, conjugate() should have to be
 > a built-in function (like abs()); and that there should be some other
 > built-in function (angle()?) that returns ``the other polar
 > coordinate'' so that (abs(z), angle(z)) are an alternate
 > representation of z.  But you can tell that I'm not a complex number
 > expert :-)

That should be "arg(z)", I think.

-- 
Geoffrey Furnish		email: furnish@llnl.gov
LLNL X/ICF			phone: 510-424-4227	fax: 510-423-0925

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From amullhau@ix.netcom  Tue Apr  1 20:24:49 1997
From: amullhau@ix.netcom (Andrew P. Mullhaupt)
Date: Tue, 01 Apr 1997 15:24:49 -0500
Subject: [PYTHON MATRIX-SIG] Re: Conversion
References: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu> <199704010323.WAA05513@monty>
Message-ID: <33416F11.16B7@ix.netcom.com>

Guido van Rossum wrote:
> 
> I have a feeling that for orthogonality, conjugate() should have to be
> a built-in function (like abs()); and that there should be some other
> built-in function (angle()?) that returns ``the other polar
> coordinate'' so that (abs(z), angle(z)) are an alternate
> representation of z.  But you can tell that I'm not a complex number
> expert :-)

You want to do several things about complex numbers, and many are
already being done.

You want to be able to extract the real and imaginary parts, and
good names for these functions are Re and Im.

You want to be able to obtain the complex conjugate, and a good name for
that function is conjugate, or perhaps co. Of course, the best way to
get this is to use * as a postfix operator for adjunction (which
specializes to complex conjugation on scalars) but this presumes using
juxtaposition for matrix (and thereby ordinary) multiplication, which is
unavailable in Python, so conjugate is probably the way to go. I'm
assuming that people who really use conjugate a lot will use stuff like

    co = conjugate

to localize the function and make their code more readable.

You want to be able to extract the modulus and the argument, and good
names for these functions are mod and arg. People frequently call the
modulus of a real number it's 'absolute value' - and that's OK since the
absolute value in the real field coincides with the complex modulus.
There are technical reasons why modulus is mathematically more appealing
than absolute value, but lots of people already think in terms of
absolute value so you probably can't clean that up, especially since
modulus also refers to remainders and fractional parts.

There is a forlorn hope that one can change the highly objectionable use
of 'j' to denote the chosen imaginary unit. The use of 'i' is much more
standard. Some Electrjcal engjneers found that they had to reserve 'i'
to represent electrical current, and relegated the chosen imaginary unit
to the letter 'j'. There is no other reason for this breach with long
established tradition, and it appears that that reason has lapsed. One
can even use the symbol 'i' for the chosen imaginary unit in the IEEE
_Transactions on Signal Processing_ without raising an eyebrow.

Later,
Andrew Mullhaupt

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From guido@CNRI.Reston.Va.US  Tue Apr  1 22:24:04 1997
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Tue, 01 Apr 1997 17:24:04 -0500
Subject: [PYTHON MATRIX-SIG] Re: Conversion
In-Reply-To: Your message of "Tue, 01 Apr 1997 15:24:49 EST."
 <33416F11.16B7@ix.netcom.com>
References: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu> <199704010323.WAA05513@monty>
 <33416F11.16B7@ix.netcom.com>
Message-ID: <199704012224.RAA11178@monty>

> You want to do several things about complex numbers, and many are
> already being done.

Yes.  I didn't design the complex number interface though, and now I'm
asking if it should be improved a bit.

> You want to be able to extract the real and imaginary parts, and
> good names for these functions are Re and Im.

You write this as z.real, z.imag.

> You want to be able to obtain the complex conjugate, and a good name for
> that function is conjugate, or perhaps co. Of course, the best way to
> get this is to use * as a postfix operator for adjunction (which
> specializes to complex conjugation on scalars) but this presumes using
> juxtaposition for matrix (and thereby ordinary) multiplication, which is
> unavailable in Python, so conjugate is probably the way to go. I'm
> assuming that people who really use conjugate a lot will use stuff like
> 
>     co = conjugate
> 
> to localize the function and make their code more readable.

It's currently a method: z.conjugate().  You could of course write

	def co(z): return z.conjugate()

but it would run much slower.  I am thinking to propose to make
conjugate() a built-in function (it could return its argument
unchanged for non-complex numbers).

> You want to be able to extract the modulus and the argument, and good
> names for these functions are mod and arg. People frequently call the
> modulus of a real number it's 'absolute value' - and that's OK since the
> absolute value in the real field coincides with the complex modulus.

Currently, abs(z) returns the modulus.  I'd like to avoid a name
involving 'mod' since it suggests the modulo operation (x%y in Python,
also divmod(x, y) which returns floor(x/y), x%y).

I was asking for arg(z), which currently does not exist.

> There are technical reasons why modulus is mathematically more appealing
> than absolute value, but lots of people already think in terms of
> absolute value so you probably can't clean that up, especially since
> modulus also refers to remainders and fractional parts.

What I said :-)

> There is a forlorn hope that one can change the highly objectionable use
> of 'j' to denote the chosen imaginary unit. The use of 'i' is much more
> standard. Some Electrjcal engjneers found that they had to reserve 'i'
> to represent electrical current, and relegated the chosen imaginary unit
> to the letter 'j'. There is no other reason for this breach with long
> established tradition, and it appears that that reason has lapsed. One
> can even use the symbol 'i' for the chosen imaginary unit in the IEEE
> _Transactions on Signal Processing_ without raising an eyebrow.

Yes, too late.  I forced the matrix sig to choose between i and j and
they chose j.  I guess that makes them the matrjx sjg.

--Guido van Rossum (home page: http://www.python.org/~guido/)

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From jim.fulton@digicool.com  Tue Apr  1 22:57:06 1997
From: jim.fulton@digicool.com (Jim Fulton)
Date: Tue, 01 Apr 1997 17:57:06 -0500
Subject: [PYTHON MATRIX-SIG] Re: Conversion
References: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu> <199704010323.WAA05513@monty>
 <33416F11.16B7@ix.netcom.com> <199704012224.RAA11178@monty>
Message-ID: <334192C2.5FCD@digicool.com>

Guido van Rossum wrote:
>
(snip) 
> 
> It's currently a method: z.conjugate().  You could of course write
> 
>         def co(z): return z.conjugate()
> 
> but it would run much slower.  I am thinking to propose to make
> conjugate() a built-in function (it could return its argument
> unchanged for non-complex numbers).
> 
(snip)
> 
> I was asking for arg(z), which currently does not exist.
> 

I hate the idea of adding functions to builtins for one domain/type.

I'd much prefer a method, or a global function defined in a specialized 
module.

Jim

-- 
Jim Fulton         Digital Creations
jim@digicool.com   540.371.6909
## Python is my favorite language ##
##     http://www.python.org/     ##

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From alan@oldp.nmsu.edu  Tue Apr  1 23:47:37 1997
From: alan@oldp.nmsu.edu (Alan Watson)
Date: Tue, 1 Apr 1997 16:47:37 -0700
Subject: [PYTHON MATRIX-SIG] Re: Conversion
Message-ID: <9704012347.AA23221@oldp.nmsu.edu>

Guido van Rossum wrote:

> I forced the matrix sig to choose between i and j and
> they chose j.

This is how you described your reasons for dropping i to the
matrix-sig mailing list:

> From: Guido van Rossum <guido@CNRI.Reston.VA.US>
> Date: Tue, 16 Jan 1996 10:19:28 -0500
> Message-Id: <199601161519.KAA05252@monty>
[...]
> I changed one thing in Konrad's final patches: I took out support for
> 'i' and 'I' to indicate imaginary constants -- you have to use 'j' or
> 'J'.  I don't like to offer gratuitous choices (the lower/upper case
> equivalency is a C legacy that I keep for consistency with other
> Python numerical constants) and I expect that engineers will whine
> bitterly if I chose 'i' while mathematicians will accept 'j' without
> complaints...  (Note that unless you never read code written by
> someone else, you must learn both alternatives if they are both
> present in the language.  This is my reason for wanting to offer only
> one option -- not the savings in instruction size or cycles.)

Unless I am mistaken, reponsibility for this behaviour would appear to
be yours alone.

Alan Watson

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From guido@CNRI.Reston.Va.US  Tue Apr  1 23:59:17 1997
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Tue, 01 Apr 1997 18:59:17 -0500
Subject: [PYTHON MATRIX-SIG] Re: Conversion
In-Reply-To: Your message of "Tue, 01 Apr 1997 16:47:37 MST."
 <9704012347.AA23221@oldp.nmsu.edu>
References: <9704012347.AA23221@oldp.nmsu.edu>
Message-ID: <199704012359.SAA12196@monty>

> Guido van Rossum wrote:
> 
> > I forced the matrix sig to choose between i and j and
> > they chose j.
> 
> This is how you described your reasons for dropping i to the
> matrix-sig mailing list:
> 
> > From: Guido van Rossum <guido@CNRI.Reston.VA.US>
> > Date: Tue, 16 Jan 1996 10:19:28 -0500
> > Message-Id: <199601161519.KAA05252@monty>
> [...]
> > I changed one thing in Konrad's final patches: I took out support for
> > 'i' and 'I' to indicate imaginary constants -- you have to use 'j' or
> > 'J'.  I don't like to offer gratuitous choices (the lower/upper case
> > equivalency is a C legacy that I keep for consistency with other
> > Python numerical constants) and I expect that engineers will whine
> > bitterly if I chose 'i' while mathematicians will accept 'j' without
> > complaints...  (Note that unless you never read code written by
> > someone else, you must learn both alternatives if they are both
> > present in the language.  This is my reason for wanting to offer only
> > one option -- not the savings in instruction size or cycles.)
> 
> Unless I am mistaken, reponsibility for this behaviour would appear to
> be yours alone.

Not quite -- I did this after consulting some matrix-sig people.
Apparently they couldn't make up their mind.  Nobody complained
(before Andrew).

--Guido van Rossum (home page: http://www.python.org/~guido/)


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From amullhau@ix.netcom  Wed Apr  2 02:01:52 1997
From: amullhau@ix.netcom (Andrew P. Mullhaupt)
Date: Tue, 01 Apr 1997 21:01:52 -0500
Subject: [PYTHON MATRIX-SIG] Re: Conversion
References: <01BC3DE4.81E4BAE0@misha.lcs.mit.edu> <199704010323.WAA05513@monty>
 <33416F11.16B7@ix.netcom.com> <199704012224.RAA11178@monty>
Message-ID: <3341BE10.A97@ix.netcom.com>

Guido van Rossum wrote:
> 
> > You want to be able to extract the real and imaginary parts, and
> > good names for these functions are Re and Im.
> 
> You write this as z.real, z.imag.

> but it would run much slower.  I am thinking to propose to make
> conjugate() a built-in function (it could return its argument
> unchanged for non-complex numbers).

I was assuming that making it a built-in was essentially agreed to
already.

> I was asking for arg(z), which currently does not exist.

You mean, does not exist as a built-in. It would be a good candidate for
that.

> Yes, too late.  I forced the matrix sig to choose between i and j and
> they chose j.  I guess that makes them the matrjx sjg.

It may well do. But this is sort of an internationalization issue. You
might want the decimal separator to be "." in the U. S. and "," in
Germany. Just like you want the chosen imaginary unit to be "i" on Earth
and perhaps "j" on some other, yet undiscovered, planet.

Later,
Andrew Mullhaupt

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From amullhau@ix.netcom  Wed Apr  2 02:20:56 1997
From: amullhau@ix.netcom (Andrew P. Mullhaupt)
Date: Tue, 01 Apr 1997 21:20:56 -0500
Subject: [PYTHON MATRIX-SIG] Re: Conversion
References: <9704012347.AA23221@oldp.nmsu.edu> <199704012359.SAA12196@monty>
Message-ID: <3341C288.C24@ix.netcom.com>

Guido van Rossum wrote:
> 
> Not quite -- I did this after consulting some matrix-sig people.
> Apparently they couldn't make up their mind.  Nobody complained
> (before Andrew).
> 

Were any other mathematicians aware of this during the period in which
nobody complained?

You will find that there are some mathematicians who permit the use of
'j' in service courses for engineers, who have even put it in texts for
such courses. I am not aware of a single instance outside of this sort
where 'j' is used.

And it matters. When you teach students to use 'j' for 'i', and use
'log' for logarithms in heretical bases (e.g. 2, 10), you are erecting a
sequence of progressive barriers between them and the high-class
literature. Worse yet, in the case at hand, you are choosing the
convention so that elementary algebra books do not explain the feature
of the language using the same symbols as the language. This is no
problem for those who have mastered complex arithmetic, but it may prove
confusing to people who only have the occasional brush with it and do
not have an electrjcal engjneerjng text within easy reach.

Later,
Andrew Mullhaupt

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From da@maigret.cog.brown.edu  Wed Apr  2 03:04:48 1997
From: da@maigret.cog.brown.edu (David Ascher)
Date: Tue, 1 Apr 1997 22:04:48 -0500 (EST)
Subject: [PYTHON MATRIX-SIG] Re: Conversion
In-Reply-To: <3341C288.C24@ix.netcom.com>
Message-ID: <Pine.SGI.3.95q.970401215802.27816A-100000@maigret>

On Tue, 1 Apr 1997, Andrew P. Mullhaupt wrote:

> And it matters. When you teach students to use 'j' for 'i', and use
> 'log' for logarithms in heretical bases (e.g. 2, 10), you are erecting a
> sequence of progressive barriers between them and the high-class
> literature. Worse yet, in the case at hand, you are choosing the
> convention so that elementary algebra books do not explain the feature
> of the language using the same symbols as the language. This is no
> problem for those who have mastered complex arithmetic, but it may prove
> confusing to people who only have the occasional brush with it and do
> not have an electrjcal engjneerjng text within easy reach.

I think it's a really minor point -- a quick look at the documentation
will tell the hapless student what 'j' is all about, and then s/he'll move
on to trying to figure out why 'matrix' multiplication works the way it
does or what shapes, ranks and dimensions really mean... 

--david, raised on 'i' pronounced /e/ and who now has to 
  use 'j' which he grew up pronouncing /g/.  So it goes.

PS: I can't wait for spring -- I'm assuming it will help the tone on the
    main list, since nothing else seems to do...


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From nigel@maths.su.oz.au  Wed Apr  2 04:28:50 1997
From: nigel@maths.su.oz.au (Nigel O'Brian)
Date: Wed, 2 Apr 1997 14:28:50 +1000 (EST)
Subject: [PYTHON MATRIX-SIG] How to Avoid the Mega-malloc?
Message-ID: <199704020428.OAA17736@milan.maths.su.oz.au>


David Ascher <da@maigret.cog.brown.edu> writes:

>> PS: I can't wait for spring -- I'm assuming it will help the tone on the
>>     main list, since nothing else seems to do...

Sorry, down here it's Fall, so I can't help you much.

Suppose I write a NumPy formula like

  A = 0.1*B + 0.2*C

where A, B and C are, say, arrays of 1 million floats. This causes a
modest 16Mb Linux box to swap like crazy. Depending what else is
happening, it may just run out of memory altogether. I'm guessing that
memory is being claimed for (perhaps) several intermediate results.

But thanks to the ufuncs' optional 3rd argument I can do something like

  add(multiply(0.1,B,B),multiply(0.2,C,C),B)

leaving the answer in B (if I don't mind trashing B and C).  I guess
this avoids any claims on memory. But it seems like there is one place
where this trick doesn't work -- namely operations based on the dot
product, such as matrix multiplication.

To get around this I wrote a rather specialised C extension to do
matrix multiplication in place (and only on certain types of
array). This saved a lot of memory and produced something like a 2x
speedup over standard NumPy on more modestly sized arrays.

In fact I would gladly give up the 2x speedup to keep the uniformity
and generality of standard NumPy. Any chance of an optional third
argument to `dot' to receive the result? Or is there some other trick
that I can use to multiply big arrays without a malloc?

Nigel
--------------------------------------------------------------------
Nigel O'Brian                             obrian_n@maths.usyd.edu.au
School of Mathematics                     Ph: (02)-9351-4083
University of Sydney                      FAX: (02)-9351-4534                
Sydney NSW 2006, Australia









_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From amullhau@ix.netcom.com  Wed Apr  2 06:41:03 1997
From: amullhau@ix.netcom.com (Andrew P. Mullhaupt)
Date: Wed, 02 Apr 1997 01:41:03 -0500
Subject: [PYTHON MATRIX-SIG] How to Avoid the Mega-malloc?
References: <199704020428.OAA17736@milan.maths.su.oz.au>
Message-ID: <3341FF7F.427F@ix.netcom.com>

Nigel O'Brian wrote:
> 
> Or is there some other trick
> that I can use to multiply big arrays without a malloc?
> 

There is, but I'm still working on it. You are essentially in the
situation where mmap is a godsend, although in the matrix-matrix
product you will still want to do a little more to control your
resident set size.

Later,
Andrew Mullhaupt

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Wed Apr  2 08:20:55 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 2 Apr 1997 10:20:55 +0200
Subject: [PYTHON MATRIX-SIG] Re: Conversion
In-Reply-To: <199704010323.WAA05513@monty> (message from Guido van Rossum on
 Mon, 31 Mar 1997 22:23:50 -0500)
Message-ID: <199704020820.KAA07978@lmspc1.ibs.fr>

> I have a feeling that for orthogonality, conjugate() should have to be
> a built-in function (like abs()); and that there should be some other
> built-in function (angle()?) that returns ``the other polar
> coordinate'' so that (abs(z), angle(z)) are an alternate
> representation of z.  But you can tell that I'm not a complex number

Exactly! This would be the most obvious solution. Another possibility
would be to have conjugate() in cmath (which is part of the standard
distribution), for those who use complex numbers but not NumPy.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Wed Apr  2 08:45:03 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 2 Apr 1997 10:45:03 +0200
Subject: [PYTHON MATRIX-SIG] Re: Conversion
In-Reply-To: <3341C288.C24@ix.netcom.com> (amullhau@ix.netcom.com)
Message-ID: <199704020845.KAA08034@lmspc1.ibs.fr>

> You will find that there are some mathematicians who permit the use of
> 'j' in service courses for engineers, who have even put it in texts for
> such courses. I am not aware of a single instance outside of this sort
> where 'j' is used.

In many books on electrical engineering. And in some other programming
languages (APL2, J).

> And it matters. When you teach students to use 'j' for 'i', and use
> 'log' for logarithms in heretical bases (e.g. 2, 10), you are erecting a
> sequence of progressive barriers between them and the high-class
> literature. Worse yet, in the case at hand, you are choosing the

No more than by writing 2.5e6 instead of

                   6
           2.5 x 10

And the only way to be completely compatible with standard mathematical
notation would be to make 'i' a built-in variable. Which is in fact
not far from what I would recommend to those who see a problem with
the notation: write "i = 1j" at the beginning, and be happy. But
don't use i as a loop counter afterwards...
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Wed Apr  2 10:00:10 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 2 Apr 1997 12:00:10 +0200
Subject: [PYTHON MATRIX-SIG] Suggestion for pickle
In-Reply-To: <199703282115.WAA24382@sapporo.ibp.fr>
 (viennet@ura1507.univ-paris13.fr)
Message-ID: <199704021000.MAA08284@lmspc1.ibs.fr>

>  But NOT using the standard pickle.Pickler and pickle.Unpickler
> classes, which is sometimes annoying.
> I suggest to directly modify the original classes: just add
> 
> pickle.Unpickler = Unpickler
> pickle.Pickler = Pickler
> 
> at the end of Numeric.py

This is not really a problem with NumPy, but with pickling in general.
Subclassing is the recommended way to add extensions, but it is not
a good solution in practice.

Your solution seems good at first sight, but imagine what happens if
not only NumPy, but also other extensions do the same. You'd never
know which pickler you are using! As it is, you can choose the pickler
you want to use by importing it. It is still bad enough that no single
pickler can handle all extensions at the same time, but at least users
are aware of the problem.

The approach that cPickle uses to add extension types is a much better
one, and I hope that this will become standard at some time.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From dubois1@llnl.gov  Wed Apr  2 15:13:32 1997
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Wed, 2 Apr 1997 07:13:32 -0800
Subject: [PYTHON MATRIX-SIG] Re: Conversion
Message-ID: <9704021515.AA11837@icf.llnl.gov.llnl.gov>

I'm a mathematician. I complained. But I came to see that there were a lot of
different communities involved and that for each issue, what one group saw as
the right answer was completely strange to some other group.

There is also more of a base here than just the "mathematical" literature.
There are a lot of mathematical computation tools, and they have evolved in
many cases a fairly similar solution to some of these things. For example,
use of x[i:j:k] and the idea that sin(x) is defined as sin(x)(i) == sin(x(i))
for each i.

What can be said in our favor is that we did not MAKE UP much of anything. It
is all borrowed from SOME community. For example, I think you made up an
off-the-wall suggestion that conjugate might be abbreviated "co". That is
precisely what we did not do. We argued about the Fortran name conjg vs.
conjugate, for example. I made many impassioned pleas for avoiding
abbreviations on the grounds that if you don't abbreviate you can't forget
which form of abbreviation you used.

Anyway, sorry if you don't like the elephant but it was designed by
committee.

By the way, there is nothing "higher" about mathematics vs. engineering.
Evolution does not have a goal. 

A reformed Abelian groupist,

Paul

----------
> From: Andrew P. Mullhaupt <amullhau@ix.netcom.com>
> To: Guido van Rossum <guido@CNRI.Reston.Va.US>
> Cc: Alan Watson <alan@oldp.nmsu.edu>; matrix-sig@python.org
> Subject: Re: [PYTHON MATRIX-SIG] Re: Conversion
> Date: Tuesday, April 01, 1997 6:20 PM
> 
> Guido van Rossum wrote:
> > 
> > Not quite -- I did this after consulting some matrix-sig people.
> > Apparently they couldn't make up their mind.  Nobody complained
> > (before Andrew).
> > 
> 
> Were any other mathematicians aware of this during the period in which
> nobody complained?
> 
> You will find that there are some mathematicians who permit the use of
> 'j' in service courses for engineers, who have even put it in texts for
> such courses. I am not aware of a single instance outside of this sort
> where 'j' is used.
> 
> And it matters. When you teach students to use 'j' for 'i', and use
> 'log' for logarithms in heretical bases (e.g. 2, 10), you are erecting a
> sequence of progressive barriers between them and the high-class
> literature. Worse yet, in the case at hand, you are choosing the
> convention so that elementary algebra books do not explain the feature
> of the language using the same symbols as the language. This is no
> problem for those who have mastered complex arithmetic, but it may prove
> confusing to people who only have the occasional brush with it and do
> not have an electrjcal engjneerjng text within easy reach.
> 
> Later,
> Andrew Mullhaupt
> 
> _______________
> MATRIX-SIG  - SIG on Matrix Math for Python
> 
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> _______________

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From dubois1@llnl.gov  Wed Apr  2 15:13:32 1997
From: dubois1@llnl.gov (Paul F. Dubois)
Date: Wed, 2 Apr 1997 07:13:32 -0800
Subject: [PYTHON MATRIX-SIG] Re: Conversion
Message-ID: <9704021515.AA11837@icf.llnl.gov.llnl.gov>

I'm a mathematician. I complained. But I came to see that there were a lot of
different communities involved and that for each issue, what one group saw as
the right answer was completely strange to some other group.

There is also more of a base here than just the "mathematical" literature.
There are a lot of mathematical computation tools, and they have evolved in
many cases a fairly similar solution to some of these things. For example,
use of x[i:j:k] and the idea that sin(x) is defined as sin(x)(i) == sin(x(i))
for each i.

What can be said in our favor is that we did not MAKE UP much of anything. It
is all borrowed from SOME community. For example, I think you made up an
off-the-wall suggestion that conjugate might be abbreviated "co". That is
precisely what we did not do. We argued about the Fortran name conjg vs.
conjugate, for example. I made many impassioned pleas for avoiding
abbreviations on the grounds that if you don't abbreviate you can't forget
which form of abbreviation you used.

Anyway, sorry if you don't like the elephant but it was designed by
committee.

By the way, there is nothing "higher" about mathematics vs. engineering.
Evolution does not have a goal. 

A reformed Abelian groupist,

Paul

----------
> From: Andrew P. Mullhaupt <amullhau@ix.netcom.com>
> To: Guido van Rossum <guido@CNRI.Reston.Va.US>
> Cc: Alan Watson <alan@oldp.nmsu.edu>; matrix-sig@python.org
> Subject: Re: [PYTHON MATRIX-SIG] Re: Conversion
> Date: Tuesday, April 01, 1997 6:20 PM
> 
> Guido van Rossum wrote:
> > 
> > Not quite -- I did this after consulting some matrix-sig people.
> > Apparently they couldn't make up their mind.  Nobody complained
> > (before Andrew).
> > 
> 
> Were any other mathematicians aware of this during the period in which
> nobody complained?
> 
> You will find that there are some mathematicians who permit the use of
> 'j' in service courses for engineers, who have even put it in texts for
> such courses. I am not aware of a single instance outside of this sort
> where 'j' is used.
> 
> And it matters. When you teach students to use 'j' for 'i', and use
> 'log' for logarithms in heretical bases (e.g. 2, 10), you are erecting a
> sequence of progressive barriers between them and the high-class
> literature. Worse yet, in the case at hand, you are choosing the
> convention so that elementary algebra books do not explain the feature
> of the language using the same symbols as the language. This is no
> problem for those who have mastered complex arithmetic, but it may prove
> confusing to people who only have the occasional brush with it and do
> not have an electrjcal engjneerjng text within easy reach.
> 
> Later,
> Andrew Mullhaupt
> 
> _______________
> MATRIX-SIG  - SIG on Matrix Math for Python
> 
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> _______________

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From jbaddor@phy.ulaval.ca  Sun Apr  6 17:14:01 1997
From: jbaddor@phy.ulaval.ca (Jean-Bernard ADDOR)
Date: Sun, 6 Apr 1997 12:14:01 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] bug ?  problem with =
Message-ID: <Pine.SUN.3.95.970406120632.3358C-100000@mills>

Python 1.4b3 (Oct 24 1996)  [GCC 2.7.2]
Copyright 1991-1996 Stichting Mathematisch Centrum, Amsterdam

f = open("Y04I0604.CDR",'r')
import array
a = array.array('h')
f.seek(511)
a.fromfile(f,pow(2,13))
f.close()

import Numeric
n = Numeric.array(a)
del a
n.shape = (n.shape[0],1)


def Delta(a, tau):
		r = Numeric.zeros(len(a) - tau)
		for t in range(len(r)):
				diff = a[t+tau] -a[t]
				print t, tau, a[t +tau], a[t], r[t],
n.typecode(), r.typecode(), diff, diff.typecode(), r.shape
				r[t] = diff #<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
		return r

def psi(a, q):
		r = Numeric.zeros(len(a) - 2)
		for tau in range(len(r)):
				s = pow(Delta(a,tau +1),q)
				r[tau] = add.reduce(s)/len(s)				
		return r

f = open("Y04I0604.q1", 'w')
f.write(str(psi(n,1)))
f.close()

>>> f =open("Y04I0604.q1", 'w')
>>> f.write(str(psi(n,1)))
0 1 3689 3442 0 l l 247 l (8191,)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 4, in psi
  File "<stdin>", line 6, in Delta
TypeError: illegal argument type for built-in operation



	Jean-Bernard



_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From steve@estel.UINDY.EDU  Mon Apr  7 05:57:33 1997
From: steve@estel.UINDY.EDU (Steve Spicklemire)
Date: Sun, 6 Apr 97 23:57:33 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <3320B04A.4AE6@tismer.com> (message from Christian Tismer on Sat, 08 Mar 1997 01:18:18 +0100)
Message-ID: <9704070457.AA03495@estel.uindy.edu>

Hi Folks,

	I haven't heard much more from this thread.... but I've
been stealing occasional moments to add more stuff. Take a look
again if you like.... especially the last two examples on this
page showing sound out, and animation...

-steve

    >> I don't know if this would help at all, but I've been having
    >> good luck using a Java/Applet based graphing. I've been using
    >> NumPy in Physics courses since the 0.3x days. I've incorporated
    >> David A.'s docs. At one point I melded it with my Zinc based
    >> GUI module.. but now I'm using more 'off the shelf' technology
    >> (i.e., Java) Point your favorite Java enabled browser to
    >> 
    >> http://estel.uindy.edu/PESSci/ph280/
    >> 
    >> and look at some of the links there. The nice thing about this
    >> approach is that you can make the resulting 'graph' more
    >> interactive. It might be pretty easy to come up with some
    >> applets that work nicely with NumPy, and also allow lots of
    >> other cool stuff.



_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From steve@estel.uindy.edu  Mon Apr  7 19:57:14 1997
From: steve@estel.uindy.edu (Steve Spicklemire)
Date: Mon, 7 Apr 97 13:57:14 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: <9704070457.AA03495@estel.uindy.edu> (steve)
Message-ID: <9704071857.AA05236@estel.uindy.edu>

Hi again....

	I don't want to pester anyone.. bug lots of folks have checked
the site and my first message wasn't clear enough. Just to avoid more
confusion, the new stuff is at:

http://estel.uindy.edu/cgi-bin/dynaGraph.py?file=sound.py

which demonstrated synthesizing a sound file and shipping
it over the Internet

and

http://estel.uindy.edu/cgi-bin/dynaGraph.py?file=testAnim.py

which shows a crude animation facitily I cooked up and added
to the earlier Java graphing class I had written about. I think
this approach has potential... I don't remember reaching any
kind of 'resolution' about the sitation. Is anyone out there
working on an API for graphics within NumPy? Should we
cook one up (like the db-sig did?).

Thanks!
-steve

>>>>> "Steve" == Steve Spicklemire <steve> writes:

    Steve> Hi Folks, I haven't heard much more from this
    Steve> thread.... but I've been stealing occasional moments to add
    Steve> more stuff. Take a look again if you like.... especially
    Steve> the last two examples on this page showing sound out, and
    Steve> animation...

    Steve> -steve

    >>> I don't know if this would help at all, but I've been having
    >>> good luck using a Java/Applet based graphing. I've been using
    >>> NumPy in Physics courses since the 0.3x days. I've
    >>> incorporated David A.'s docs. At one point I melded it with my
    >>> Zinc based GUI module.. but now I'm using more 'off the shelf'
    >>> technology (i.e., Java) Point your favorite Java enabled
    >>> browser to
    >>> 
    >>> http://estel.uindy.edu/PESSci/ph280/
    >>> 
    >>> and look at some of the links there. The nice thing about this
    >>> approach is that you can make the resulting 'graph' more
    >>> interactive. It might be pretty easy to come up with some
    >>> applets that work nicely with NumPy, and also allow lots of
    >>> other cool stuff.




_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From rodgers@vs.lmco.com  Mon Apr  7 21:23:33 1997
From: rodgers@vs.lmco.com (Kevin Rodgers (x39079, WT-07))
Date: Mon, 07 Apr 1997 15:23:33 -0500
Subject: [PYTHON MATRIX-SIG] Plotting packages
In-Reply-To: Your message of "Mon, 07 Apr 1997 13:57:14 CDT."
 <9704071857.AA05236@estel.uindy.edu>
Message-ID: <199704072023.PAA01056@daedalus>

Awhile back in the plotting packages discussion, there was some discussion of 
PLPlot.  I tried to get it working with Python but failed; it appeared that 
the new Tk widget it introduces is not dynamically loadable, and so is not 
accessible from Tkinter.  Has anybody on this list gotten PLPlot working with 
Python, and what did you have to do?  Or should I just post to the PLPlot 
mailing list?  Thanks in advance . . .
-- 
Kevin Rodgers    Lockheed Martin Vought Systems    rodgers@vs.lmco.com
"This one goes up to eleven."  --  Nigel Tufnel
-------------------------------------------------------------------------------



_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From tommy@kerner.com  Mon Apr 14 18:36:06 1997
From: tommy@kerner.com (Tommy Burnette)
Date: Mon, 14 Apr 1997 10:36:06 -0700
Subject: [PYTHON MATRIX-SIG] function not supported?
Message-ID: <199704141736.KAA18078@derlin.kerner.com>

Hey there,

I picked up the latest (I think it's the latest?) Numeric extensions
after Jim H. posted that it was about ready for primt time.  I got the
package from: http://www.sls.lcs.mit.edu/~jjh/numpy about three or
four weeks ago.  It all built fine and imports okay, but every other
test program I have for it fails in about the same way.  Here's what
happened when I ran the mandelbrot.py Demo:

(tommy@derlin)/u0/tommy$ python -i /net/gs/src/lib/NumPy/Demo/mandelbrot.py 
Traceback (innermost last):
  File "/net/gs/src/lib/NumPy/Demo/mandelbrot.py", line 25, in ?
    print draw(-2.1, 0.7, -1.2, 1.2)
  File "/net/gs/src/lib/NumPy/Demo/mandelbrot.py", line 10, in draw
    xx=arange(LowX,HighX,(HighX-LowX)/stepx)
  File "/u1/gfx/lib/python/NumPy/Numeric.py", line 28, in arrayrange
    m = (add.accumulate(ones((n,), Int))-1)*step + (start + stop-stop)
  File "/u1/gfx/lib/python/NumPy/Numeric.py", line 301, in ones
    return zeros(shape, typecode)+array(1, typecode)
ValueError: function not supported
>>> 


It appears that multiarrays do not support the "+" operator.  Strange
since they are used this way all over the modules that I've looked
at.  When I walked through the multiarray source I couldn't find
anything that seemed to support the "+" or "__add__" or anything like
that.  So who's out of synch here?  What am I missing?  Thanks,

							Tommy.


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hugunin@mit.edu  Mon Apr 14 20:29:16 1997
From: hugunin@mit.edu (Jim Hugunin)
Date: Mon, 14 Apr 1997 15:29:16 -0400
Subject: [PYTHON MATRIX-SIG] function not supported?
Message-ID: <01BC48E8.9DD38970@misha.lcs.mit.edu>

Tommy writes:
> I picked up the latest (I think it's the latest?) Numeric extensions
> after Jim H. posted that it was about ready for primt time.  I got the
> package from: http://www.sls.lcs.mit.edu/~jjh/numpy about three or
> four weeks ago.  It all built fine and imports okay, but every other
> test program I have for it fails in about the same way.  Here's what
> happened when I ran the mandelbrot.py Demo:

I've seen this problem before.  It appears to have to do with dynamic 
linking under particular OS's.  I assume that you're using the dynamically 
linked version of numpy?  Also, what OS are you running under?

The numeric functions on multiarrays are actually implemented in 
umathmodule.c.  When this module is imported, it fills in the table of math 
functions for arrayobjects.  The problem is that somehow on your system, 
this table is not getting filled in.  I'd bet that if you build a 
statically linked version of Python + NumPy, this problem will go away.  If 
you know enough about your OS's dynamic linking system to figure out why 
things are not working on your machine, I'd love to adopt any patches you 
might have.  For a clue, the function that probably isn't working is in 
umath_init in umathmodule.c and it's the line:

 	/* Setup the array object's numerical structures */
 	 PyArray_SetNumericOps(d);

Let me know how it goes - Jim


_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Fri Apr 18 10:36:58 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 18 Apr 1997 11:36:58 +0200
Subject: [PYTHON MATRIX-SIG] Integrated Python/NumPy distribution available
Message-ID: <199704180936.LAA12951@lmspc1.ibs.fr>

Following several complaints from prospective users of my recently
announced molecular modelling toolkit about difficulties with installing
NumPy, I have prepared a modified Python 1.4 distribution that includes
NumPy (and also my netCDF module, but that is comparatively trivial).
It should be of interest to other users of NumPy who had problems with
installation.

Unfortunately the file is too big to put on my Web site, but the
Laboratoire de Chimie théorique de Nancy offered to host it on their
server. You can get it from
     http://www.lctn.u-nancy.fr/services/mmtk/

This distribution also fixes the CObject linking problem under Irix 6.2/6.3
(a small change to "configure").
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From ta.short@pti-us.com  Fri Apr 18 18:08:49 1997
From: ta.short@pti-us.com (Tom Short)
Date: Fri, 18 Apr 1997 17:08:49 +0000
Subject: [PYTHON MATRIX-SIG] Re: Plotting: Windows version of Yorick & Gist graphics
Message-ID: <199704182108.RAA24803@hobbes.pti-us.com>

A win95/nt beta version of the array language Yorick is available
at:

   ftp://ftp-icf.llnl.gov/pub/Yorick

It is an MFC program which is similar to PythonWin 
(commands are entered into an edit-like window).

This is a very useful tool in its own right, but of special interest
for NumPy is the Gist graphics library included with Yorick. It is
available for unix, the mac, and now windows. It would be a good 
choice for a cross platform graphics library for NumPy.

The folks at LLNL have already done an interface to Python (PyGist),
and a few weeks ago, their posts to this list indicated that they
were working on an object-oriented interface.

E-mail from Steve Langer (who ported Yorick to Windows and the Mac)
said that he did not think anyone at LLNL was doing a port of Gist
for PythonWin. Steve did issue one warning though:

> There are some issues about the Python event loop vs.
> the Gist event loop that would probably be very different under
> windows and UNIX.

Someone with a compiler may want to get the source code from Steve
(shl@icf.llnl.gov) and try and interface it with
PythonWin+NumPy+PyGist. If anyone else from LLNL has any suggestions
or comments on their plans for PyGist, please let us know.

- Tom
--------------------------
See the PTI Lightning Photo Gallery: http://www.pti-us.com/pti/consult/dist/photos.htm

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From busby@icf.llnl.gov  Sat Apr 19 02:01:37 1997
From: busby@icf.llnl.gov (L. Busby)
Date: Fri, 18 Apr 97 18:01:37 PDT
Subject: [PYTHON MATRIX-SIG] Re: Plotting: Windows version of Yorick & Gist graphics
Message-ID: <9704190101.AA00841@icf.llnl.gov.llnl.gov>

[ Tom Short said ]
>A win95/nt beta version of the array language Yorick is available at:
>
>   ftp://ftp-icf.llnl.gov/pub/Yorick
>
>It is an MFC program which is similar to PythonWin 
>(commands are entered into an edit-like window).
>
>This is a very useful tool in its own right, but of special interest
>for NumPy is the Gist graphics library included with Yorick. It is
>available for unix, the mac, and now windows. It would be a good 
>choice for a cross platform graphics library for NumPy.
>
>The folks at LLNL have already done an interface to Python (PyGist),
>and a few weeks ago, their posts to this list indicated that they
>were working on an object-oriented interface.
>
>E-mail from Steve Langer (who ported Yorick to Windows and the Mac)
>said that he did not think anyone at LLNL was doing a port of Gist
>for PythonWin. Steve did issue one warning though:
>
>> There are some issues about the Python event loop vs.
>> the Gist event loop that would probably be very different under
>> windows and UNIX.
>
>Someone with a compiler may want to get the source code from Steve
>(shl@icf.llnl.gov) and try and interface it with
>PythonWin+NumPy+PyGist. If anyone else from LLNL has any suggestions
>or comments on their plans for PyGist, please let us know.
>
>- Tom

I don't really have any suggestions.  As far as comments go, a Windows
port of Python + Gist is not on my short list of high-priority
projects at this time (so others should certainly feel free to have at
it).  The highest priority for me at the moment is to update the Pygist
module so that it supports the latest Gist library, published as part
of Yorick 1.4.

One of the principles which I tried to cleave unto in writing the
Pygist module was to behave as a strict client of Python, NumPy, and
the Gist library itself.  I didn't entirely succeed - it required a 4
line patch in Python to support the Gist event loop for X Windows
graphics.  But there were no other changes required in NumPy or the
Gist library itself.

It is not quite the case yet, as Tom said above, that ``the Gist
library is available for unix, the mac, and now windows''.  More
precisely, there are versions of *Yorick* which run on those
platforms.  But there is not yet a single Gist library which presents a
uniform API and provides a uniform mechanism for event handling across
all those platforms.  That is a problem with some hard tradeoffs.

My comments are not meant to discourage anyone.  I do think that you
will have to modify both Python and Gist to accomplish this goal.  You
should not underestimate the difficulty of building and maintaining
such a code, while continuing to track changes made by the separate
authors.

Lee

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From michaelb@gold.iap.net.au  Mon Apr 21 12:04:00 1997
From: michaelb@gold.iap.net.au (Michael Bell)
Date: Mon, 21 Apr 97 11:04 WST
Subject: [PYTHON MATRIX-SIG] Integrated Python/NumPy distribution available
In-Reply-To: <199704180936.LAA12951@lmspc1.ibs.fr> (message from Konrad Hinsen
 on Fri, 18 Apr 1997 11:36:58 +0200)
Message-ID: <m0wJ9PU-00001JC@grendel.iap.net.au>

Konrad wrote:
> NumPy, I have prepared a modified Python 1.4 distribution that includes
> NumPy (and also my netCDF module, but that is comparatively trivial).
                     ^^^^^^
Thanks for the module Konrad, I've made great use of it under Linux.  
Has someone, or can someone, make available a binary of that netcdf
module for NT?

(I'm quite at home compiling modules for unix, but I find anything
Windowsish very perplexing)

-- 
Michael Bell
Kalgoorlie Consolidated Gold Mines, Western Australia

arrangements assassination PLO jihad $400 million in gold bullion
Serbian nuclear strategic Khaddafi plutonium Ft. Bragg bomb Soviet
World Trade Center Uzi

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From da@maigret.cog.brown.edu  Mon Apr 21 04:30:18 1997
From: da@maigret.cog.brown.edu (David Ascher)
Date: Sun, 20 Apr 1997 23:30:18 -0400 (EDT)
Subject: [PYTHON MATRIX-SIG] Integrated Python/NumPy distribution available
In-Reply-To: <m0wJ9PU-00001JC@grendel.iap.net.au>
Message-ID: <Pine.SGI.3.95q.970420232338.29401A-100000@maigret>

On Mon, 21 Apr 1997, Michael Bell wrote:

> Thanks for the module Konrad, I've made great use of it under Linux.  
> Has someone, or can someone, make available a binary of that netcdf
> module for NT?
> 
> (I'm quite at home compiling modules for unix, but I find anything
> Windowsish very perplexing)

Only somewhat related, but -- I've just discovered the Cygnus gnu-win32
project [1], which is basically an attempt to have the GNU tools on Win32
(95 + NT).  It's not finished yet, but what it means is that as long as
all you need is non-GUI code, you can usually do

	./configure ; make

and things work pretty well.  Python + NumPy worked fine (once I ifdef'ed
out the four calls which aren't in the Cygnus API yet (pause(),
set/getsockopt(), and setpwent()). 

Readline doesn't work yet that I can manage, so I still don't have command
line completion on NT =(.  However, all of posix (with the exceptions
noted above) and select() work, which is cool. 

[1]:  http://www.cygnus.com/misc/gnu-win32

--da



_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From Anthony Baxter <arb@connect.com.au>  Mon Apr 21 04:42:02 1997
From: Anthony Baxter <arb@connect.com.au> (Anthony Baxter)
Date: Mon, 21 Apr 1997 13:42:02 +1000
Subject: [PYTHON MATRIX-SIG] Integrated Python/NumPy distribution available
In-Reply-To: Your message of "Sun, 20 Apr 1997 23:30:18 -0400."
 <Pine.SGI.3.95q.970420232338.29401A-100000@maigret>
Message-ID: <199704210342.NAA17728@jambu.off.connect.com.au>


>>> David Ascher wrote
> Only somewhat related, but -- I've just discovered the Cygnus gnu-win32
> project [1], which is basically an attempt to have the GNU tools on Win32
> (95 + NT).  It's not finished yet, but what it means is that as long as
> all you need is non-GUI code, you can usually do

There's also UWIN, from Bell Labs.
http://www.research.att.com/sw/tools/uwin/

Provides a unix environment and API under NT/95.

Anthony

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Mon Apr 21 09:19:56 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Mon, 21 Apr 1997 10:19:56 +0200
Subject: [PYTHON MATRIX-SIG] Integrated Python/NumPy distribution available
In-Reply-To: <m0wJ9PU-00001JC@grendel.iap.net.au> (message from Michael Bell
 on Mon, 21 Apr 97 11:04 WST)
Message-ID: <199704210819.KAA27876@lmspc1.ibs.fr>

> Has someone, or can someone, make available a binary of that netcdf
> module for NT?

Good question. Certainly not me; I have used NT for a grand total
of five minutes in my whole life!

I don't know how many people use Python, NumPy etc. with NT, but
maybe they could set up an arrangement to provide binaries for
extension modules. Any volunteers?
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From susan@pcmdi.llnl.gov  Wed Apr 23 18:48:35 1997
From: susan@pcmdi.llnl.gov (Susan Peterson)
Date: Wed, 23 Apr 1997 10:48:35 -0700
Subject: [PYTHON MATRIX-SIG] getting ArrayObjects pointer
Message-ID: <9704231048.ZM6046@penguin.llnl.gov>

Hi,

In an external C function, I am trying to get the pointer to an
ArrayObject that was created with PyObject_NEW.  If I pass the name
of the ArrayObject how can I find the objects pointer?

Also, Is there any way to get a list of all objects that have been
created during a Python session, via a C code?

Please send reply to susan@penguin.llnl.gov

Thanks.
-Susan

-- 
Susan Peterson

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Thu Apr 24 09:16:11 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Thu, 24 Apr 1997 10:16:11 +0200
Subject: [PYTHON MATRIX-SIG] getting ArrayObjects pointer
In-Reply-To: <9704231048.ZM6046@penguin.llnl.gov> (susan@pcmdi.llnl.gov)
Message-ID: <199704240816.KAA17363@lmspc2.ibs.fr>

> In an external C function, I am trying to get the pointer to an
> ArrayObject that was created with PyObject_NEW.  If I pass the name
> of the ArrayObject how can I find the objects pointer?

That depends on where the name was defined. It could be in a module,
as a local variable in a function, or as an object attribute.
The most general solution, given the name and the namespace it is in,
is to call an expression evaluation from C.

> Also, Is there any way to get a list of all objects that have been
> created during a Python session, via a C code?

I doubt it, and it would probably not be very useful. Such a list
would include all functions and classes imported from various modules,
including the standard library! You can however easily get all objects
in a given namespace, via its dictionary.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hrc@monsoon.colorado.edu  Wed Apr 30 19:54:35 1997
From: hrc@monsoon.colorado.edu (Hai-Ru Chang)
Date: Wed, 30 Apr 1997 12:54:35 -0600
Subject: [PYTHON MATRIX-SIG] calling FORTRAN subroutine inside python
Message-ID: <199704301854.MAA25362@typhoon.>

Hello,
     Is there any way that I can call FORTRAN (prefer f90) subroutines inside
a python program?  Thanks!

Dr. Hai-Ru Chang
Program in Atmospheric and Oceanic Sciences
Campus Box 311
University of Colorado at Boulder
Boulder, CO 80309
Tel: (303)492-0544
Fax: (303)492-3524

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________

From hinsen@ibs.ibs.fr  Wed Apr 30 20:34:48 1997
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 30 Apr 1997 21:34:48 +0200
Subject: [PYTHON MATRIX-SIG] calling FORTRAN subroutine inside python
In-Reply-To: <199704301854.MAA25362@typhoon.> (hrc@monsoon.colorado.edu)
Message-ID: <199704301934.VAA28087@lmspc2.ibs.fr>

>      Is there any way that I can call FORTRAN (prefer f90) subroutines inside
> a python program?  Thanks!

Yes, but how to do it depends on your machine/compiler. You will have
to check the manual of your Fortran compiler for a description of
interfacing with C.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                          | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------

_______________
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
_______________