Mailing List Archive: Python: Dev

Infix operators

Index | Next | Previous | View Threaded

loisel at temple

Jul 23, 2008, 2:14 PM

Post #1 of 22 (1297 views)
Permalink

Infix operators

Dear Pythonistas,

I've googled for this but I wasn't able to find anything definitive. I was
recently looking at scipy to see if I could use it in stead of MATLAB for my
class on numerical PDEs, but I noticed that there's some difficulty related
to the notation; mainly, the matrix multiplication, and the linear solver
(i.e., MATLAB's \ operator). After giving it some thought, I've decided to
hold back for now and use MATLAB.

Since scipy/numeric python have been around for a while and some of it is
even integrated in Python 2.5, I'm sure this conversation has happened
before, so please just educate me. Now I think that there's always going to
be people wanting more and more operators in Python (although the operators
I'm talking about are privileged -- the Chinese were using matrices some
2000 years ago), so I was thinking that it would be simpler to have a way
for defining new infix operators, which would simply be binary functions
whose names are punctuation marks; see any language with this feature, e.g.,
Haskell.

Now since this is such a simple idea, I'm guessing it occured to pythonistas
at some point in 1992, and got voted down and that decision has now become
scripture. Is that the case?

The one thing which I found was PEP 211
http://www.python.org/dev/peps/pep-0211/, which has an amazing quote from
James Rawlings. His comment about inv is completely absurd, and while he
claims not to know \ and /, he is quoted as an authority on these operators.
This particular PEP should probably be deleted from history. For a more
authoritative explanation, a quick search yields MathWorks' own Loren Shure:
http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/

Essentially, in almost all applications, inv(A) is entirely wrong. You can
ask any numerical analyst who works with large problems, and they will
confirm it. One of the main reason is that, even if A is sparse, inv(A) is
full.

That absurdity aside, if I were a language designer, I would be reticent to
add one operator to Python (like in PEP 211), because there will always be
more operators that people want (how long until someone asks for an operator
for the Kronecker product or the convolution?) But why not put in this infix
possibility?

Sincerely,

--
Sébastien Loisel

josiah.carlson at gmail

Jul 23, 2008, 4:11 PM

Post #2 of 22 (1261 views)
Permalink

Re: Infix operators [In reply to]

On Wed, Jul 23, 2008 at 2:14 PM, Sebastien Loisel <loisel [at] temple> wrote:
> Dear Pythonistas,
>
> I've googled for this but I wasn't able to find anything definitive. I was
> recently looking at scipy to see if I could use it in stead of MATLAB for my
> class on numerical PDEs, but I noticed that there's some difficulty related
> to the notation; mainly, the matrix multiplication, and the linear solver
> (i.e., MATLAB's \ operator). After giving it some thought, I've decided to
> hold back for now and use MATLAB.
>
> Since scipy/numeric python have been around for a while and some of it is
> even integrated in Python 2.5, I'm sure this conversation has happened
> before, so please just educate me. Now I think that there's always going to
> be people wanting more and more operators in Python (although the operators
> I'm talking about are privileged -- the Chinese were using matrices some
> 2000 years ago), so I was thinking that it would be simpler to have a way
> for defining new infix operators, which would simply be binary functions
> whose names are punctuation marks; see any language with this feature, e.g.,
> Haskell.
>
> Now since this is such a simple idea, I'm guessing it occured to pythonistas
> at some point in 1992, and got voted down and that decision has now become
> scripture. Is that the case?
>
> The one thing which I found was PEP 211
> http://www.python.org/dev/peps/pep-0211/, which has an amazing quote from
> James Rawlings. His comment about inv is completely absurd, and while he
> claims not to know \ and /, he is quoted as an authority on these operators.
> This particular PEP should probably be deleted from history. For a more
> authoritative explanation, a quick search yields MathWorks' own Loren Shure:
> http://blogs.mathworks.com/loren/2007/05/16/purpose-of-inv/
>
> Essentially, in almost all applications, inv(A) is entirely wrong. You can
> ask any numerical analyst who works with large problems, and they will
> confirm it. One of the main reason is that, even if A is sparse, inv(A) is
> full.
>
> That absurdity aside, if I were a language designer, I would be reticent to
> add one operator to Python (like in PEP 211), because there will always be
> more operators that people want (how long until someone asks for an operator
> for the Kronecker product or the convolution?) But why not put in this infix
> possibility?

Why not add the possibility for arbitrary infix operators? Others
will most likely disagree with me, but I would claim that adding
arbitrary infix operators are a great way to destroy readability.
What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's
a custom infix operator. But where is it defined? In the module? In
some other module that is imported? Can I override or do some
pre-processing to the arguments and pass it on to the previously
defined $ operator? So many questions, none of which tell me what '$'
does.

Really though, PEP 211 was a perfect example of a k-line function that
someone attempted to make syntax that really didn't need to be syntax.
And arguably, any infix operator will need to result in a lookup for
the new infix operator, which will be as fast (or slow) as a globals
lookup, so you may as well define your operator as a two-argument
function, which has defined semantics, and can be imported and passed
just like all functions defined for years.

I would argue current operators are *convenience* for the 99%+
majority of "mathematical" operations done in Python, with
well-defined and understood semantics in the 99%+ cases they are used
for. Further, the addition of further infix operators are, strictly
speaking, a domain-specific language, which Python (as a language)
doesn't frown upon, but doesn't encourage either.

If you still think that X \ Y would honestly make Python a better
language, I would ask you if logix
(http://www.livelogix.net/logix/intro.html) would suit you better. It
seems to allow you to use arbitrary punctuation for operators.

- Josiah
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

loisel at temple

Jul 23, 2008, 4:48 PM

Post #3 of 22 (1256 views)
Permalink

Re: Infix operators [In reply to]

Dear Josiah,

Thank you for your email.

On Wed, Jul 23, 2008 at 7:11 PM, Josiah Carlson <josiah.carlson [at] gmail>
wrote:

> What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's
> a custom infix operator. But where is it defined? In the module? In
> some other module that is imported? Can I override or do some
> pre-processing to the arguments and pass it on to the previously
> defined $ operator? So many questions, none of which tell me what '$'
> does.
>

My question is really what the history of this thing is and what sort of
opposition there is to this idea, in the python community. From your email,
I suspect that this conversation has already taken place.

I'm not going to become a python developer/politician and try to push this,
my job involves teaching and research in mathematics and the programming
language is just a tool. If I want to "put food on my family" (in the words
of a wise man), I can't really spend a whole lot of time on this mailing
list debating this.

However, just for posterity (and I'm not going to pursue the argument
further than this), I'll say this. The problem of determining the meaning
(or overridability or whatever) of x=4$6 is the same as the problem of
determining the meaning of x=fooz(4,6). Since it's not a good argument
against user-defined functions, I don't see it as a good argument against
user-defined operators. Of course, obviously the LISP people have decided
that fooz(4,6) (or rather, (fooz 4 6)) is okay, and 4$6 is not, so who am I
to dispute that.

> If you still think that X \ Y would honestly make Python a better

Well, I'm not arguing for adding one more special-purpose operator, because
probably the need for more operators will never end. If arbitrary operators
were defined like ordinary functions, they could be brought in with the
import numeric or whatever, and docstrings could be looked up, etc...

>
> language, I would ask you if logix
> (http://www.livelogix.net/logix/intro.html) would suit you better. It
> seems to allow you to use arbitrary punctuation for operators.
>

Thank you for the pointer. I have taken a look and it does look interesting,
on first blush I would love to use that language. The main thing is that I
worry about being out on the fringe, using a language that nobody uses, and
which may get abandoned without warning (like Sun abandoned `self'), or be
buggier just because people don't use it... Although I love metaprogramming
and I would use it if it were in python, I don't really need to go that far
(arbitrary infix operators would suffice to me.)

Sincerely,

--
Sébastien Loisel

curt at hagenlocher

Jul 23, 2008, 5:08 PM

Post #4 of 22 (1252 views)
Permalink

Re: Infix operators [In reply to]

On Wed, Jul 23, 2008 at 4:48 PM, Sebastien Loisel <loisel [at] temple> wrote:
>
> On Wed, Jul 23, 2008 at 7:11 PM, Josiah Carlson <josiah.carlson [at] gmail>
> wrote:
>>
>> language, I would ask you if logix
>> (http://www.livelogix.net/logix/intro.html) would suit you better. It
>> seems to allow you to use arbitrary punctuation for operators.
>
> Thank you for the pointer. I have taken a look and it does look interesting,
> on first blush I would love to use that language. The main thing is that I
> worry about being out on the fringe, using a language that nobody uses, and
> which may get abandoned without warning (like Sun abandoned `self'), or be
> buggier just because people don't use it...

Have you considered OCaml? (http://en.wikipedia.org/wiki/Ocaml) It's
in reasonably broad use and is actively maintained, and it allows
user-defined infix operators.

A programming language can't be all things to all people. That's why
there's room in the world for more than one.

--
Curt Hagenlocher
curt [at] hagenlocher
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

loisel at temple

Jul 23, 2008, 5:21 PM

Post #5 of 22 (1258 views)
Permalink

Re: Infix operators [In reply to]

Dear Curt,

Thank you for your email.

Have you considered OCaml? (http://en.wikipedia.org/wiki/Ocaml) It's
>

I have. I've considered a lot of languages, but OCaml isn't for me. My
current language is MATLAB. Python is pretty close in syntax, and it's
widely accepted, so you can teach students Python and they can go out and
use it. You can also publish a paper and write a code snippet without having
to explain the syntax. I'm not trying to go out on the blistering leading
edge of computer language sophistication; that would not be good for my
students, and it would not be good for my research.

For most of my programs, what I need is a language where you don't need to
give types or declare variables, because that just takes up space and
obscures the math. So I need a mainstream dynamic language like Python or
MATLAB.

OCaml is not dynamic, and linear algebra in OCaml is a pain in the neck
because of the explosion of the number of operators for various pairs of
operand types.

Sincerely,

--
Sébastien Loisel

greg.ewing at canterbury

Jul 23, 2008, 7:05 PM

Post #6 of 22 (1259 views)
Permalink

Re: Infix operators [In reply to]

Sebastien Loisel wrote:

> Essentially, in almost all applications, inv(A) is entirely wrong. You
> can ask any numerical analyst who works with large problems, and they
> will confirm it. One of the main reason is that, even if A is sparse,
> inv(A) is full.

This argues for a function such as solve(A, b). It
doesn't argue for an infix operator.

> But why not put in this infix possibility?

Guido is on record as opposing any kind of macros
or other "extensible syntax", and this probably comes
under the same heading.

Besides which there are technical difficulties, such
as how the parser is supposed to know the precedence
of these user-defined operators.

To address your original problem, I believe that numpy
comes with a matrix type that defines * as matrix
multiplication. That's the usual Python solution to
these kinds of things -- rather than invent a new
operator, invent a new type that behaves the way
you want.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

loisel at temple

Jul 23, 2008, 7:28 PM

Post #7 of 22 (1253 views)
Permalink

Re: Infix operators [In reply to]

Dear Greg,

Thanks for your email.

Guido is on record as opposing any kind of macros
> or other "extensible syntax", and this probably comes
> under the same heading.
>

Thanks, that's exactly what I was looking for when I asked:

Now since this is such a simple idea, I'm guessing it occured to pythonistas
> at some point in 1992, and got voted down and that decision has now become
> scripture. Is that the case?
>

Case closed.

Sincerely,

--
Sébastien Loisel

PS:

This argues for a function such as solve(A, b). It
> doesn't argue for an infix operator.
>

I know, I was demolishing PEP 211, not trying to support my point.

greg.ewing at canterbury

Jul 23, 2008, 8:21 PM

Post #8 of 22 (1257 views)
Permalink

Re: Infix operators [In reply to]

Josiah Carlson wrote:
> What the heck does 'x = 4 $ 6' mean in Python? Oh, that's right, it's
> a custom infix operator. But where is it defined?

It's not quite as bad as that -- it would be defined by
the relevant operator method on one of the operands. But
a convention would be needed for mapping arbitary non-
alphanumeric sequences to method names, and it's not
obvious how to do that.

But the main technical problem I see is that of precedence.
It would have to be declared somehow, or a declaration
imported from another module. If it's imported, then
parsing a module can't be done in isolation any more,
since it depends on the contents of other modules.
Things could get very messy.

> Really though, PEP 211 was a perfect example of a k-line function that
> someone attempted to make syntax that really didn't need to be syntax.

It looks like a case of someone wanting a matrix multiplication
operator in numpy, and then hunting around for something to
make it mean in Python.

I would actually be in favour of adding a matrix multiplication
operator, but I would make it mean matrix multiplication in
Python as well, operating on anything that can be treated as
a 2D sequence.

Why matrix multiplication in particular? Because it's the one
thing that you do all the time with matrices for which there
isn't an available operator. I think this one addition could
be justified on the grounds of very wide usage.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

aahz at pythoncraft

Jul 23, 2008, 9:03 PM

Post #9 of 22 (1260 views)
Permalink

Re: Infix operators [In reply to]

On Wed, Jul 23, 2008, Sebastien Loisel wrote:
>
> [...] I was thinking that it would be simpler to have a way
> for defining new infix operators, [...]

python-dev is the wrong place for this discussion. Please use either
comp.lang.python or python-ideas.
--
Aahz (aahz [at] pythoncraft) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

loisel at temple

Jul 24, 2008, 2:19 PM

Post #10 of 22 (1227 views)
Permalink

Re: Infix operators [In reply to]

Greg Ewing said:

> I would actually be in favour of adding a matrix multiplication
> operator

That would be helpful to me, for my students as well as my papers.

Sincerely,

--
Sébastien Loisel
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

scott+python-dev at scottdial

Jul 24, 2008, 3:06 PM

Post #11 of 22 (1240 views)
Permalink

Re: Infix operators [In reply to]

Sebastien Loisel wrote:
> Greg Ewing said:
>> I would actually be in favour of adding a matrix multiplication
>> operator
>
> That would be helpful to me, for my students as well as my papers.
>

Perhaps I'm nobody, but I think this would be ridiculous. Matrices are
not native objects to the language. There is no type(matrix). The notion
of what makes a Python object a matrix is a convention and to have
built-in operators dedicated to such objects makes no sense. There are
multiple ways to stuff matrices into Python. Please submit a PEP for a
type(matrix) first. Until a matrix is a first-order object in Python,
there is no logic to making operators for them.

-Scott

--
Scott Dial
scott [at] scottdial
scodial [at] cs
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

fredrik.johansson at gmail

Jul 24, 2008, 5:02 PM

Post #12 of 22 (1232 views)
Permalink

Re: Infix operators [In reply to]

On Fri, Jul 25, 2008 at 12:06 AM, Scott Dial
<scott+python-dev [at] scottdial> wrote:

> Perhaps I'm nobody, but I think this would be ridiculous. Matrices are
> not native objects to the language. There is no type(matrix). The notion
> of what makes a Python object a matrix is a convention and to have
> built-in operators dedicated to such objects makes no sense. There are
> multiple ways to stuff matrices into Python. Please submit a PEP for a
> type(matrix) first. Until a matrix is a first-order object in Python,
> there is no logic to making operators for them.

Though I would personally find a matrix multiplication operator
useful, I have to agree with this.

Anyway, it is easy to define pseudo-operators in Python; just create
an Operator class and implement its __mul__ and __rmul__ methods
appropriately (there are recipes for this around somewhere). Then you
can define various custom multiplication operators with syntax like
this:

A *matrixmul* B
A *dot* B
A *cross* B
A *elementwise* B

Some other fun possibilities:

A +concat+ B
A /solve/ B
A **left_inverse** (-1)
A **right_inverse** (-1)
x **tetrate** y
n |choose| k

Fredrik
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Jul 24, 2008, 7:02 PM

Post #13 of 22 (1232 views)
Permalink

Re: Infix operators [In reply to]

Scott Dial wrote:

> Perhaps I'm nobody, but I think this would be ridiculous. Matrices are
> not native objects to the language.

Why should that matter? We already have things like
sum(), which operates on any sequence of numbers,
without needing a special "array of numbers" data
type. I don't see why one shouldn't be able to
perform matrix multiplication on a plausible
representation of a matrix using the existing
built-in sequence types.

> Until a matrix is a first-order object in Python,
> there is no logic to making operators for them.

If there were a dedicated matrix type, there would
actually be *less* reason to have a new operator,
since that type could just implement * as matrix
multiplication.

However, there are disadvantages to that, which
become apparent when numpy is considered. There are
good reasons for wanting * to mean elementwise
multiplication of numpy arrays. There are also
good reasons for wanting to use numpy arrays as
matrices, since you get the benefit of all the
other powerful things that numpy can do with
arrays.

You can use a matrix type that's based somehow
on a numpy array, but there are problems with that
too. E.g. if you add a matrix and a plain numpy
array, what type should the result be? If plain
numpy arrays can be used directly as matrices, that
problem goes away.

--
Greg

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Jul 24, 2008, 7:08 PM

Post #14 of 22 (1236 views)
Permalink

Re: Infix operators [In reply to]

Fredrik Johansson wrote:

> Anyway, it is easy to define pseudo-operators in Python;
>
> A *matrixmul* B
> A *dot* B
> A *cross* B
> A *elementwise* B

Urg. This is another one of those recipes that I consider
is too clever for its own good. Very nice in theory,
but I would never use it in real life.

What's more, it doesn't address the real problem at hand,
which is providing a notation for matrix multiplication
that is concise enough to be used *very* frequently --
like multiple times in every line of code that manipulates
matrices.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

scott+python-dev at scottdial

Jul 24, 2008, 7:46 PM

Post #15 of 22 (1234 views)
Permalink

Re: Infix operators [In reply to]

Greg Ewing wrote:
> Scott Dial wrote:
>> Perhaps I'm nobody, but I think this would be ridiculous. Matrices are
>> not native objects to the language.
>
> Why should that matter? We already have things like
> sum(), which operates on any sequence of numbers,
> without needing a special "array of numbers" data
> type.

I would argue that Python contains a "array of some_type" data type.
That sum() performs a left-fold of __add__ on the array is completely
independent of them being numbers. In all fact, they could be any type
that supports __add__/__radd__ or even a mix of types. I do not believe
"array of numbers" to be analogically equivalent to a "matrix of
numbers". We have an "array of" type in Python, we do not have a "matrix
of" type in Python. sum() is not an operator, it is a builtin; the
suggestion was for there to be an operator, not a builtin. If you want
to suggest there be a mmul() builtin, then perhaps there is a viable
answer there, despite the lack of a "matrix of" type still.

> I don't see why one shouldn't be able to
> perform matrix multiplication on a plausible
> representation of a matrix using the existing
> built-in sequence types.

What is "a plausible representation of a matrix"? Is it a list of lists?
Row-major (m[1][2]) or column-major (m[2][1])? Is it a dictionary of
tuple'd indices (m[1,2])? Also, You went on to talk about wanting to
using numpy.array.

How does this not make it clear that there is not a case of TOOWTDI?

-Scott

--
Scott Dial
scott [at] scottdial
scodial [at] cs
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

josiah.carlson at gmail

Jul 24, 2008, 7:47 PM

Post #16 of 22 (1225 views)
Permalink

Re: Infix operators [In reply to]

On Thu, Jul 24, 2008 at 7:08 PM, Greg Ewing <greg.ewing [at] canterbury> wrote:
> Fredrik Johansson wrote:
>
>> Anyway, it is easy to define pseudo-operators in Python;
>>
>> A *matrixmul* B
>> A *dot* B
>> A *cross* B
>> A *elementwise* B
>
> Urg. This is another one of those recipes that I consider
> is too clever for its own good. Very nice in theory,
> but I would never use it in real life.

That's unfortunate ;), because it's available in Python today, and
with the common local caching of globals, can be as short as 3
characters (M for matrixmul, D for dot, X for cross, E for
elementwise).

> What's more, it doesn't address the real problem at hand,
> which is providing a notation for matrix multiplication
> that is concise enough to be used *very* frequently --
> like multiple times in every line of code that manipulates
> matrices.

This is the first time anyone has mentioned "conciseness" in this
thread. And what's a 3 character operator between friends? The "and"
and "not" operators don't seem to be bothered by three characters. ;)

- Josiah
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Jul 24, 2008, 10:27 PM

Post #17 of 22 (1221 views)
Permalink

Re: Infix operators [In reply to]

Scott Dial wrote:

> I would argue that Python contains a "array of some_type" data type.
> That sum() performs a left-fold of __add__ on the array is completely
> independent of them being numbers.

That's not strictly true -- it explicitly refuses to operate
on strings (or at least it did last time I heard). Guido has
said that he *intends* it to only be used for numbers, even
if it happens to accidentally do something with other types.

However, as I envisage it, the @ operator wouldn't be
restricted to numbers either -- it would do whatever the
* and + operations do on the elements.

> sum() is not an operator, it is a builtin; the
> suggestion was for there to be an operator, not a builtin.

That's true, and it means that the built-in implementation
wouldn't have as wide applicability as the sum() function,
since it would be restricted to lists and tuples (and
perhaps array.array instances). But I don't think that's a
fatal flaw -- if you create your own sequence type, you
have to take steps if you want to be able e.g. to use +
to concatenate them, and nobody complains about that.

> If you want
> to suggest there be a mmul() builtin, then perhaps there is a viable
> answer there

No, that's not a viable answer to people who want a matrix
multiplication operator. They want an operator because a
function is nowhere near concise enough. Telling these
people they have to use a function to multiply matrices
is like telling them they have to use a function to
multiply numbers.

> What is "a plausible representation of a matrix"? Is it a list of lists?

That's one. A tuple of tuples would be another.

> Row-major (m[1][2]) or column-major (m[2][1])?

Pick one and stick to it. Probably row-major, since it's
what the numpy matrixmultiply function uses.

> Is it a dictionary of tuple'd indices (m[1,2])?

I think dictionaries would have to be excluded, because
there's no easy way of finding out the dimensions, it's
not obvious what to do about missing elements, etc.

> Also, You went on to talk about wanting to using numpy.array.

Yes -- what's wrong with that?

> How does this not make it clear that there is not a case of TOOWTDI?

I think there *is* one obvious way of representing a matrix,
or any 2D array, using built-in Python types, or rather two
ways -- a list of lists if you want mutability, or a tuple
of tuples if you want immutability.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Jul 24, 2008, 10:30 PM

Post #18 of 22 (1221 views)
Permalink

Re: Infix operators [In reply to]

Josiah Carlson wrote:

> This is the first time anyone has mentioned "conciseness" in this
> thread.

I thought it more or less went without saying. After
all, if conciseness isn't a goal, there's nothing
wrong with a plain function call, which can be as short
as 3 characters as well.

The trouble is that, for the people who badly want
a matrix multiplication operator, 3 characters is
far too long!

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Jul 26, 2008, 1:23 AM

Post #19 of 22 (1174 views)
Permalink

Re: Infix operators [In reply to]

Sebastien Loisel wrote:
> However, just for posterity (and I'm not going to pursue the argument
> further than this), I'll say this. The problem of determining the
> meaning (or overridability or whatever) of x=4$6 is the same as the
> problem of determining the meaning of x=fooz(4,6). Since it's not a good
> argument against user-defined functions, I don't see it as a good
> argument against user-defined operators.

The namespace of usefully mnemonic function names is infinitely larger
than that of usefully mnemonic punctuation marks. User-defined functions
are good, but once you have those there is no reason to have
user-defined operators *as well*.

Cheers,
Nick.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

charleshixsn at earthlink

Jul 27, 2008, 10:43 AM

Post #20 of 22 (1139 views)
Permalink

Re: Infix operators [In reply to]

On Saturday 26 July 2008 01:23:17 am Nick Coghlan wrote:
> Sebastien Loisel wrote:
> > However, just for posterity (and I'm not going to pursue the argument
> > further than this), I'll say this. The problem of determining the
> > meaning (or overridability or whatever) of x=4$6 is the same as the
> > problem of determining the meaning of x=fooz(4,6). Since it's not a good
> > argument against user-defined functions, I don't see it as a good
> > argument against user-defined operators.
>
> The namespace of usefully mnemonic function names is infinitely larger
> than that of usefully mnemonic punctuation marks. User-defined functions
> are good, but once you have those there is no reason to have
> user-defined operators *as well*.
>
> Cheers,
> Nick.
>
Most mathematicians would disagree with you. I'll grant that it tends to make
the code extremely obscure to those who don't work in the field, but it tends
to make it much clearer to those who do so work.

OTOH, it's also true that there aren't sufficient punctuation symbols. E.g.
math people drafted capital sigma as sum of a series, etc.

Therefore it seems to me that the appropriate thing is to create a convention
that bar-somethingprintable-bar should be interpreted as a user defined
operation, e.g. |+| or |@#|. The first one is reasonable as matrix
multiplication, the second as some user defined operation that hasn't yet
been specified (in this context). And since such things don't yet have
a "secret name" I would suggest that they be defined either via an ordinary
def, or via a def with their name in quotes, i.e., either:
def |+| or def "|+|"

If an ordinary functional reference is desireable (probably) there could be a
decorators that assigned the name, and possibly the precedence, e.g.:
@name=madd
@precedence="+"
def |+| (a, b):
etc.

The main drawback that I see is that code that relies heavily on this approach
would become much less readable to anyone not in the particular field. Think
of the first time you encountered the curl or del operators, or even the
kronecker delta.

OTOH, it seems far too late in the development process to be inserting such a
change in Python 2.6 or 3.0. If this is important to you, you should
probably propose it for 2.7/3.1.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

regebro at gmail

Jul 27, 2008, 11:18 AM

Post #21 of 22 (1143 views)
Permalink

Re: Infix operators [In reply to]

On Sun, Jul 27, 2008 at 19:43, Charles Hixson
<charleshixsn [at] earthlink> wrote:
> Therefore it seems to me that the appropriate thing is to create a convention
> that bar-somethingprintable-bar

And the "something-printable" shows the main flaw of this approach.
Mathematics indeed uses a lot of symbols to make things clear and
unambigous. Many of these are hard to print in a line, even with
unicode, and entering and editing this from a keyboard would be very
difficult. So to make this scheme useable you would have to limit
yourself to ascii-codes, and then most of the point goes away since
you can't use the proper symbols anyway, and ambiguity is
reintroduced.

It seems to me that mathematicians who need these things would be
better served by dedicated maths-software.

Just my 2 cents.

--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

steve at holdenweb

Jul 27, 2008, 2:42 PM

Post #22 of 22 (1136 views)
Permalink

Re: Infix operators [In reply to]

Charles Hixson wrote:
[...]
> OTOH, it seems far too late in the development process to be inserting such a
> change in Python 2.6 or 3.0. If this is important to you, you should
> probably propose it for 2.7/3.1.

It's been too late for over three months now, and the suggestions I've
seen so far are all way impractical anyway.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads