>
Fixed. Bug in my makefile.
--david
=================
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 Oct 23 10:13:11 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 23 Oct 96 10:13:11 +0100
Subject: [PYTHON MATRIX-SIG] Final (hopefully) alpha release available
In-Reply-To: <199610222021.QAA17378@python.org> (tim@lassi.ece.uiuc.edu)
Message-ID: <199610230918.KAA08295@ibs.ibs.fr>
> either. However, it seems like A == B, and A != B are perfectly valid
> matrix expressions that should evaluate to true and false respectively
> if A and B are the same shape and have equal values. In other words,
> A == B <=> A.shape == B.shape and and.reduce(equal(ravel(A), ravel(B))).
>
> Yes? No?
If you ask me, yes! And of course it is possible. Here is the
definition of __cmp__ of my tensor class, which is basically
a wrapper around a special kind of array:
def __cmp__(self, other):
if self.rank != other.rank:
return 1
else:
return not umath.logical_and.reduce(
umath.equal(self.array, other.array).flat)
In this case, self.rank completely specifies shape, so it doesn't have
to be compared separately.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 Oct 23 14:27:43 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Wed, 23 Oct 96 14:27:43 +0100
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
Message-ID: <199610231333.OAA09920@ibs.ibs.fr>
Reading David's excellent tutorial has made me aware of a few
peculiarities that I had forgotten, and which should be cleaned
up before the beta release:
1) where() is just a special case of choose() and should be
eliminated.
2) compress() is just a special case of repeat() and should be
eliminated.
3) binarysearch() should be called just search(), or find().
The name of a function should not indicate the algorithm
that is uses, however obvious the choice of the algorithm
is.
4) I am a bit confused about the exact meaning of the parameters
to diagonal() and trace(). Shouldn't that simply be to integers,
indicating the two axes along which the diagonal is constructed,
and defaulting to -2 and -1?
5) There's dot() and matrixmultiply(). Dot() does something for which
I have never found a direct need, and which anyway should not be
called dot() because it doesn't work like what linear algebra
users expect dot() to mean. How about having just dot() with a
useful generalization of the dot product, i.e. summing along
the last axis of the first and the first axis of the second argument?
(I think we have discussed this before, but I don't remember details...)
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 fredrik_lundh@ivab.se Wed Oct 23 14:23:43 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Wed, 23 Oct 1996 15:23:43 +0200
Subject: [PYTHON MATRIX-SIG] Last complaints about NumPy 1.0a5
In-Reply-To: <199610231333.OAA09920@ibs.ibs.fr> (message from Konrad Hinsen on
Wed, 23 Oct 96 14:27:43 +0100)
Message-ID: <9610231323.AA06667@arnold.image.ivab.se>
> binarysearch() should be called just search(), or find().
> The name of a function should not indicate the algorithm
> that is uses, however obvious the choice of the algorithm
> is.
To me, "binarysearch" implies that data must be sorted beforehand,
while a "search" function wouldn't bother about such issues (compare
bsearch and lsearch in the standard C library).
Maybe a better name, but not as generic as "search".
/F (just an ordinary programmer)
=================
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 Wed Oct 23 19:07:19 1996
From: hugunin@mit.edu (Jim Hugunin)
Date: Wed, 23 Oct 1996 14:07:19 -0400
Subject: [PYTHON MATRIX-SIG] Problems building alpha5 (Linux)
Message-ID: <9610231812.AA03290@goldilocks.LCS.MIT.EDU>
> From: Oliver Gathmann ** It seems to me that one of the reasons APL never made it was that it
> insisted on talking its own language which was internally self-consistent
> but had little to do with any language talked by others. Conversely,
> Matlab, with its horrid "bad Fortran" syntax, is very popular in part
I suppose APL's main problem was the use of a special character set.
Even modern GUIs don't solve all the difficulties associated with
it. Look at comp.lang.apl to see what people are doing to publish
APL code on Usenet - it's a mess!
> because it never strays really far from standard notation. If we are to
> sell NumPy to users, shouldn't we try to make the operators mean what
> typical users will expect them to mean, or will learn that they mean in
> mathematics courses, rather than defining them to be something completely
> different?
I agree, but there's no way to do that with Python 1.4. And perhaps
not even with Python 1.5 or whatever comes next.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 fredrik_lundh@ivab.se Fri Oct 25 13:50:46 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Fri, 25 Oct 1996 14:50:46 +0200
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251301.OAA20153@ibs.ibs.fr> (message from Konrad Hinsen on
Fri, 25 Oct 96 13:55:38 +0100)
Message-ID: <9610251250.AA25848@arnold.image.ivab.se>
Konrad writes:
> Of course the best solution would be to give up this strategy and
> implement all the comparison operators independently. With some
> effort that could even be done in a backwards compatible way (i.e.
> using the old strategy for types defining cmp()).
Agreed. I have several applications where such a change would be
really useful (like using Python classes to build expression trees for
later execution within subsystems; operations on images, for example).
> But that is far from a trivial change.
Not sure about that, really (thought it might add some overhead for
classes that only implements __cmp__). Is definitely worth
investigating for 1.5.
Regards /F
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From fredrik_lundh@ivab.se Fri Oct 25 13:50:46 1996
From: fredrik_lundh@ivab.se (Fredrik Lundh)
Date: Fri, 25 Oct 1996 14:50:46 +0200
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251301.OAA20153@ibs.ibs.fr> (message from Konrad Hinsen on
Fri, 25 Oct 96 13:55:38 +0100)
Message-ID: <9610251250.AA25848@arnold.image.ivab.se>
Konrad writes:
> Of course the best solution would be to give up this strategy and
> implement all the comparison operators independently. With some
> effort that could even be done in a backwards compatible way (i.e.
> using the old strategy for types defining cmp()).
Agreed. I have several applications where such a change would be
really useful (like using Python classes to build expression trees for
later execution within subsystems; operations on images, for example).
> But that is far from a trivial change.
Not sure about that, really (thought it might add some overhead for
classes that only implements __cmp__). Is definitely worth
investigating for 1.5.
Regards /F
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From tim@lassi.ece.uiuc.edu Fri Oct 25 14:27:46 1996
From: tim@lassi.ece.uiuc.edu (tim@lassi.ece.uiuc.edu)
Date: Fri, 25 Oct 1996 08:27:46 -0500
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
(message from Alistair Mees on Fri, 25 Oct 1996 18:13:36 +0800)
Message-ID: <199610251323.JAA27023@python.org>
> = Alistair Mees
> > = Tim Hochberg
<...>
> > The problem is that __cmp__ can only validly return an integer. Notice
> > that for your first example that am array might be neither >=0 nor <0
> > ([1,-1] comes to mind), so there's really no valid value to return.
>That is not a problem. The answer to "is [1,-1]>=0" is "no" so you return
>0, as you do for the comparisons [1,-1]<=0, [1,-1]>0 and [1,-1]<0. These
>are standard elementary results! Likewise, if we are working with
>symmetric matrices then A>=B and A<=B can both return 0 (since they are
>equivalent to A-B>=0 and A-B<=0, neither of which might be true if we
>decide to define the inequalities to be statements about positive
>semidefiniteness.
I don't entirely disagree that this is a reasonable solution in
principle, although I tend to think the correct answer to [-1,1]>=0 is
"undefined" and so you should get an exception.
However, the comparison operators (<=, >, etc.) are just veneer on top
of __cmp__ (or tp_compare for C classes). If I do cmp(a,b) I get back
an integer: if its positive, >, >=, and != return true, if 0, ==, >=,
<= return true and if negative, <, <=, or != return true.
For cmp([1,-1],0) I want >, >=, <, and <= to raise an exception (or be
false for your semantics), I want == to be false, and != to be
true. What integer do you return for that? None ;) (at least in the
future - hopefully)
With the patch I'm working on, returning None in Python or INT_MIN
(sorry) in C will tell the veneer that the objects compared are not
equal but don't have an ordering. (This is in general, not just for
the Numerics extension.) This could be used to either raise an
exception if you try to order them or to return false for all the
ordering operators (<,<=,>,>=). However, I much prefer the former, if
you want to make questionable comparisons you should have to do it
explicitly!!
--
-tim
+--------------------------------------------------------------------+
| Tim Hochberg Ultrahigh Speed Digital Electronics Lab |
| tim@lassi.ece.uiuc.edu University of Illinois |
| http://dogbert.ece.uiuc.edu/~tim (217) 333-6014 |
+--------------------------------------------------------------------+
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From mclay@nist.gov Fri Oct 25 09:48:38 1996
From: mclay@nist.gov (Michael McLay)
Date: Fri, 25 Oct 1996 04:48:38 -0400
Subject: [PYTHON MATRIX-SIG] arrays from text?
In-Reply-To: <199610250950.KAA19003@ibs.ibs.fr>
References: <199610250019.AA171292774@london.ks.uiuc.edu>
<199610250950.KAA19003@ibs.ibs.fr>
Message-ID: <199610250848.EAA05050@fermi.eeel.nist.gov>
Konrad Hinsen writes:
> > Is there a way to (quickly) generate an array of numbers from an array of
> > their string representations? More specifically, if I have an array a of Char
> > in which each row contains a printed representation of a Float, is there a
> > faster way to get an array of Floats than the following?
> >
> > array(map(lambda b: string.atof(b.tostring()), a))
>
> Nothing I know of, and even the map() solution get more complicated
> for arrays of higher rank. I do have a simple module that reads
> rank-1 and rank-2 arrays from files (and reads them), but in terms
> of efficiency it's even worse. I have decided more than once to do
> a C module, but of course I never found the time.
>
> > Even better would be the ability to use the equivalent of FORTRAN format
> > statements and implicit loops to read in several arrays of different types
> > simultaneously from either a Char array or a file. Anyone know how hard this
> > would be to do?
>
> Not too hard, but still a lot of work. Especially since I want such
> a module to be able to read all reasonable representations for numbers,
> including Fortran double precision (with a D instead of an E) and
> Mathematica format (e.g. 2.5*10^3).
How about ftp://ftp.python.org/pub/python/contrib/Misc/sscanfmodule.c.
It probably needs to be modified to read in arrays. I think it just
returns tuples that correspond to the parse string.
> > Of course, the reason for doing this is that with array operations as fast as
> > they are, the bottleneck in many programs will be the time needed to read in
> > text files, which won't be any faster.
>
> And that is exactly my observation in practice. I/O is frustratingly
> slow!
>
> Konrad.
> --
> -------------------------------------------------------------------------------
> Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
> Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
> Institut de Biologie Structurale | Fax: +33-76.88.54.94
> 41, av. des Martyrs | Deutsch/Esperanto/English/
> 38027 Grenoble Cedex 1, France | Nederlands/Francais
> -------------------------------------------------------------------------------
>
> =================
> MATRIX-SIG - SIG on Matrix Math for Python
>
> send messages to: matrix-sig@python.org
> administrivia to: matrix-sig-request@python.org
> =================
=================
MATRIX-SIG - SIG on Matrix Math for Python
send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================
From hinsen@ibs.ibs.fr Fri Oct 25 16:09:59 1996
From: hinsen@ibs.ibs.fr (Konrad Hinsen)
Date: Fri, 25 Oct 96 16:09:59 +0100
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <9610251250.AA25848@arnold.image.ivab.se> (message from Fredrik
Lundh on Fri, 25 Oct 1996 14:50:46 +0200)
Message-ID: <199610251515.QAA21237@ibs.ibs.fr>
> > But that is far from a trivial change.
>
> Not sure about that, really (thought it might add some overhead for
> classes that only implements __cmp__). Is definitely worth
> investigating for 1.5.
Of course. I expect the main problem to be types implemented in C.
They'd need new methods too, but in such a way that previously written
code would still work. But in my opinion it is worth even a major
effort.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@ibs.ibs.fr
Laboratoire de Dynamique Moleculaire | Tel.: +33-76.88.99.28
Institut de Biologie Structurale | Fax: +33-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 chris.chase@jhuapl.edu Fri Oct 25 16:07:06 1996
From: chris.chase@jhuapl.edu (Chris Chase SRM)
Date: Fri, 25 Oct 1996 11:07:06 -0400
Subject: [PYTHON MATRIX-SIG] ARRAY COMPARISONS
In-Reply-To: <199610251323.JAA27023@python.org>
References: <199610251013.SAA08608@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
<199610251323.JAA27023@python.org>
Message-ID: <199610251510.LAA27375@python.org>
>>>>> "tim" == tim writes:
>> = Alistair Mees
>> > = Tim Hochberg
tim> <...>
>> > The problem is that __cmp__ can only validly return an integer. Notice
>> > that for your first example that am array might be neither >=0 nor <0
>> > ([1,-1] comes to mind), so there's really no valid value to return.
>> That is not a problem. The answer to "is [1,-1]>=0" is "no" so you return
>> 0, as you do for the comparisons [1,-1]<=0, [1,-1]>0 and [1,-1]<0. These
>> are standard elementary results! Likewise, if we are working with
>> symmetric matrices then A>=B and A<=B can both return 0 (since they are
>> equivalent to A-B>=0 and A-B<=0, neither of which might be true if we
>> decide to define the inequalities to be statements about positive
>> semidefiniteness.
tim> I don't entirely disagree that this is a reasonable solution in
tim> principle, although I tend to think the correct answer to [-1,1]>=0 is
tim> "undefined" and so you should get an exception.
tim> However, the comparison operators (<=, >, etc.) are just veneer on top
tim> of __cmp__ (or tp_compare for C classes). If I do cmp(a,b) I get back
tim> an integer: if its positive, >, >=, and != return true, if 0, ==, >=,
tim> <= return true and if negative, <, <=, or != return true.
tim> For cmp([1,-1],0) I want >, >=, <, and <= to raise an exception (or be
tim> false for your semantics), I want == to be false, and != to be
tim> true. What integer do you return for that? None ;) (at least in the
tim> future - hopefully)
tim> With the patch I'm working on, returning None in Python or INT_MIN
tim> (sorry) in C will tell the veneer that the objects compared are not
tim> equal but don't have an ordering. (This is in general, not just for
tim> the Numerics extension.) This could be used to either raise an
tim> exception if you try to order them or to return false for all the
tim> ordering operators (<,<=,>,>=). However, I much prefer the former, if
tim> you want to make questionable comparisons you should have to do it
tim> explicitly!!
I agree with Tim's approach. Raise an exception when two objects are
not comparable.
The implicit assumption in Python seems to be that cmp() implements a
_complete_ partial order relation [a relation that is reflexive,
transitive, and anti-symmetric, and comparable: a <= b or b <= a].
Supporting a partial order relation [dropping comparable property]
requires an exception be produced by cmp().
For arrays (finite dimensional vector spaces) the natural partial
order was mentioned by Alstair Mess ( a >= b iff a-b > 0
componentwise). This partial order is an often used requirement in
many constrained optimization of convex functions. Other partial
orders might be defined (e.g. Alstair mentioned positive semidefinite
for matrices).
Certain operations like sorting assume a complete order relation (or a
"chain" which is a completely ordered subset of a partial ordered
set). Would it be a problem if an exception was generated inside
these kind of operations?
Chris
=================
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 Fri Oct 25 17:14:39 1996
From: furnish@laura.llnl.gov (Geoffrey Furnish)
Date: Fri, 25 Oct 1996 09:14:39 -0700
Subject: [PYTHON MATRIX-SIG] Array comparisons, and determinants
In-Reply-To: <199610251107.MAA19602@ibs.ibs.fr>
References: <199610250208.KAA07541@nuytsia.maths.uwa.edu.au.maths.uwa.edu.au>
<199610251107.MAA19602@ibs.ibs.fr>
Message-ID: <199610251616.MAA27563@python.org>
Konrad Hinsen writes:
> > Inequalities are often generalised to work for vectors and matrices. For
> > example, x>=0 where x is a vector means x[i]>=0 for every i.
>
> With such a definition, you could have an x for which both x > 0 and
> x <=0 0 are false. But the __cmp__ function has to decide cleanly
> between equal, greater, and less - there is nothing in between.
And Tim Hochberg writes:
> The problem is that __cmp__ can only validly return an integer. Notice
> that for your first example that am array might be neither >=0 nor <0
> ([1,-1] comes to mind), so there's really no valid value to return.
The original poster's request has a utility which I think is being
missed. The goal of expecting x >= 0 (or any other operator) to mean
x[i] >= 0 for every i, is not to get back a truth value, it is to get
back a boolean mask. Data parallel languages of many stripes and
colors have historically allowed constructs like
**