Velocity Reviews > Re: multiply each element of a list by a number

# Re: multiply each element of a list by a number

Tim Chase
Guest
Posts: n/a

 12-27-2008
> What does *not* work is
> 3 * [0,1,2]
> As you know, this gives
> [0,1,2,0,1,2,0,1,2]
> What I am hoping for is
> [0,3,6]
> I see that I can use
> numpy.multiply(3,range(3))
> but this seems overkill to me. Can you tell I am coming to Python from
> Matlab?

The common way to do this is just

a1 = [0,1,2]
a2 = [x * 3 for x in a1]

or, if you need a1 to be done in place:

a1[:] = [x*3 for x in a1]

-tkc

Martin
Guest
Posts: n/a

 12-27-2008
you might also want to look into the map(elem), and filter(elem) builtins

>>> def multby3(elem):

.... return elem * 3
....
>>> map(multby3, (1, 2, 3, ))

[3, 6, 9]
>>> help(map)
>>> def even(elem):

.... return not elem % 2
....
>>> filter(even, (1, 2, 3, ))

(2,)
>>> help(filter)

KeyboardInterrupt
>>> map(multby3, filter(even, (1, 2, 3, )))

[6]
>>>

hth
martin

2008/12/27 Scott David Daniels <(E-Mail Removed)>:
> Tim Chase wrote:
>>>
>>> What does *not* work is 3 * [0,1,2]
>>> As you know, this gives
>>> [0,1,2,0,1,2,0,1,2]
>>> What I am hoping for is
>>> [0,3,6]

--
http://soup.alt.delete.co.at
http://www.xing.com/profile/Martin_Marcher

You are not free to read this message,
by doing so, you have violated my licence
and are required to urinate publicly. Thank you.

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Méta-MCI (MVP)
Guest
Posts: n/a

 12-27-2008
Hi!

> map(multby3, (1, 2, 3, ))

....with lambda:
map(lambda x: x*3, [1,2,3])

@-salutations
--
Michel Claveau

Colin J. Williams
Guest
Posts: n/a

 12-27-2008
Méta-MCI (MVP) wrote:
> Hi!
>
>> map(multby3, (1, 2, 3, ))

>
> ....with lambda: map(lambda x: x*3, [1,2,3])
>
> @-salutations

More lines but perhaps faster than numpy:

PythonWin 2.5.4 (r254:67916, Dec 23
2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32.
Hammond - see 'Help/About PythonWin' for
>>> lst= [1,2,3]
>>> trippleList= [3*a for a in lst]
>>> trippleList

[3, 6, 9]
>>>

Colin W.

skip@pobox.com
Guest
Posts: n/a

 12-27-2008

Colin> ... perhaps faster than numpy:
...

For extremely short lists, but not for much else:

% for n in 1 10 100 1000 10000 100000 ; do
> echo "len:" \$n
> echo -n "numpy: "
> python -m timeit -s 'import numpy ; a = numpy.array(range('\$n'))' 'a*3'
> echo -n "list: "
> python -m timeit -s 'a = range('\$n')' '[3*x for x in a]'
> done

len: 1
numpy: 100000 loops, best of 3: 11.7 usec per loop
list: 1000000 loops, best of 3: 0.698 usec per loop
len: 10
numpy: 100000 loops, best of 3: 11.7 usec per loop
list: 100000 loops, best of 3: 2.94 usec per loop
len: 100
numpy: 100000 loops, best of 3: 12.1 usec per loop
list: 10000 loops, best of 3: 24.4 usec per loop
len: 1000
numpy: 100000 loops, best of 3: 15 usec per loop
list: 1000 loops, best of 3: 224 usec per loop
len: 10000
numpy: 10000 loops, best of 3: 41 usec per loop
list: 100 loops, best of 3: 2.17 msec per loop
len: 100000
numpy: 1000 loops, best of 3: 301 usec per loop
list: 10 loops, best of 3: 22.2 msec per loop

This is with Python 2.4.5 on Solaris 10. YMMV.

--
Skip Montanaro - http://www.velocityreviews.com/forums/(E-Mail Removed) - http://smontanaro.dyndns.org/

Colin J. Williams
Guest
Posts: n/a

 12-28-2008
(E-Mail Removed) wrote:
> Colin> ... perhaps faster than numpy:
> ...
>
> For extremely short lists, but not for much else:
>
> % for n in 1 10 100 1000 10000 100000 ; do
> > echo "len:" \$n
> > echo -n "numpy: "
> > python -m timeit -s 'import numpy ; a = numpy.array(range('\$n'))' 'a*3'
> > echo -n "list: "
> > python -m timeit -s 'a = range('\$n')' '[3*x for x in a]'
> > done

> len: 1
> numpy: 100000 loops, best of 3: 11.7 usec per loop
> list: 1000000 loops, best of 3: 0.698 usec per loop
> len: 10
> numpy: 100000 loops, best of 3: 11.7 usec per loop
> list: 100000 loops, best of 3: 2.94 usec per loop
> len: 100
> numpy: 100000 loops, best of 3: 12.1 usec per loop
> list: 10000 loops, best of 3: 24.4 usec per loop
> len: 1000
> numpy: 100000 loops, best of 3: 15 usec per loop
> list: 1000 loops, best of 3: 224 usec per loop
> len: 10000
> numpy: 10000 loops, best of 3: 41 usec per loop
> list: 100 loops, best of 3: 2.17 msec per loop
> len: 100000
> numpy: 1000 loops, best of 3: 301 usec per loop
> list: 10 loops, best of 3: 22.2 msec per loop
>
> This is with Python 2.4.5 on Solaris 10. YMMV.
>

Skip,

Your comment is justified for len= 100
or 1,000 but not for len= 10,000 or 100,000.

I wonder about the variability of the
number of loops in your data.

I have tried to repeat your test with
the program below, but it fails to cope
with numpy.

The results for Python 2.5 are:

list: 0.421 0.253
list: 0.427 0.254
list: 0.420 0.250
list: 0.421 0.255
list: 0.415 0.254
list: 0.423 0.254
list: 0.422 0.256

The results for Python 2.6 are:

list: 0.388 0.228
list: 0.410 0.225
list: 0.384 0.227
list: 0.389 0.226
list: 0.390 0.227

The script used above for both 2.5 and
2.6:

# speedUgh.py To compare array timing
##import numpy
import timeit as _t
m= 100 # number of repetitions
values= (10, 100)
numpyRes= []
listRes= []

for n in values:
sn= 'numpy.arange(' + str(n) + ')*3'
t= _t.Timer(sn)
## r= t.repeat(3, m)
## numpyRes.append(sum(t.repeat(3, m))
* 1000000/(3*m*n))
sl='a= [3*k for k in range(' + str(n)
+ ')]'
t= _t.Timer(stmt= sl)
listRes.append( sum(t.repeat(3, m)) *
1000000/(3*m*n))

##print 'numpy:', len(values)*'%8.3f' %
tuple(numpyRes)
print ' list:', len(values)*'%8.3f' %
tuple(listRes)

Colin W.

skip@pobox.com
Guest
Posts: n/a

 12-29-2008
>>>>> "Colin" == Colin J Williams <(E-Mail Removed)> writes:

Colin> (E-Mail Removed) wrote:

>> For extremely short lists, but not for much else:
>>
>> % for n in 1 10 100 1000 10000 100000 ; do
>> > echo "len:" \$n
>> > echo -n "numpy: "
>> > python -m timeit -s 'import numpy ; a = numpy.array(range('\$n'))' 'a*3'
>> > echo -n "list: "
>> > python -m timeit -s 'a = range('\$n')' '[3*x for x in a]'
>> > done

>> len: 1
>> numpy: 100000 loops, best of 3: 11.7 usec per loop
>> list: 1000000 loops, best of 3: 0.698 usec per loop
>> len: 10
>> numpy: 100000 loops, best of 3: 11.7 usec per loop
>> list: 100000 loops, best of 3: 2.94 usec per loop
>> len: 100
>> numpy: 100000 loops, best of 3: 12.1 usec per loop
>> list: 10000 loops, best of 3: 24.4 usec per loop
>> len: 1000
>> numpy: 100000 loops, best of 3: 15 usec per loop
>> list: 1000 loops, best of 3: 224 usec per loop
>> len: 10000
>> numpy: 10000 loops, best of 3: 41 usec per loop
>> list: 100 loops, best of 3: 2.17 msec per loop
>> len: 100000
>> numpy: 1000 loops, best of 3: 301 usec per loop
>> list: 10 loops, best of 3: 22.2 msec per loop
>>
>> This is with Python 2.4.5 on Solaris 10. YMMV.

Colin> Your comment is justified for len= 100
Colin> or 1,000 but not for len= 10,000 or 100,000.

Look again at the time units per loop.

Colin> I wonder about the variability of the number of loops in your
Colin> data.

That's how timeit works. It runs a few iterations to see how many to run to
get a reasonable runtime.

Colin> I have tried to repeat your test with the program below, but it
Colin> fails to cope with numpy.

I stand by my assertion that numpy will be much faster than pure Python for
all but very short lists.

--
Skip Montanaro - (E-Mail Removed) - http://smontanaro.dyndns.org/

Colin J. Williams
Guest
Posts: n/a

 12-29-2008
(E-Mail Removed) wrote:
>>>>>> "Colin" == Colin J Williams <(E-Mail Removed)> writes:

>
> Colin> (E-Mail Removed) wrote:
>
> >> For extremely short lists, but not for much else:
> >>
> >> % for n in 1 10 100 1000 10000 100000 ; do
> >> > echo "len:" \$n
> >> > echo -n "numpy: "
> >> > python -m timeit -s 'import numpy ; a = numpy.array(range('\$n'))' 'a*3'
> >> > echo -n "list: "
> >> > python -m timeit -s 'a = range('\$n')' '[3*x for x in a]'
> >> > done
> >> len: 1
> >> numpy: 100000 loops, best of 3: 11.7 usec per loop
> >> list: 1000000 loops, best of 3: 0.698 usec per loop
> >> len: 10
> >> numpy: 100000 loops, best of 3: 11.7 usec per loop
> >> list: 100000 loops, best of 3: 2.94 usec per loop
> >> len: 100
> >> numpy: 100000 loops, best of 3: 12.1 usec per loop
> >> list: 10000 loops, best of 3: 24.4 usec per loop
> >> len: 1000
> >> numpy: 100000 loops, best of 3: 15 usec per loop
> >> list: 1000 loops, best of 3: 224 usec per loop
> >> len: 10000
> >> numpy: 10000 loops, best of 3: 41 usec per loop
> >> list: 100 loops, best of 3: 2.17 msec per loop
> >> len: 100000
> >> numpy: 1000 loops, best of 3: 301 usec per loop
> >> list: 10 loops, best of 3: 22.2 msec per loop
> >>
> >> This is with Python 2.4.5 on Solaris 10. YMMV.

>
> Colin> Your comment is justified for len= 100
> Colin> or 1,000 but not for len= 10,000 or 100,000.
>
> Look again at the time units per loop.
>
> Colin> I wonder about the variability of the number of loops in your
> Colin> data.
>
> That's how timeit works. It runs a few iterations to see how many to run to
> get a reasonable runtime.

That's interesting but that's not the
way timeit is documented for Python 2.5:

timeit( [number=1000000])

Time number executions of the main
statement. This executes the setup
statement once, and then returns the
time it takes to execute the main
statement a number of times, measured in
seconds as a float. The argument is the
number of times through the loop,
defaulting to one million. The main
statement, the setup statement and the
timer function to be used are passed to
the constructor.

>
> Colin> I have tried to repeat your test with the program below, but it
> Colin> fails to cope with numpy.
>
> I stand by my assertion that numpy will be much faster than pure Python for
> all but very short lists.
>

In spite of the fact that your own data
doesn't support the assertion?

I would have expected numpy to be the
clear winner for len > 1,500.

Perhaps your data questions the value of
timeit as a timing tool.

Colin W.

skip@pobox.com
Guest
Posts: n/a

 12-29-2008

Colin> That's interesting but that's not the
Colin> way timeit is documented for Python 2.5:

Colin> timeit( [number=1000000])

That's how it works when invoked as a main program using -m.

Colin> In spite of the fact that your own data doesn't support the
Colin> assertion?

Colin> I would have expected numpy to be the clear winner for len >
Colin> 1,500.

It is. In fact, it's the clear winner well below that. Below I have
reorganized the timeit output so the units are the same for all runs
(*microseconds* per loop):

length numpy pure python
1 11.7 0.698
10 11.7 2.94
100 12.1 24.4
1000 15 224
10000 41 2170
100000 301 22200

--
Skip Montanaro - (E-Mail Removed) - http://smontanaro.dyndns.org/