[kepler-dev] ParameterSet

[Edward A. Lee]

Interesting...

I see your point about the non-interactive use of a workflow.
However, there are two aspects of your solution that I don't like:

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.

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

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?

Edward

At 09:56 AM 10/20/2006, Norbert Podhorszki wrote:

>Edward,
>
>I have only a long answer, however I try to propose a synthesis at the end.
>
>I also think I understand your position here, and respectfully 
>agree. At least about the locality.
>
>The difference in our position is really in our real position in 
>front of the screen. Namely, you are talking about using Ptolemy 
>models within Vergil. I am talking about finished/published software 
>used by those who actually do not care about if that software was 
>written in Fortran or MoML.
>
>If you do not look at the workflow graph, just use it, what is more 
>visible and most local to you? The parameters in the workflow, or 
>the parameters in the config file, you have just recently edited?
>
>Some languages allow you to set default values for 
>function/procedure arguments, some for object fields. If you debug 
>the code, entering such procedure or create an object, do you expect 
>the actual value to be what you see on screen (the default value) - 
>which is most visible and most local -, or rather the arguments 
>given in the call/constructor?
>
>Obviously, you may defend the current status asking that what is the need
>for on-screen parameters if the user never looks at it. They just 
>should configure the workflow in the config file. One argument is 
>allowing the workflow have default values. However, I may accept 
>this situation if you make my (the developer's) life easier. I still 
>want to use on-screen parameters in the workflow during the 
>development and for nice screenshots. If I could "comment" them out 
>at the end, then the current behaviour of Ptolemy would be OK for 
>me. As far as I know, MoML is the first language without comments, 
>at least among modern languages. Surely, you have some forum threads 
>in the past about why is there no such feature, don't you ;-)?
>
>What about satisfying both of us, instead? I propose the following behaviour:
>
>1. Whichever exists alone in the workflow (on-screen parameter or config
>    file parameter), is in effect.
>2. Having both, at opening the workflow, the on-screen parameters are
>    updated to the values of the config file. (defaults are overwritten).
>3. If you change on-screen parameters,
>    a. this becomes in effect and
>    b. write the value into the config back at Save (or ask before)
>4. If you have a config parameter and then you drag a parameter onto the
>    screen, and rename it to the existing parameter,
>    a. if you have not set its value yet, give it the existing config value
>       automatically
>    b. if you have set its value before renaming to an existing name,
>       - either set that value to be in effect, or
>       - ask what to do
>5. If you have a parameter on-screen and then drag a ParameterSet and
>    provide a config file including that parameter, then update the
>    on-screen parameter's value.
>
>I tend to believe, that the problem is lying in the current 
>implementation, that you have actually two different entities with 
>the same name and we are arguing about their precedence. If they 
>were the same entity with two different methods to set its value, 
>the above behaviour would be natural.
>
>The above behaviour satisfies you when staring at Vergil, and it 
>satisfies my users when running the workflow from command-line. 
>Actually, I am not concerned about your acceptance the most but 
>about poor Christopher's who must cry out when reading points 3b and 
>4... Also, problems arise for point 2 from the fact, that 
>ParameterSet is just an attribute and there is currently no way to 
>force to be evaluated after all other entities are created, or at 
>least force to be the last entity in the MoML file.
>
>I would not be surprised if the easiest solution were a new Ptolemy 
>built-in feature for supporting config files and not forcing the use 
>of attributes.
>
>What are your opinions and work-estimate for the above?
>Norbert
>
>
>On Thu, 19 Oct 2006, Edward A. Lee wrote:
>
>>
>>Norbert,
>>
>>I think I understand your position here, but respectfully disagree...
>>
>>It is my opinion that things that are most visible and most local
>>should take precedence over things that are less visible and less local.
>>This seems rather obvious to me, in fact...  It would be far more confusing
>>if parameter staring you in the face had no effect on execution of a model,
>>and instead some parameter hidden away in some file took precedence over it.
>>
>>The rest of the precedence rules follow this principle of favoring 
>>locality...
>>
>>Edward
>
>
>      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
>      ----------------------------------

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