random.gauss vs. random.normalvariate

Discussion in 'Python' started by Alan G Isaac, Aug 15, 2009.

  1. Alan G Isaac

    Alan G Isaac Guest

    Quoting http://docs.python.org/3.1/library/random.html#random.gauss:
    Gaussian distribution. mu is the mean, and sigma is the
    standard deviation. This is slightly faster than the
    normalvariate() function defined below.

    So since both are offered and gauss is faster, I assume it
    must have some offsetting disadvantage. What is it?

    Thank you,
    Alan Isaac
     
    Alan G Isaac, Aug 15, 2009
    #1
    1. Advertising

  2. Alan G Isaac

    Carl Banks Guest

    On Aug 15, 12:49 pm, Alan G Isaac <> wrote:
    > Quotinghttp://docs.python.org/3.1/library/random.html#random.gauss:
    >     Gaussian distribution. mu is the mean, and sigma is the
    >     standard deviation. This is slightly faster than the
    >     normalvariate() function defined below.
    >
    > So since both are offered and gauss is faster, I assume it
    > must have some offsetting disadvantage.  What is it?


    random.gauss is not thread safe.

    I'm kind of surprised the html docs don't mention this; the docstring
    does.


    Carl Banks
     
    Carl Banks, Aug 15, 2009
    #2
    1. Advertising

  3. Alan G Isaac

    Alan G Isaac Guest

    > On Aug 15, 12:49 pm, Alan G Isaac <> wrote:
    >> Quotinghttp://docs.python.org/3.1/library/random.html#random.gauss:
    >> Gaussian distribution. mu is the mean, and sigma is the
    >> standard deviation. This is slightly faster than the
    >> normalvariate() function defined below.
    >>
    >> So since both are offered and gauss is faster, I assume it
    >> must have some offsetting disadvantage. What is it?




    On 8/15/2009 4:26 PM Carl Banks apparently wrote:
    > random.gauss is not thread safe.
    >
    > I'm kind of surprised the html docs don't mention this; the docstring
    > does.




    Thank you,
    Alan Isaac
     
    Alan G Isaac, Aug 15, 2009
    #3
  4. On Sat, 15 Aug 2009 14:34:36 -0600, John Haggerty <>
    declaimed the following in gmane.comp.python.general:

    > What does the term "thread safe" mean exactly. I never had to program with
    > "threads" before


    That, part way through the logic of the function, control could be
    switched to a different thread which call the same function... This
    second call would change some of the internal values and may then be
    preempted and control returned to the first thread, which continues the
    rest of the function with different values then it had when first
    preempted.

    A very contrived example, untested of course, consider it
    pseudo-code...

    startt = None

    def atimer():
    global startt
    startt = time.time()
    time.sleep(5)
    print time.time() - startt

    t1 = threading.thread(atimer)
    t2 = threading.thread(atimer)
    t1.start()
    t2.start()

    Say t1 gets all the way up to the sleep call, and (since sleep is a
    releasing call), t2 then starts. t2 changes the value of startt; and
    sleeps... both sleep and presuming the resolution is fine enough, t1
    resumes, and prints a delta time that is incorrect -- it is printing
    the time difference from when t2 started to sleep, not from when t1
    started to sleep.
    --
    Wulfraed Dennis Lee Bieber KD6MOG
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Aug 16, 2009
    #4
  5. On Sat, 15 Aug 2009 21:59:09 -0600, John Haggerty <>
    declaimed the following in gmane.comp.python.general:

    > Interesting so it seems that the compiler(c/c++)interpreter(perl,
    > python)/vm(java) doesn't do this?


    No language can guard against independent access of a shared/global
    object by multiple threads... Look at Java's "synchronized" keyword, for
    example.

    Though Ada did build tasking and "protected objects" into the
    language syntax, rather than making them a library with constraints one
    must know of to code against.
    --
    Wulfraed Dennis Lee Bieber KD6MOG
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Aug 16, 2009
    #5
  6. Alan G Isaac

    Paul Rubin Guest

    Dennis Lee Bieber <> writes:
    > No language can guard against independent access of a shared/global
    > object by multiple threads...


    Erlang?
     
    Paul Rubin, Aug 16, 2009
    #6
  7. Alan G Isaac

    Chris Rebert Guest

    > On Sat, Aug 15, 2009 at 10:18 PM, Paul Rubin <http://>
    > wrote:
    >>
    >> Dennis Lee Bieber <> writes:
    >> >       No language can guard against independent access of a
    >> > shared/global
    >> > object by multiple threads...

    >>
    >> Erlang?


    On Sun, Aug 16, 2009 at 12:23 AM, John Haggerty<> wrote:
    > Erlang I assume is a computer programming language?


    http://en.wikipedia.org/wiki/Erlang_(programming_language)

    There's a reason Wikipedia has a search function... :)

    Cheers,
    Chris
    --
    http://blog.rebertia.com
     
    Chris Rebert, Aug 16, 2009
    #7
  8. Alan G Isaac

    Dave Angel Guest

    John Haggerty wrote:
    > On Sat, Aug 15, 2009 at 7:23 PM, Dennis Lee Bieber <>wrote:
    >
    >
    >> On Sat, 15 Aug 2009 14:34:36 -0600, John Haggerty <>
    >> declaimed the following in gmane.comp.python.general:
    >>
    >>
    >>> What does the term "thread safe" mean exactly. I never had to program
    >>>

    >> with
    >>
    >>> "threads" before
    >>>

    >> That, part way through the logic of the function, control could be
    >> switched to a different thread which call the same function... This
    >> second call would change some of the internal values and may then be
    >> preempted and control returned to the first thread, which continues the
    >> rest of the function with different values then it had when first
    >> preempted.
    >>
    >> A very contrived example, untested of course, consider it
    >> pseudo-code...
    >>
    >> startt = None
    >>
    >> def atimer():
    >> global startt
    >> startt = time.time()
    >> time.sleep(5)
    >> print time.time() - startt
    >>
    >> t1 = threading.thread(atimer)
    >> t2 = threading.thread(atimer)
    >> t1.start()
    >> t2.start()
    >>
    >> Say t1 gets all the way up to the sleep call, and (since sleep is a
    >> releasing call), t2 then starts. t2 changes the value of startt; and
    >> sleeps... both sleep and presuming the resolution is fine enough, t1
    >> resumes, and prints a delta time that is incorrect -- it is printing
    >> the time difference from when t2 started to sleep, not from when t1
    >> started to sleep.
    >> --
    >> Wulfraed Dennis Lee Bieber KD6MOG
    >> HTTP://wlfraed.home.netcom.com/
    >>
    >> --
    >> http://mail.python.org/mailman/listinfo/python-list
    >>
    >>

    >
    > Interesting so it seems that the compiler(c/c++)interpreter(perl,
    > python)/vm(java) doesn't do this?
    >
    >

    It is impossible for a language, vm, or operating system to avoid
    threading problems without the programmer's help, except by trivial
    means (eg. preventing you from having them at all).

    The power of threading is entirely tied up with the features the
    environment gives to the developer, and those features come with a risk.

    At one extreme is the CP/M model. You start a new program only when you
    finish the previous one. So the only communication between them is a
    file the first one leaves behind, that the second can look at.

    Next is separate processes. If you launch a second process, by default,
    they're independent, and not likely to get into trouble. But you can
    build pipes or shared memory, or sockets between them, and then you have
    to worry about race conditions.

    Next is threads, within a single process. At this point, you can share
    (global) variables between them, or you can have objects known to both
    when the thread is launched. The system cannot tell which ones are
    deliberate and which ones are accidental. So a language might give
    extra keywords to tell the compiler that certain things should be
    protected in certain ways. Or it might give a way to declare a
    "per-thread global" that acts like a global to each thread, but is
    actually two independent variables from the process point of view.

    The only real reason threads are singled out is it's easier to collide
    by mistake. But that's also what makes it efficient to "collide" on
    purpose.

    DaveA
     
    Dave Angel, Aug 16, 2009
    #8
  9. On 15 Aug 2009 21:18:36 -0700, Paul Rubin <http://>
    declaimed the following in gmane.comp.python.general:

    > Dennis Lee Bieber <> writes:
    > > No language can guard against independent access of a shared/global
    > > object by multiple threads...

    >
    > Erlang?


    Well, if I read the wikipedia link given in a later post,
    http://en.wikipedia.org/wiki/Erlang...oncurrency_and_distribution_oriented_language
    (emphasis mine)...

    """
    Like operating system processes (and unlike green threads and operating
    system threads) they have NO SHARED STATE between them.
    """

    which seems to reinforce my statement, not refute it.

    Hmmm, except for the facet that the Amiga exec directly passed
    memory addresses (no memory protection in the OS, the process sending
    was not supposed to touch the memory of the sent message until receiving
    the message reply), the Erlang process communication maps very closely
    to the Amiga message port system.


    (The Amiga was heavily dependent upon message ports: application I/O
    request becomes a message to the port of the file system, file system
    would map the "file pointer" to an internal table to locate the device,
    send a message to the port of the device handler -- device handler would
    execute the I/O request, reply to file system, file system would then
    reply to application... Having to copy data buffers between processes
    would have slowed the system down drastically [8MHz processor, in those
    days], so the link-list of messages on a port were typically short,
    having a pointer to the actual memory to use)


    --
    Wulfraed Dennis Lee Bieber KD6MOG
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Aug 16, 2009
    #9
  10. Alan G Isaac

    Paul Rubin Guest

    Dennis Lee Bieber <> writes:
    > > > No language can guard against independent access of a shared/global
    > > > object by multiple threads...

    > http://en.wikipedia.org/wiki/Erlang_(programming_language)
    > """
    > Like operating system processes (and unlike green threads and operating
    > system threads) they have NO SHARED STATE between them.
    > """
    > which seems to reinforce my statement, not refute it.


    Id say Erlang guards against independent access of shared/global
    objects by not allowing them.

    > (The Amiga was heavily dependent upon message ports... Having to
    > copy data buffers between processes would have slowed the system
    > down drastically [8MHz processor, in those days],


    It's perfectly ok for Erlang implementation to just pass pointers
    around, when the processes are on the same machine. Erlang prohibits
    data mutation so there isn't an issue of a process modifying some
    structure while another process is using it.
     
    Paul Rubin, Aug 16, 2009
    #10
    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:
    3
    Views:
    421
    Steve Holden
    Aug 4, 2007
  2. Vincent Davis
    Replies:
    3
    Views:
    287
    Dennis Lee Bieber
    Jun 21, 2009
  3. Vincent Davis
    Replies:
    18
    Views:
    556
  4. pistacchio

    random.gauss: range

    pistacchio, Feb 26, 2010, in forum: Python
    Replies:
    5
    Views:
    673
    Gregory Ewing
    Feb 28, 2010
  5. Daniel Schüle

    Random gauss numbers?

    Daniel Schüle, Nov 30, 2005, in forum: Ruby
    Replies:
    2
    Views:
    121
    Dan Diebolt
    Nov 30, 2005
Loading...

Share This Page