consistency: extending arrays vs. multiplication ?

[Soeren Sonnenburg]

Hi all,

Just having started with python, I feel that simple array operations '*'
and '+' don't do multiplication/addition but instead extend/join an
array:

a=[1,2,3]

b=[4,5,6]
a+b

[1, 2, 3, 4, 5, 6]

instead of what I would have expected:
[5,7,9]

or
[1, 2, 3, 1, 2, 3]

Well it is consistent to strings but tolerating string-operations to be
special is ok to me as "a" + "b" -> 'ab'
Why not make it another function like a.stretch() or a.expand() and
a.extend() is there doing the same anyway and is more readable...

Putting this in a larger view:
Ufuncs are very reasonable sin(a), etc ... all that won't work because
of that '+','*' syntax. Ok I can use numarray for that, but seeing its
PEP and a possible inclusion into python at some point that
inconsistency is giving me quite some headache...

Will that change in the future ? Or is this 100*[0] syntax put into
stone for all ages ?

Best,
Soeren.

PS: As I am very new to python please forgive/correct me!

 

[Marc 'BlackJack' Rintsch]

Just having started with python, I feel that simple array operations '*'
and '+' don't do multiplication/addition but instead extend/join an
array:

a=[1,2,3]

b=[4,5,6]
a+b

[1, 2, 3, 4, 5, 6]

Both operate on the lists themselves and not on their contents. Quite
consistent if you ask me.

Ciao,
Marc 'BlackJack' Rintsch

 

[Dan Bishop]

Hi all,

Just having started with python, I feel that simple array operations '*'
and '+' don't do multiplication/addition but instead extend/join an
array:

a=[1,2,3]

b=[4,5,6]
a+b

[1, 2, 3, 4, 5, 6]

instead of what I would have expected:
[5,7,9]

To get what you expected, use

[x + y for (x, y) in zip(a, b)]

 

[Steven D'Aprano]

Hi all,

Just having started with python, I feel that simple array operations '*'
and '+' don't do multiplication/addition but instead extend/join an
array:

* and + are not array operations, they are list operations.

Lists in Python can contain anything, not just numeric values.

Python doesn't have built-in mathematical arrays, otherwise known as
matrices. There are modules that do that, but I haven't used them. Google
on Numeric Python.

 

[Soeren Sonnenburg]

Just having started with python, I feel that simple array operations '*'
and '+' don't do multiplication/addition but instead extend/join an
array:

a=[1,2,3]

b=[4,5,6]
a+b

[1, 2, 3, 4, 5, 6]

Both operate on the lists themselves and not on their contents. Quite
consistent if you ask me.

But why ?? Why not have them operate on content, like is done on
*arrays ?

Soeren

 

[Soeren Sonnenburg]

* and + are not array operations, they are list operations.

Lists in Python can contain anything, not just numeric values.

That seems to be *the point*. Although list(a) + list(b) could create a
list [ a[0]+b[0], ...] and bail out if for elements '+' is not
defined...

Python doesn't have built-in mathematical arrays, otherwise known as
matrices. There are modules that do that, but I haven't used them. Google
on Numeric Python.

Well I am aware of that but I don't understand the reasons of having
both lists (which are infect arrays) and *arrays ? *I* would rather drop
'+' and '*' to work like they do in *array ...

Soeren

 

[Soeren Sonnenburg]

Hi all,

Just having started with python, I feel that simple array operations '*'
and '+' don't do multiplication/addition but instead extend/join an
array:

a=[1,2,3]

b=[4,5,6]
a+b

[1, 2, 3, 4, 5, 6]

instead of what I would have expected:
[5,7,9]

To get what you expected, use

[x + y for (x, y) in zip(a, b)]

Thanks for this suggestion, however I am interested in understanding the
design decision here... I could aswell just use numarray and get the
wanted a+b by:

from numarray import *
a=array([1,2,3])
b=array([1,2,3])
a+b
array([2, 4, 6])

Soeren

 

[Robert Kern]

That seems to be *the point*.

Whose point? If you mean that you want to be able to use arbitrary
objects in an array, then look in numarray.objects for an array type
that handles arbitrary Python objects.

Although list(a) + list(b) could create a
list [ a[0]+b[0], ...] and bail out if for elements '+' is not
defined...

Unlike the current situation, where a+b always works consistently
despite the contents, despite how long the lists are.

Well I am aware of that but I don't understand the reasons of having
both lists (which are infect arrays)

They "are in [fact] arrays" only in the sense that they are containers
of objects with a contiguous layout in memory. That doesn't imply either
set of semantics for + and * operators.

and *arrays ?

They're good at different things. Arrays like Numeric/numarray are
harder to implement than the builtin lists.

*I* would rather drop
'+' and '*' to work like they do in *array ...

Tough. It's 14 years or so too late to make that change.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Carl Banks]

* and + are not array operations, they are list operations.

Lists in Python can contain anything, not just numeric values.

That seems to be *the point*. Although list(a) + list(b) could create a
list [ a[0]+b[0], ...] and bail out if for elements '+' is not
defined...

Python doesn't have built-in mathematical arrays, otherwise known as
matrices. There are modules that do that, but I haven't used them. Google
on Numeric Python.

Well I am aware of that but I don't understand the reasons of having
both lists (which are infect arrays) and *arrays ? *I* would rather drop
'+' and '*' to work like they do in *array ...

The number of programmers who do operations on mathematical arrays is
pretty small. The number of programmers who need to do things like
concatenate lists is much larger. Thus, the decision was made to use
the valuable operator for the more common thing.

Truth be told, I rarely use + on lists (I tend to use list.extend
mostly), and if + had instead been used for element-by-element
operations, I don't think it would have affected the overall quality of
Python too much. But, as it's been said, it's a little late to change
it now.

 

[Christopher Subich]

But why ?? Why not have them operate on content, like is done on
*arrays ?

Because they're lists, not arrays. What do you propose that the
following do:

[1,2,3] + [4,5,6]
[1,2] + [3,4,5]
[1,2] + [{3:4,5:6}]
dict_var_1.keys() + dict_var_2.keys()
[g(3) for g in [f1 f2 f3] + [f4 f5 f6]]

I point out that the idiom is <list> + <list>, not <numbers> +
<numbers>. Operations on lists must deal with them as lists, not lists
of any specific type.

 

[Soeren Sonnenburg]

On Sat, 23 Jul 2005 18:30:02 +0200, Soeren Sonnenburg wrote: [...]
Lists in Python can contain anything, not just numeric values.

That seems to be *the point*.

Whose point? If you mean that you want to be able to use arbitrary
objects in an array, then look in numarray.objects for an array type
that handles arbitrary Python objects.

Well, one cannot efficiently deal with these 'list-arrays' as they can
contain different data types (typechecking necessary; atlas etc won't
work).

[...]

Tough. It's 14 years or so too late to make that change.

Ok got it.

A seperate array type which can only contain objects of the same type
simply makes sense.

Soeren

 

[Soeren Sonnenburg]

Thanks a lot for all the answers!!

Soeren