Daniel Klopp | 16 Aug 18:07
Picon

Monitor.timeAverage() Bug

Hi, i found something buggy in the timeAverage function of the Monitor Object. Let my explain:

Supouse you have a Monitor 'm' that looks like this: [ [0.0 , 1.0] , [1.0, 2.0] ]
now, if we put

>>>m.timeAverage(2)
1.5
Perfect!

Now we do

>>>m.observe(3.0, 2.0)
>>>m.observe(4.0, 3.0)
>>>print m
[[0.0, 1.0], [1.0, 2.0], [2.0, 3.0], [3.0, 4.0]]
>>>m.timeAverage(4)
2.5

Good, But!
>>>m.timeAverage(2) # Same that in the beginning!
1.0

Wrong! it should be 1.5.
And even worse:
>>>m.timeAverage(1)
-2.0

Negative??

Well, I'm new with SimPy and Python, second day actually ;) , But that's a Bug!

For everything else, you guys are doing a great job!

My Regards.

Daniel Klopp

Hotmail to go? Get your Hotmail, news, sports and much more! Check out the New MSN Mobile
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Simpy-users mailing list
Simpy-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simpy-users
kgmuller | 17 Aug 07:53
Picon
Picon
Favicon

Re: Monitor.timeAverage() Bug

Dear Daniel,

welcome to the list and to SimPy!

 

You did not find a bug, but you misunderstood the semantics of timeAverage's parameter "t". If you look at SimPy's Manual, you find:

 

  • r.timeAverage([t]) the average of the time-weighted y graph, calculated from time 0 (or the last time r.reset([t]) was called) to time t (or to the current simulation time, now( ), if t is missing). This is determined from the area under the graph shown in the figure, divided by the total time of observation. For accurate time-average results y most be piecewise constant and observed just after each change in its value. (If there are no observations, the message "SimPy: No observations for timeAverage". If no time has elapsed, the message "SimPy: No elapsed time for timeAverage" is printed).

    r.timeAverage( ) is the time-weighted average of the observed y values. Each y value is weighted by the time for which it exists. The average is the area under the above curve divided by the total time, t.

  •  
    So, parameter "t" is the total time. In your example, that is 4.0 . Calling timeAverage with another time value leads to the wrong function value return.
     
    Maybe the Manual should stress this more.
     
    Happy SimPying!
     
    Klaus Muller

    From: simpy-users-bounces <at> lists.sourceforge.net [mailto:simpy-users-bounces <at> lists.sourceforge.net] On Behalf Of Daniel Klopp
    Sent: Thursday, August 16, 2007 6:08 PM
    To: simpy-users <at> lists.sourceforge.net
    Subject: [Simpy-users] Monitor.timeAverage() Bug

    Hi, i found something buggy in the timeAverage function of the Monitor Object. Let my explain:

    Supouse you have a Monitor 'm' that looks like this: [ [0.0 , 1.0] , [1.0, 2.0] ]
    now, if we put

    >>>m.timeAverage(2)
    1.5
    Perfect!

    Now we do

    >>>m.observe(3.0, 2.0)
    >>>m.observe(4.0, 3.0)
    >>>print m
    [[0.0, 1.0], [1.0, 2.0], [2.0, 3.0], [3.0, 4.0]]
    >>>m.timeAverage(4)
    2.5

    Good, But!
    >>>m.timeAverage(2) # Same that in the beginning!
    1.0

    Wrong! it should be 1.5.
    And even worse:
    >>>m.timeAverage(1)
    -2.0

    Negative??

    Well, I'm new with SimPy and Python, second day actually ;) , But that's a Bug!

    For everything else, you guys are doing a great job!

    My Regards.

    Daniel Klopp

    Hotmail to go? Get your Hotmail, news, sports and much more! Check out the New MSN Mobile
    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    Tony Vignaux | 18 Aug 07:17
    Picon
    Gravatar

    Re: Monitor.timeAverage() Bug

    If someone can suggest a wording that would make it clearer, I't be happy to put it in.

    Alternatively, can anyone suggest an alternative mechanism? Currently if the argument t is given, that is what is used. If it is not given, the system uses now() to get the interval over which the average is to be calculated. If there has not been a simulation to update now(), we will have strange results.

    I noticed another bug: in the figure I refer to m.timeaverage() , it should be r.timeaverage() -- we changed the example. I will fix the figure.

    By the way, should we just refer to the method as timeaverage()?   Will readers understand that methods have to be prefixed with the monitor identifier?

    Tony Vignaux



    On 8/17/07, kgmuller <kgwork <at> xs4all.nl> wrote:

    Dear Daniel,

    welcome to the list and to SimPy!

     

    You did not find a bug, but you misunderstood the semantics of timeAverage's parameter "t". If you look at SimPy's Manual, you find:

     

  • r.timeAverage([t]) the average of the time-weighted y graph, calculated from time 0 (or the last time r.reset([t]) was called) to time t (or to the current simulation time, now( ), if t is missing). This is determined from the area under the graph shown in the figure, divided by the total time of observation. For accurate time-average results y most be piecewise constant and observed just after each change in its value. (If there are no observations, the message "SimPy: No observations for timeAverage". If no time has elapsed, the message "SimPy: No elapsed time for timeAverage" is printed).

    r.timeAverage( ) is the time-weighted average of the observed y values. Each y value is weighted by the time for which it exists. The average is the area under the above curve divided by the total time, t.

  •  
    So, parameter "t" is the total time. In your example, that is 4.0 . Calling timeAverage with another time value leads to the wrong function value return.
     
    Maybe the Manual should stress this more.
     
    Happy SimPying!
     
    Klaus Muller

    From: simpy-users-bounces <at> lists.sourceforge.net [mailto:simpy-users-bounces <at> lists.sourceforge.net] On Behalf Of Daniel Klopp
    Sent: Thursday, August 16, 2007 6:08 PM
    To: simpy-users <at> lists.sourceforge.net
    Subject: [Simpy-users] Monitor.timeAverage() Bug

    Hi, i found something buggy in the timeAverage function of the Monitor Object. Let my explain:

    Supouse you have a Monitor 'm' that looks like this: [ [0.0 , 1.0] , [1.0, 2.0] ]
    now, if we put

    >>>m.timeAverage(2)
    1.5
    Perfect!

    Now we do

    >>>m.observe(3.0, 2.0)
    >>>m.observe(4.0, 3.0)
    >>>print m
    [[0.0, 1.0], [1.0, 2.0], [2.0, 3.0], [3.0, 4.0]]
    >>>m.timeAverage(4)
    2.5

    Good, But!
    >>>m.timeAverage(2) # Same that in the beginning!
    1.0

    Wrong! it should be 1.5.
    And even worse:
    >>>m.timeAverage(1)
    -2.0

    Negative??

    Well, I'm new with SimPy and Python, second day actually ;) , But that's a Bug!

    For everything else, you guys are doing a great job!

    My Regards.

    Daniel Klopp

    Hotmail to go? Get your Hotmail, news, sports and much more! Check out the New MSN Mobile

    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users


    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    The Helmbolds | 18 Aug 17:40
    Picon
    Favicon

    Re: Monitor.timeAverage() Bug

    Regarding reference to the method as just "timeaverage" versus "r.timeaverage": 
       First, such references appear in SimPy programs as "r.timeaverage".
       Second, the practice adopted elsewhere in the manual consistently uses the object prefix.
       Third, while my experience is limited, this seems to be the practice normally used by other authors.
       Fourth, it is more specific, and even experienced users are sometimes helped by a reminder that the particular object reference needs to be included -- especially so if one happens to have several different objects in play.
     
    Regarding rewording to make things clearer: My first thought would be to include a paragraph headed
       "Caution: Using a time that is not the total time may give incorrect results. For example:
      (and insert here Klopps's example or one like it, together with the gist of Klaus's
      explanation)."
    However, there may be better approaches than this. One disadvantage of this approach is that we probably do not want to include more than a _very_ few such cautions in the manual. (Sigh) it is always possible for someone somewhere to misinterpret the language (or even the code), no matter how hard the writer has tried to make things clear. As a teacher, I'm sure that Tony understands this phenomenon better than I do.
     
    Regards, Bob 

    Tony Vignaux <vignaux <at> gmail.com> wrote:
    If someone can suggest a wording that would make it clearer, I't be happy to put it in.

    Alternatively, can anyone suggest an alternative mechanism? Currently if the argument t is given, that is what is used. If it is not given, the system uses now() to get the interval over which the average is to be calculated. If there has not been a simulation to update now(), we will have strange results.

    I noticed another bug: in the figure I refer to m.timeaverage() , it should be r.timeaverage() -- we changed the example. I will fix the figure.

    By the way, should we just refer to the method as timeaverage()?   Will readers understand that methods have to be prefixed with the monitor identifier?

    Tony Vignaux



    On 8/17/07, kgmuller <kgwork <at> xs4all.nl> wrote:
    Dear Daniel,
    welcome to the list and to SimPy!
     
    You did not find a bug, but you misunderstood the semantics of timeAverage's parameter "t". If you look at SimPy's Manual, you find:
     
  • r.timeAverage([t]) the average of the time-weighted y graph, calculated from time 0 (or the last time r.reset([t]) was called) to time t (or to the current simulation time, now( ), if t is missing). This is determined from the area under the graph shown in the figure, divided by the total time of observation. For accurate time-average results y most be piecewise constant and observed just after each change in its value. (If there are no observations, the message "SimPy: No observations for timeAverage". If no time has elapsed, the message "SimPy: No elapsed time for timeAverage" is printed).
    r.timeAverage( ) is the time-weighted average of the observed y values. Each y value is weighted by the time for which it exists. The average is the area under the above curve divided by the total time, t.
  •  
    So, parameter "t" is the total time. In your example, that is 4.0 . Calling timeAverage with another time value leads to the wrong function value return.
     
    Maybe the Manual should stress this more.
     
    Happy SimPying!
     
    Klaus Muller

    From: simpy-users-bounces <at> lists.sourceforge.net [mailto:simpy-users-bounces <at> lists.sourceforge.net] On Behalf Of Daniel Klopp
    Sent: Thursday, August 16, 2007 6:08 PM
    To: simpy-users <at> lists.sourceforge.net
    Subject: [Simpy-users] Monitor.timeAverage() Bug

    Hi, i found something buggy in the timeAverage function of the Monitor Object. Let my explain:

    Supouse you have a Monitor 'm' that looks like this: [ [0.0 , 1.0] , [1.0, 2.0] ]
    now, if we put

    >>>m.timeAverage(2)
    1.5
    Perfect!

    Now we do

    >>>m.observe(3.0, 2.0)
    >>>m.observe(4.0, 3.0)
    >>>print m
    [[0.0, 1.0], [1.0, 2.0], [2.0, 3.0], [3.0, 4.0]]
    >>>m.timeAverage(4)
    2.5

    Good, But!
    >>>m.timeAverage(2) # Same that in the beginning!
    1.0

    Wrong! it should be 1.5.
    And even worse:
    >>>m.timeAverage(1)
    -2.0

    Negative??

    Well, I'm new with SimPy and Python, second day actually ;) , But that's a Bug!

    For everything else, you guys are doing a great job!

    My Regards.

    Daniel Klopp

    Hotmail to go? Get your Hotmail, news, sports and much more! Check out the New MSN Mobile

    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users


    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems? Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users

    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    Mark Elston | 18 Aug 18:18

    [Fwd: Re: Monitor.timeAverage() Bug]

    
    On 17 Aug, Klaus Muller wrote:
     > ...
     >
     > You did not find a bug, but you misunderstood the semantics of
     > timeAverage's parameter "t". If you look at SimPy's Manual, you find:
     >
     > ...
     >
     > r.timeAverage([t]) the average of the time-weighted y graph,
     > calculated from time 0 (or the last time r.reset([t]) was called) to
     > time t (or to the current simulation time, now( ), if t is missing).
     > This is determined from the area under the graph shown in the figure,
     > divided by the total time of observation. For accurate time-average
     > results y most be piecewise constant and observed just after each
     > change in its value. (If there are no observations, the message
     > "SimPy: No observations for timeAverage". If no time has elapsed, the
     > message "SimPy: No elapsed time for timeAverage" is printed).
     >
     > ...
     >
     > /*r.timeAverage( )* is the time-weighted average of the observed y
     > values. Each y value is weighted by the time for which it exists. The
     > average is the area under the above curve divided by the total time,
     > t./
     >
     > So, parameter "t" is the *total* time. In your example, that is 4.0.
     > Calling timeAverage with another time value leads to the wrong
     > function value return.
    
    So, why allow any other value if it will lead to wrong results?  I
    guess I also misunderstand this since the first paragraph indicates
    that this function returns the 'time-weighted graph, calculated from
    0 ... to time t'.  According to this Daniel is correct in what he
    expects to happen.
    
    I haven't seen any other explanation of what *is* returned if you pass
    in an actual value of 't'.
    
    Mark
    
    
    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    
    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    Tony Vignaux | 19 Aug 07:01
    Picon
    Gravatar

    Re: [Fwd: Re: Monitor.timeAverage() Bug]

    I'll have a look at the unit-tests and the code to see what might have gone wrong. With positive values of y we should never
    get a negative value of timeaverage.

    On 8/19/07, Mark Elston <m.elston <at> advantest-ard.com> wrote:

    On 17 Aug, Klaus Muller wrote:
    > ...
    >
    > You did not find a bug, but you misunderstood the semantics of
    > timeAverage's parameter "t". If you look at SimPy's Manual, you find:
    >
    > ...
    >
    > r.timeAverage([t]) the average of the time-weighted y graph,
    > calculated from time 0 (or the last time r.reset([t]) was called) to
    > time t (or to the current simulation time, now( ), if t is missing).
    > This is determined from the area under the graph shown in the figure,
    > divided by the total time of observation. For accurate time-average
    > results y most be piecewise constant and observed just after each
    > change in its value. (If there are no observations, the message
    > "SimPy: No observations for timeAverage". If no time has elapsed, the
    > message "SimPy: No elapsed time for timeAverage" is printed).
    >
    > ...
    >
    > /*r.timeAverage( )* is the time-weighted average of the observed y
    > values. Each y value is weighted by the time for which it exists. The
    > average is the area under the above curve divided by the total time,
    > t./
    >
    > So, parameter "t" is the *total* time. In your example, that is 4.0.
    > Calling timeAverage with another time value leads to the wrong
    > function value return.

    So, why allow any other value if it will lead to wrong results?  I
    guess I also misunderstand this since the first paragraph indicates
    that this function returns the 'time-weighted graph, calculated from
    0 ... to time t'.  According to this Daniel is correct in what he
    expects to happen.

    I haven't seen any other explanation of what *is* returned if you pass
    in an actual value of 't'.

    Mark


    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>   http://get.splunk.com/

    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users


    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>   http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users


    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    Tony Vignaux | 19 Aug 09:14
    Picon
    Gravatar

    Re: [Fwd: Re: Monitor.timeAverage() Bug]

    Let us see if we can make the timeAverage call clearer -- or develop a better alternative. I hope this can be backward compatible as there are an awful lot of SimPy programs out there.

    currently:

    def
    timeAverage(self,t=None)

    if t==None, then t = now(). The time average is calculated from 0 to t, or from the time of the last reset to t. Thus, there is a "hidden" parameter, the start time.

    one alternative:

    def timeAverage (self,t=None,interval=[])

    Here interval is either [] or a two-element list, [tstart, tfinish]. If interval is not None, then it overrides t. tfinish could be None in which case it takes the value now()


    Any other ideas?






    On 8/19/07, Mark Elston <m.elston <at> advantest-ard.com> wrote:

    On 17 Aug, Klaus Muller wrote:
    > ...
    >
    > You did not find a bug, but you misunderstood the semantics of
    > timeAverage's parameter "t". If you look at SimPy's Manual, you find:
    >
    > ...
    >
    > r.timeAverage([t]) the average of the time-weighted y graph,
    > calculated from time 0 (or the last time r.reset([t]) was called) to
    > time t (or to the current simulation time, now( ), if t is missing).
    > This is determined from the area under the graph shown in the figure,
    > divided by the total time of observation. For accurate time-average
    > results y most be piecewise constant and observed just after each
    > change in its value. (If there are no observations, the message
    > "SimPy: No observations for timeAverage". If no time has elapsed, the
    > message "SimPy: No elapsed time for timeAverage" is printed).
    >
    > ...
    >
    > /*r.timeAverage( )* is the time-weighted average of the observed y
    > values. Each y value is weighted by the time for which it exists. The
    > average is the area under the above curve divided by the total time,
    > t./
    >
    > So, parameter "t" is the *total* time. In your example, that is 4.0.
    > Calling timeAverage with another time value leads to the wrong
    > function value return.

    So, why allow any other value if it will lead to wrong results?  I
    guess I also misunderstand this since the first paragraph indicates
    that this function returns the 'time-weighted graph, calculated from
    0 ... to time t'.  According to this Daniel is correct in what he
    expects to happen.

    I haven't seen any other explanation of what *is* returned if you pass
    in an actual value of 't'.

    Mark




    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    Mark Elston | 20 Aug 03:30

    Re: [Fwd: Re: Monitor.timeAverage() Bug]

    Tony,
    
    What you proposed would work, I think.  An alternative might be:
    
    def timeAverage(self, t=None, tStart=None)
    
    Here 't' behaves as it currently does; it determines the 'end' of the
    time averaging period.  If it is None then use 'now()'.  The 'tStart'
    parameter specifies the optional start time of the time averaging
    period.  If it is 'None' then the start is either 0 or the time  of the
    last reset.
    
    This approach seems to have a simpler interface providing reasonable
    default values to both the start and the end.  Putting tStart at the
    end of the calling sequence recognizes that it is the least likely to
    be specified (most calls will start from 0).  It looks a little odd
    since the 'start' is specified after the 'end'.  This might violate the
    readability principle in PEP 08.  I'll let others decide.
    
    Mark
    
    * Tony Vignaux wrote (on 8/19/2007 12:14 AM):
    > Let us see if we can make the timeAverage call clearer -- or develop a 
    > better alternative. I hope this can be backward compatible as there are 
    > an awful lot of SimPy programs out there.
    > 
    > currently:
    > 
    > def timeAverage(self,t=None)
    > 
    > if t==None, then t = now(). The time average is calculated from 0 to t, 
    > or from the time of the last reset to t. Thus, there is a "hidden" 
    > parameter, the start time.
    > 
    > one alternative:
    > 
    > def timeAverage(self,t=None,interval=[])
    > 
    > Here interval is either [] or a two-element list, [tstart, tfinish]. If 
    > interval is not None, then it overrides t. tfinish could be None in 
    > which case it takes the value now()
    > 
    > 
    > Any other ideas?
    > 
    > 
    > 
    > 
    > 
    > On 8/19/07, *Mark Elston * <m.elston <at> advantest-ard.com 
    > <mailto:m.elston <at> advantest-ard.com>> wrote:
    > 
    > 
    >     On 17 Aug, Klaus Muller wrote:
    >      > ...
    >      >
    >      > You did not find a bug, but you misunderstood the semantics of
    >      > timeAverage's parameter "t". If you look at SimPy's Manual, you
    >     find:
    >      >
    >      > ...
    >      >
    >      > r.timeAverage([t]) the average of the time-weighted y graph,
    >      > calculated from time 0 (or the last time r.reset([t]) was called) to
    >      > time t (or to the current simulation time, now( ), if t is missing).
    >      > This is determined from the area under the graph shown in the figure,
    >      > divided by the total time of observation. For accurate time-average
    >      > results y most be piecewise constant and observed just after each
    >      > change in its value. (If there are no observations, the message
    >      > "SimPy: No observations for timeAverage". If no time has elapsed, the
    >      > message "SimPy: No elapsed time for timeAverage" is printed).
    >      >
    >      > ...
    >      >
    >      > /*r.timeAverage( )* is the time-weighted average of the observed y
    >      > values. Each y value is weighted by the time for which it exists. The
    >      > average is the area under the above curve divided by the total time,
    >      > t./
    >      >
    >      > So, parameter "t" is the *total* time. In your example, that is 4.0.
    >      > Calling timeAverage with another time value leads to the wrong
    >      > function value return.
    > 
    >     So, why allow any other value if it will lead to wrong results?  I
    >     guess I also misunderstand this since the first paragraph indicates
    >     that this function returns the 'time-weighted graph, calculated from
    >     0 ... to time t'.  According to this Daniel is correct in what he
    >     expects to happen.
    > 
    >     I haven't seen any other explanation of what *is* returned if you pass
    >     in an actual value of 't'.
    > 
    >     Mark
    > 
    > 
    > 
    > 
    > 
    > ------------------------------------------------------------------------
    > 
    > -------------------------------------------------------------------------
    > This SF.net email is sponsored by: Splunk Inc.
    > Still grepping through log files to find problems?  Stop.
    > Now Search log events and configuration files using AJAX and a browser.
    > Download your FREE copy of Splunk now >>  http://get.splunk.com/
    > 
    > 
    > ------------------------------------------------------------------------
    > 
    > _______________________________________________
    > Simpy-users mailing list
    > Simpy-users <at> lists.sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    
    Tony Vignaux | 20 Aug 03:44
    Picon
    Gravatar

    Re: [Fwd: Re: Monitor.timeAverage() Bug]

    Yes, this was my first idea but I am a little wary of the  start-finish being the "wrong way round".

    It is easy enough to do.


    On 8/20/07, Mark Elston <m.elston <at> advantest-ard.com> wrote:
    Tony,

    What you proposed would work, I think.  An alternative might be:

    def timeAverage(self, t=None, tStart=None)

    Here 't' behaves as it currently does; it determines the 'end' of the
    time averaging period.  If it is None then use 'now()'.  The 'tStart'
    parameter specifies the optional start time of the time averaging
    period.  If it is 'None' then the start is either 0 or the time  of the
    last reset.

    This approach seems to have a simpler interface providing reasonable
    default values to both the start and the end.  Putting tStart at the
    end of the calling sequence recognizes that it is the least likely to
    be specified (most calls will start from 0).  It looks a little odd
    since the 'start' is specified after the 'end'.  This might violate the
    readability principle in PEP 08.  I'll let others decide.

    Mark

    * Tony Vignaux wrote (on 8/19/2007 12:14 AM):
    > Let us see if we can make the timeAverage call clearer -- or develop a
    > better alternative. I hope this can be backward compatible as there are
    > an awful lot of SimPy programs out there.
    >
    > currently:
    >
    > def timeAverage(self,t=None)
    >
    > if t==None, then t = now(). The time average is calculated from 0 to t,
    > or from the time of the last reset to t. Thus, there is a "hidden"
    > parameter, the start time.
    >
    > one alternative:
    >
    > def timeAverage(self,t=None,interval=[])
    >
    > Here interval is either [] or a two-element list, [tstart, tfinish]. If
    > interval is not None, then it overrides t. tfinish could be None in
    > which case it takes the value now()
    >
    >
    > Any other ideas?
    >
    >
    >
    >
    >
    > On 8/19/07, *Mark Elston * <m.elston <at> advantest-ard.com
    > <mailto:m.elston <at> advantest-ard.com>> wrote:
    >
    >
    >     On 17 Aug, Klaus Muller wrote:
    >      > ...
    >      >
    >      > You did not find a bug, but you misunderstood the semantics of
    >      > timeAverage's parameter "t". If you look at SimPy's Manual, you
    >     find:
    >      >
    >      > ...
    >      >
    >      > r.timeAverage([t]) the average of the time-weighted y graph,
    >      > calculated from time 0 (or the last time r.reset([t]) was called) to
    >      > time t (or to the current simulation time, now( ), if t is missing).
    >      > This is determined from the area under the graph shown in the figure,
    >      > divided by the total time of observation. For accurate time-average
    >      > results y most be piecewise constant and observed just after each
    >      > change in its value. (If there are no observations, the message
    >      > "SimPy: No observations for timeAverage". If no time has elapsed, the
    >      > message "SimPy: No elapsed time for timeAverage" is printed).
    >      >
    >      > ...
    >      >
    >      > /*r.timeAverage( )* is the time-weighted average of the observed y
    >      > values. Each y value is weighted by the time for which it exists. The
    >      > average is the area under the above curve divided by the total time,
    >      > t./
    >      >
    >      > So, parameter "t" is the *total* time. In your example, that is 4.0.
    >      > Calling timeAverage with another time value leads to the wrong
    >      > function value return.
    >
    >     So, why allow any other value if it will lead to wrong results?  I
    >     guess I also misunderstand this since the first paragraph indicates
    >     that this function returns the 'time-weighted graph, calculated from
    >     0 ... to time t'.  According to this Daniel is correct in what he
    >     expects to happen.
    >
    >     I haven't seen any other explanation of what *is* returned if you pass
    >     in an actual value of 't'.
    >
    >     Mark
    >
    >
    >
    >
    >
    > ------------------------------------------------------------------------
    >
    > -------------------------------------------------------------------------
    > This SF.net email is sponsored by: Splunk Inc.
    > Still grepping through log files to find problems?  Stop.
    > Now Search log events and configuration files using AJAX and a browser.
    > Download your FREE copy of Splunk now >>   http://get.splunk.com/
    >
    >
    > ------------------------------------------------------------------------
    >
    > _______________________________________________
    > Simpy-users mailing list
    > Simpy-users <at> lists.sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/simpy-users

    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    _______________________________________________
    Simpy-users mailing list
    Simpy-users <at> lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/simpy-users
    
    kgmuller | 27 Aug 16:48
    Picon
    Picon
    Favicon

    Help me with selection of faster event list handling algorithms for SimPy!

    All:
    For almost two months, I have been working on finding faster algorithms/data
    structures for handling SimPy.Simulation's event list. My goal is to make
    SimPy's next version noticeably faster, so that you can tackle larger models
    and/or more replication runs. This looks quite feasible!
    
    I am now seeking your help (see below).
    
    This work was originally aimed at evaluating a proposal developed by Prof.
    Norm Matloff and a few very bright students to speed up SimPy.Simulation's
    event handling by dropping the dictionary in event notices. (As a reminder:
    SimPy.Simulation has the event notice structure 
    {<time1>:(ev notice1, ev notice2, . . ), <time2>:(ev notice 3,...),..};
    event times are maintained in a list sorted by bisect.) Norm and his
    students did an in-depth scientific study on improvement approaches using
    only Python and also approaches employing e.g. C. Of these, I only
    considered the one in pure Python.
    
    Norm's proposal is to drop the dictionary and to maintain the event notices
    in a time-sorted list (sorted by bisect).
    
    I measured the performance of Simulation.py with Norm's changes and found
    better performance. Depending on the model characteristics, the performance
    could amount to tens of percents. Impressive!
    
    I then started looking for other, even faster event handling algorithms/data
    structures and found that using heapq (rather than bisect) could give even
    better performance. heapq keeps a list partially sorted so that the element
    at the front of the list is always the lowest in the sort order. In my
    alternative Simulation.py, I therefore use a time-ordered list, sorted by
    heapq.
    
    Tony Vignaux gave me a very clever input: avoid shortening/compacting the
    event list by not removing a cancelled event notice. Mark the event notice
    as cancelled instead and throw it away when it comes to the front of the
    event list. Deletion of elements from inside a list is expensive in
    CPU-time.
    
    I now had three versions of Simulation.py to compare:
     1) the original version (as released in 1.7.1) (I called this
    Simulation1_7_1.py)
     2) that version, but modified using Norm's proposal (getting rid of the
    dictionary) (called Simulation_ND.py), and
     3) Norm's version (no dictionary), but modified to use heapq instead of
    bisect and with cancelled event notices marked and only thrown away when
    coming to the front (called Simulation_heapq_Plus.
    
    I then developed several synthetic models for timing purposes. The ones I
    concentrated on were:
    A)A model with a large number of processes which execute two "yield hold"
    with exponentially distributed times (model_doublehold*.py). This model
    tests the performance for scheduling and firing events.
    B) A model with a large number of processes which do one "yield hold" and
    some of which do a "yield request" with reneging (model_renege_*.py). The
    renege never happens, as there are enough resource units for all processes.
    This model tests the performance of cancelling processes, namely the renege
    processes.
    
    Both types of models are instrumented for runtime measurement with Python's
    hotshot module.
    
    You can download all these files from SimPy's CVS:
    
    http://simpy.cvs.sourceforge.net/simpy/SimPy/Speedup/?pathrev=avendor7
    
    The file processHotshotFiles.py extracts the measurement and presents
    detailed timing reports.
    
    Just put all of these files into a new folder and you won't interfere with
    your current SimPy installation.
    
    I performed a large number of timing runs with Python 3.4.1 under Debian
    Linux Etch, varying the number of processes and/or the percentage of
    processes which do the yield request (causing a process cancel). As to which
    version of Simulation*.py is better, all I can say: it all depends on the
    models in terms of structure (mix of "yield" command types) and number of
    processes! Significant speed improvements (many tens of percents) are
    possible.
    
    HERE IS THE HELP I AM SEEKING:
    
    (1) Run the models for different numbers of processes and send me the
    results produced by processHotshotFiles.py. Please, include data on your
    operating system, the version of Python installed and the amount of RAM in
    your machine.
    
    (2) Comment on the models and let me know whether you think they are
    sufficient to base a decision on concerning SimPy's future event handler.
    
    (3) Run other models you have which are typical for your use of SimPy with
    each of the three versions of Simulation*.py. Time them with either profile
    or hotshot and let me know the results. Include a general categorization of
    those models (e.g., many/few reneges, many/few interrupts, or many
    processes).
    
    (4) Any inputs on what you would consider good benchmark models for SimPy's
    performance are also most welcome.
    
    I will publish your inputs and my own measurements on SimPy's wiki
    (http://www.mcs.vuw.ac.nz/cgi-bin/wiki/SimPy ). Please, notice that I am not
    publishing my results 
    
    Thank you in advance for helping us to make SimPy faster!
    
    Klaus Müller 
    
    -------------------------------------------------------------------------
    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems?  Stop.
    Now Search log events and configuration files using AJAX and a browser.
    Download your FREE copy of Splunk now >>  http://get.splunk.com/
    

    Gmane