[kepler-dev] ParameterSet

[Edward A. Lee]

I like the idea of distinguishing parameters from variables,
and in fact we used to do this in Ptolemy Classic.  It's an extremely
useful distinction in code generation, since parameter generate to
literal constants while variables generate to, well, variables.

However, this doesn't by itself solve Norbert's problem.
I don't think we have a solution yet.  Making the precedence rules
configurable is possible... I would do it by adding a parameter
to the ParameterSet parameter called, say, "overwriteContainerParameters"
that by default is false.  However, I still believe this is not
good behavior because it silently discards user data (it does,
Norbert... the parameter value before the overwrite is user
data... when you save the model, it's gone, and the user never
directly erased the data).  I guess if it's clearly documented
with plenty of warnings, then I can live with it.  Would Norbert
be the only one to use it?

With the parameter/variable distinction, the user data need not
be lost, since presumably if the container's parameter is a
"variable" then its initial value would be preserved.  However,
this is really subtle... User data is overwritten if you use
a Parameter, not overwritten if you use a Variable...  Seems to
me like this really borders on mysterious inexplicable behavior...

Edward

At 10:36 AM 10/29/2006, Bertram Ludaescher wrote:

>Edward, Norbert:
>
>I only now get to throw in my own 2 cents on this.
>This is a very interesting and important issue (i.e., how to deal with
>on-screen params vs. config-param settings).
>
>Clearly, part of the issue arises due to the different use cases and
>ways of using Ptolemy/Kepler:
>- as an interactive modeling or wf *design* (and testing) tool
>- vs in 'non-interactive' mode, i.e., after the design+testing is
>essentially finished.
>
>I have two suggestions:
>
>1. Allow to define a "parameter handling policy", e.g. as a command
>line option. I know that making things configurable is an old trick,
>and that is sometimes pulled too often out of the cylinder ...
>Specifically it adds to the complexity of understanding the overall
>system when one has to take into account this new param handling
>policy parameter.
>
>2. Norbert's comment on distinguishing *params* from *variables* is an
>interesting one and could be used to think about a more fundamental /
>modeling kind of solution.
>
>I guess it's in the nature of a model/workflow parameter to be quite
>static, even fixed throughout an execution (making a parameter really
>a user-definable *constant*).
>
>On the other hand, I can see uses such as parameter sweep techniques,
>where one wants to be able to run a workflow with different param
>settings.
>
>I'd like to suggest to try and find a common understanding of these
>notions. Here is an attempt:
>
>Kepler workflows/Ptolemy models have a well-defined signature/API,
>consisting of
>
>(p) immutable parameters (which can be instantiated at the beginning,
>but cannot be changed during execution)
>
>(d) "data bindings" (for Kepler, maybe not needed for Ptolemy), in a
>sense a set of "special parameters" which act as "data inputs" (data
>streams from databases) and/or "data outputs" (special, distinguished
>data(base)  sinks into which the global wf output is dumped)
>
>(v) mutable parameters or 'static *v*ariables' which get their default
>values at invocation time, but which can change dynamically during
>execution (hey, I didn't come up with the notion of 'static variable'
>for a dynamically changing entity..)
>
>Equipped with these (or similar) basic notions, we might be able to
>define a solution to the param-handling-policy problem that is more
>satisfying to the different needs!?
>
>For example, by def. (p) stuff cannot be changed during exec, but only
>at invocation time (that still allows param sweeps via higher-order
>actors which invoke the same wf/model multiple times w/ different
>p-settings.
>
>(v) can be changed during runtime. This might be a good modeling
>primitive for user-interactive wfs where the user during execution
>needs to inspect some values, then dynamically changes a parameter
>setting -- oops, excuse-moi, a mutable param/variable (v)
>
>[Aside: of course, a procedural way to do param sweeps could be to use
>(v) instead of (p)+higher-order actors. But the latter seems
>cleaner/more statically analysable and thus preferable.]
>
>Comments?
>
>Bertram
>
>
>
> >>> On Fri, 20 Oct 2006 16:52:13 -0700 (PDT)
> >>> Norbert Podhorszki <npodhorszki at ucdavis.edu> wrote:
>NP>
>NP> On Fri, 20 Oct 2006, Edward A. Lee wrote:
> >> 1) As a general rule, one should not discard user data as a
> >> side effect of some action that might seem unrelated.
> >> Changing the value of an on-screen parameter as a side effect
> >> of editing a configuration file would violate this rule.
>NP>
>NP> I do not see this. Why is it a violation? I open a workflow, the
>NP> parameters values are set according to the config file. Then I can decide
>NP> about changing them before executing the workflow. Why is this different
>NP> from opening a workflow which has no config file, just some parameters.
>NP> Their values are stored in the xml file and then I can change them before
>NP> executing the workflow.
>NP>
>NP> I do not consider the config file as user data. This is not data processed
>NP> by the workflow. This is just a convenient storage of parameters in a
>NP> separate, plain text file. Otherwise, before command-line execution, the
>NP> user should change the parameters inside the xml. Do not worry, physicist
>NP> are not afraid from doing that!
>NP>
>NP> Another option is to create a new actor, that takes a config file as input
>NP> and creates such parameters or sets the values of existing ones. And this
>NP> actor would be put into my workflows to the beginning. This resembles the
>NP> textual programming where main() first calls processArgs().
>NP>
> >> 2) It seems very complex.  Do you really want to change parameter
> >> values when you save a file?  This means that you can run,
> >> save, close, open, re-run, and get different results...
> >> This sort of inexplicable behavior is what Microsoft Word does ;-)
>NP>
>NP> Now here comes out the difference in our views. Here you refer to
>NP> parameters that may be changed by the workflow during execution. I
>NP> would like to name such entities as 'variables', not 'parameters'.
>NP> I was thinking only about parameters, i.e. read-only entities (for the
>NP> workflow execution). But you are right, with current Ptolemy parameters
>NP> this is possible.
>NP>
>NP> However, I just suggested this save option only because I thought you
>NP> would have asked first: what about the annoying situation that the user
>NP> changes the parameter on screen and then next time opens the workflow and
>NP> the old value pops up there from the config file. I do not need that
>NP> save-back feature, so we can eliminate this point.
>NP>
> >> There is actually a mechanism already that does much of what you
> >> propose:
> >>
> >> - Create a ParameterSet with a variable "foo" with value "20" (say).
> >> - Create an on-screen parameter with name "foo" and value "foo".
> >>
> >> Now, the value of foo used within the model is 20.  If I change
> >> the value of the on-screen parameter to "5" (say), then the value
> >> of foo in the model becomes 5.
> >>
> >> Would this satisfy the need?
>NP>
>NP> No, for the same two reason, as for I need the discussed behaviour:
>NP>   - no default values
>NP>   - only annoying screenshots as documentation
>NP> So rather, I just delete all on-screen parameters :-(
>NP>
>NP> Norbert
>NP>
>NP>
>NP>       Norbert Podhorszki
>NP>     ------------------------------------
>NP>       University of California, Davis
>NP>       Department of Computer Science
>NP>       1 Shields Ave, 2236 Kemper Hall
>NP>       Davis, CA 95616
>NP>       (530) 754-8188
>NP>       pnorbert at cs.ucdavis.edu
>NP>       ----------------------------------
>NP> _______________________________________________
>NP> Kepler-dev mailing list
>NP> Kepler-dev at ecoinformatics.org
>NP> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

------------
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal