[vistrails-dev] [VisTrails Trac] #523: Default values for parameters not showing

Juliana Freire juliana at cs.utah.edu
Sat Jan 21 17:31:45 EST 2012


Hi Dave,

> should the defaults always be written out when the parameter is
> selected or only when values are changed from the defaults? 

If the default values are used when the workflow is run,  for the provenance to be complete, they should be stored.


>  I change a module to work with Kelvin temperatures instead of
> Celsius, my defaults will also likely change, but it is not valid to
> compare the two values (whether they are defaults or not) because the
> parameters are different.

But in this scenario, you are changing the semantics of the module in a way that is not visible to VisTrails.
If C or K are parameters, then the analysis would work---you would be able to see the values as well as the scale.

> I am also thinking about VTK here, where there are default values that are
> not currently specified as VisTrails defaults.  

Is it hard to show the defaults that are used? Maybe a compromise here we could do what you suggest: explicitly distinguish in the interface values set by the user from the default values. (Or maybe, if the interface becomes to cluttered, users could be given the option to hide default parameters).

> Thus, keeping a parameter
> "unset" means that this default value is used, but here as well, the
> provenance does not reflect the use of such defaults.  

I think the provenance should reflect the results.

> Here, the size of
> the provenance would dramatically increase if defaults were specified and
> written out each time because there are a large number of parameters (and
> defaults) for each module.

I think that if this indeed becomes a problem, we could try to do some normalization. For example, save default parameters only once for a module. 

Best,
Juliana



On Jan 21, 2012, at 4:59 PM, VisTrails Trac wrote:

> #523: Default values for parameters not showing
> ---------------------+-------------------------
>  Reporter:  dakoop  |      Owner:  dakoop
>      Type:  defect  |     Status:  new
>  Priority:  major   |  Milestone:  version 2.0
> Component:  core    |    Version:  master
> Resolution:          |   Keywords:
> ---------------------+-------------------------
> 
> Comment (by dakoop):
> 
> The code was missing from the new ports panel for this.  However, there is
> a design question here that I would like to resolve before committing the
> change: should the defaults always be written out when the parameter is
> selected or only when values are changed from the defaults?  For example,
> Qt 4.7 supports "placeholder text" so for standard line editors I could
> show what the default value is but indicate that the value has not been
> set by the user.
> 
> However, I believe that Matthias originally requested this feature so that
> default values would be written to provenance.  This simplified the
> analysis if a future version of the module changed the default value.
> Instead of finding the old version of the code to determine the default,
> one could examine the provenance. As I am rethinking this, I wonder if
> this approach can be as problematic as the non-persisted defaults.  For
> example, if I change a module to work with Kelvin temperatures instead of
> Celsius, my defaults will also likely change, but it is not valid to
> compare the two values (whether they are defaults or not) because the
> parameters are different.  Thus, one needs to look at the code to properly
> interpret the provenance anyway...
> 
> I am also thinking about VTK here, where there are default values that are
> not currently specified as VisTrails defaults.  Thus, keeping a parameter
> "unset" means that this default value is used, but here as well, the
> provenance does not reflect the use of such defaults.  Here, the size of
> the provenance would dramatically increase if defaults were specified and
> written out each time because there are a large number of parameters (and
> defaults) for each module.
> 
> -- 
> Ticket URL: <https://www.vistrails.org/ticket/523#comment:1>
> VisTrails Trac <https://www.vistrails.org/>
> VisTrails Project
> _______________________________________________
> vistrails-dev mailing list
> vistrails-dev at vistrails.org
> http://lists.vistrails.org/mailman/listinfo/vistrails-dev
> 



More information about the vistrails-dev mailing list