[kepler-users] 3 Qs re: PythonScript, tokenConsumptionRate, portparameters, and polymorphism

[Rick Moore]

Tom,
some additional comments are in line
Rick

Tom Parris wrote:
> Rick,
>
> Thanks!  This is very helpful.  I'll read the Ptolemy document more 
> thoroughly and try again.
>
> The basic challenge I'm having is translating from java examples to 
> python. I've been experimenting with the optional methods.   In the 
> Java examples I've been looking at (e.g., Repeat, DownSample) the 
> constructor method is used to: create and set parameters, and sets the 
> input_tokenConsumptionRate and output_tokenConsumptionRate.  The same 
> is true for SDFTranformer (from which these examples are subclassed). 
> That is what led me to try the same in Python (with the __init__ 
> method). 
>
the initialize(0 and preinitialize() methods provide support for what 
you would normally do in __init__(). preinitialize() is called just once 
in each run, however, there are circumstances where initialize() may be 
called more than once ... I don;t understand what those circumstances 
are. In practice, I use preinitialize() to read true parameters (those 
defined in "Configure Actor") and store them into Python instance 
attributes.
> The other challenge I'm having is reading n elements from an input 
> port, but only consuming m elements (where 0<=m<=n) in order to 
> implement sliding window actors.  Given the code for IOPort.java, I'm 
> not convinced this is even possible. It looks (to the untrained eye) 
> that every call to get implicitly pops tokens off the channel.
You must read all tokens from a port on each fire. My suggestion is to 
read the all of the tokens and either store the extras in a Python 
attribute or just ignore them.
>
> I'll work both challenges some more and get back to you offline if I 
> still need help.
>
> -- Tom
>
> On Tue, Nov 24, 2009 at 11:04 AM, Rick Moore <rem63 at cornell.edu 
> <mailto:rem63 at cornell.edu>> wrote:
>
>     Tom,
>
>     I ran your workflow and both ports had the correct values ... but
>     your script doesn't currently do anything with the blocksize
>     except print it to stdout (which in kepler is the console). And
>     that works as well.
>
>     A PythonActor doesn't communicate with it's scripts through the
>     standard Python __init__ method. Rather it expects the Python
>     scripts to implement the same methods that a Java actor might
>     implement. Of course, you already use fire(), but there are
>     several other optional methods available :
>
>     def preinitialize(self) ... set port types and/or scheduling
>     information ...
>     def initialize(self) ... initialize local variables ...
>     def prefire(self) ... determine whether firing should proceed ...
>     a good place to check whether the execution environment is valid
>           if you use it, it must return True to proceed,  False if
>     there is some problem ... no return value is the same as False
>           the fire(0 method will be called only if prefire() returns True
>     def postfire(self) ... update persistent state and/or determine
>     whether firing should continue to next iteration
>          if you use it, it must return True to proceed,  False if
>     there is some problem ... no return value is the same as False
>          returning False will terminate the workflow
>     def wrapup(self) ... cleanup and display final results ...
>          I use this to reset to the initial state after the last iteration
>
>     Designing actors is discussed in detail in chapter 5 of the
>     document at
>     http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-28.pdf
>
>     If you want, I can help you in more detail off list.
>
>     Rick Moore
>     Information Science
>     Cornell University
>
>     "Once in a while you will be shown the light in the strangest of
>     places, if you look at it right"
>     from Scarlet Begonias by the Grateful Dead
>
>     Tom Parris wrote:
>>     Dear Keplerites:
>>
>>     I have been making steady progress understanding how to write
>>     actors for Kepler using the PythonScript actor.  However, I have
>>     hit a stumbling block in my attempts to set
>>     input_tokenConsumptionRate.  
>>
>>     To illustrate my problem, I have attached a simple workflow with
>>     an actor titled "IntTokenSum" written with the PythonScript
>>     actor.  This actor is designed to add some number of integer
>>     tokens from it's "input" port.  The number of tokens is defined
>>     by the "windowsize" port.  The number of tokens to consume with
>>     each "fire" is defined with the "blocksize" port.   The current
>>     version works as desired with the exception of the blocksize
>>     input prot (it always takes on the value of the windowsize input
>>     port).
>>
>>     Q1: As the script is currently configured, the windowsize
>>     parameter works as advertised.  However, I can't seem to get the
>>     blocksize parameter to work.  I've tried a number of approaches
>>     to setting the input_tokenConsumptionRate per the java code for
>>     several actors (e.g., DownSample).  But now I'm wondering if that
>>     is the correct approach.  Perhaps its the call to self.input.get
>>     that needs to be changed.  Correct output on Display2 should be
>>     the sequence: 1, 3, 5, 7, 9, 11, 13, 15, 17.
>>
>>     Q2: I'd also like to use an actor along these lines under the SDF
>>     director with portparameters for windowsize and blocksize.  But
>>     can't figure out how to to this with the PythonScript actor.  Is
>>     this possible?  If so, I would welcome guidance.
>>
>>     Q3: Finally, it should be fairly easy to make this actor
>>     polymorphic.  I think this can be done by changing the line:
>>
>>        val = val + it.intValue()
>>
>>     to
>>
>>        val = it.add(val)
>>
>>     But I am not sure how to initialize val to the additive identity
>>     (generalized notion of zero).
>>
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Kepler-users mailing list
>>     Kepler-users at kepler-project.org <mailto:Kepler-users at kepler-project.org>
>>     http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20091124/3c9def07/attachment.html>