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! 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
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.
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)]
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
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
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
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
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
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.
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
Thanks a lot for all the answers!!
Soeren This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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 =...
|
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)
|
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...
|
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...
|
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?
|
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...
|
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...
|
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...
|
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)....
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
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...
|
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,...
|
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...
|
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,...
|
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...
|
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...
|
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,...
|
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...
| |