[kepler-dev] ParameterSet

Norbert Podhorszki pnorbert at cs.ucdavis.edu
Fri Oct 20 16:52:13 PDT 2006


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.

I do not see this. Why is it a violation? I open a workflow, the 
parameters values are set according to the config file. Then I can decide
about changing them before executing the workflow. Why is this different 
from opening a workflow which has no config file, just some parameters.
Their values are stored in the xml file and then I can change them before
executing the workflow.

I do not consider the config file as user data. This is not data processed
by the workflow. This is just a convenient storage of parameters in a 
separate, plain text file. Otherwise, before command-line execution, the 
user should change the parameters inside the xml. Do not worry, physicist 
are not afraid from doing that!

Another option is to create a new actor, that takes a config file as input
and creates such parameters or sets the values of existing ones. And this 
actor would be put into my workflows to the beginning. This resembles the 
textual programming where main() first calls processArgs().

> 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 ;-)

Now here comes out the difference in our views. Here you refer to 
parameters that may be changed by the workflow during execution. I 
would like to name such entities as 'variables', not 'parameters'.
I was thinking only about parameters, i.e. read-only entities (for the
workflow execution). But you are right, with current Ptolemy parameters 
this is possible.

However, I just suggested this save option only because I thought you 
would have asked first: what about the annoying situation that the user 
changes the parameter on screen and then next time opens the workflow and 
the old value pops up there from the config file. I do not need that 
save-back feature, so we can eliminate this point.

> 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?

No, for the same two reason, as for I need the discussed behaviour:
  - no default values
  - only annoying screenshots as documentation
So rather, I just delete all on-screen parameters :-(

Norbert


      Norbert Podhorszki
    ------------------------------------
      University of California, Davis
      Department of Computer Science
      1 Shields Ave, 2236 Kemper Hall
      Davis, CA 95616
      (530) 754-8188
      pnorbert at cs.ucdavis.edu
      ----------------------------------


More information about the Kepler-dev mailing list