Re: multiply each element of a list by a number

Discussion in 'Python' started by Tim Chase, Dec 27, 2008.

  1. Tim Chase

    Tim Chase Guest

    > 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
    Tim Chase, Dec 27, 2008
    #1
    1. Advertising

  2. Tim Chase

    Martin Guest

    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 <>:
    > 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
    http://www.linkedin.com/in/martinmarcher

    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
    Martin, Dec 27, 2008
    #2
    1. Advertising

  3. Hi!

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


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

    @-salutations
    --
    Michel Claveau
    Méta-MCI (MVP), Dec 27, 2008
    #3
  4. 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.
    Portions Copyright 1994-2008 Mark
    Hammond - see 'Help/About PythonWin' for
    further copyright information.
    >>> lst= [1,2,3]
    >>> trippleList= [3*a for a in lst]
    >>> trippleList

    [3, 6, 9]
    >>>


    Colin W.
    Colin J. Williams, Dec 27, 2008
    #4
  5. Tim Chase

    Guest

    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://smontanaro.dyndns.org/
    , Dec 27, 2008
    #5
  6. 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.
    Colin J. Williams, Dec 28, 2008
    #6
  7. Tim Chase

    Guest

    >>>>> "Colin" == Colin J Williams <> writes:

    Colin> 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 - - http://smontanaro.dyndns.org/
    , Dec 29, 2008
    #7
  8. wrote:
    >>>>>> "Colin" == Colin J Williams <> writes:

    >
    > Colin> 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.
    Colin J. Williams, Dec 29, 2008
    #8
  9. Tim Chase

    Guest

    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 - - http://smontanaro.dyndns.org/
    , Dec 29, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    11
    Views:
    613
    Neil Cerutti
    Nov 11, 2005
  2. Replies:
    8
    Views:
    447
    osmium
    Oct 14, 2006
  3. Replies:
    20
    Views:
    1,226
  4. John
    Replies:
    16
    Views:
    883
  5. Pat Maddox
    Replies:
    6
    Views:
    151
    Marcin Mielżyński
    Jan 20, 2006
Loading...

Share This Page