473,461 Members | 1,515 Online
Bytes | Software Development & Data Engineering Community
Create Post

Home Posts Topics Members FAQ

consistency: extending arrays vs. multiplication ?

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
2*a

[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!

Jul 23 '05 #1
11 2253
In <ma***************************************@python. org>, Soeren
Sonnenburg wrote:
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
Jul 23 '05 #2
On Sat, 23 Jul 2005 18:30:02 +0200, Soeren Sonnenburg wrote:
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.

--
Steven.

Jul 24 '05 #3
Soeren Sonnenburg wrote:
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)]

Jul 24 '05 #4
On Sat, 2005-07-23 at 23:35 +0200, Marc 'BlackJack' Rintsch wrote:
In <ma***************************************@python. org>, Soeren
Sonnenburg wrote:
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

Jul 24 '05 #5
On Sun, 2005-07-24 at 13:36 +1000, Steven D'Aprano wrote:
On Sat, 23 Jul 2005 18:30:02 +0200, Soeren Sonnenburg wrote:
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.


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

Jul 24 '05 #6
On Sat, 2005-07-23 at 20:25 -0700, Dan Bishop wrote:
Soeren Sonnenburg wrote:
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

Jul 24 '05 #7
Soeren Sonnenburg wrote:
On Sun, 2005-07-24 at 13:36 +1000, Steven D'Aprano wrote:
On Sat, 23 Jul 2005 18:30:02 +0200, Soeren Sonnenburg wrote:
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.


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.
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)


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
rk***@ucsd.edu

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

Jul 24 '05 #8


Soeren Sonnenburg wrote:
On Sun, 2005-07-24 at 13:36 +1000, Steven D'Aprano wrote:
On Sat, 23 Jul 2005 18:30:02 +0200, Soeren Sonnenburg wrote:
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.


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.
--
CARL BANKS

Jul 24 '05 #9
Soeren Sonnenburg wrote:
On Sat, 2005-07-23 at 23:35 +0200, Marc 'BlackJack' Rintsch wrote:
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 ?


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.
Jul 24 '05 #10
On Sun, 2005-07-24 at 11:50 -0700, Robert Kern wrote:
Soeren Sonnenburg wrote:
On Sun, 2005-07-24 at 13:36 +1000, Steven D'Aprano wrote:
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).

[...]
*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.


Ok got it.

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

Soeren

Jul 26 '05 #11
Thanks a lot for all the answers!!

Soeren

Jul 26 '05 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Matthew Barnes | last post by:
I was wondering if there would be any interest in extending the struct.unpack format notation to be able to express groups of data with parenthesis. For example: >>> data =...
9
by: Ralf Hildebrandt | last post by:
Hi all! First of all: I am a C-newbie. I have noticed a "strange" behavior with the standart integer multiplication. The code is: void main(void)
9
by: Charles Banas | last post by:
i've got an interesting peice of code i'm maintaining, and i'd like to get some opinions and comments on it, hopefully so i can gain some sort of insight as to why this works. at the top of the...
5
by: chella mani | last post by:
hi all, I am developing a tool for scientific application which must be time and memory efficient,my tool uses 1D,2D and 3D arrays. Is it a good practice to use 3D arrays in applications or I...
8
by: l.j. | last post by:
Hi. I've a homework including calculations with arrays. I've stuck on multiply them. Can you help me?
1
by: conor.robinson | last post by:
Using large arrays of data I found it is MUCH faster to cast arrays to matricies and then multiply the two matricies togther (scipy.matrix(ARRAY1)*scipy.matrix(ARRAY2)) in order to do a matrix...
5
by: paul | last post by:
Hi all, Could some kind soul peruse the following code and see if there is anything wrong with it? Its producing output, but its only occupying the first third of the output array; to give an...
11
by: Hakusa | last post by:
Pythonic lists are everything I want in a one dimensional array . . . but I'm trying to do a text adventure and simplify the proces by creating a grid as opposed to a tedious list of rooms this...
6
by: Emiurgo | last post by:
Hi there to everyone! I've got a problem which may be interesting to some of you, and I'd be very grateful if there is someone who can give me some advice (or maybe redirect me to some other place)....
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.