New parameter type for storing results

[mkommend]

It is quite cumbersome to store results in the result collection from an analyzer. One has to look up the result collection, check if the results already exists and eventually create it and set the value. This procedure is the same for each produced results and should be performed by a specialized parameter, so that all of the steps above are simplified to:

ResultsParameter.Value = bestSolution;

The following functionality should be provided:

• ResultsParameter automatically look up the results collection
• ResultsParameter provide a ResultsName property
• It is possible to set an initial value of the ResultsParameter (avoid null checks)
• The indexer of ResultCollection should return the value instead of the result

Furthermore, the results parameter should provide the possibility to change the name of the produced result.

[abeham]

Patching the trunk to include the result parameter, also adapts QualityDistributionAnalyzer to use this new parameter

[abeham]

Please have a look at the patch. A few issues that should be noted here that have also been discussed:

• The new parameter halves the amount of LOC in the Apply method of the QualityDistributionAnalyzer. The ctor becomes a bit more complex though. There is a much nicer separation though. Additionally, there is the benefit that the ResultName may be configured in the GUI without additional parameters.
• It is not possible to put this parameter in the HeuristicLab.Parameters plugin. The reason is that ResultCollection is not accessible in this assembly. It was decided to put it into HeuristicLab.Optimization.
• A new interface IContextualParameter was introduced that is the new base to ILookupParameter and IResultParameter and which exposes only the ExecutionContext property. This is needed, because Operator currently only sets the ExecutionContext for ILookupParameters. IContextualParameter may not yet be the final name (suggestions necessary).
• A view for the new parameter is not yet included in the patch.
• Backwards compatibility of the adapted operator is not accounted for.

[abeham]

Derive ResultParameter<T> from LookupParameter<ResultCollection> and reuse the lookup mechanism.

[abeham]

Improved patch (deriving result parameter from lookup parameter)

[abeham]

Please have a look at the new patch. I regrouped files in HeuristicLab.Optimization and made the changes described in the architects meeting.

Open points:

• Make the ResultParameter class a [NonDiscoverableType], as otherwise users would probably use them in the GUI - they don't do anything when added in the GUI
• I put the interface in HeuristicLab.Optimization and chose to derive from ILookupParameter<ResultCollection> so that I can derive from the lookup parameter's view

[abeham]

Btw, I did come up with cases where ResultParameter makes sense in the GUI. E.g. when making a ProgrammableAnalyzer I would want to add a ResultParameter. But then the problem is that we need to configure the DefaultValue in the GUI.

[mkommend]

Reviewed the attached patch resultparameter2.patch. IMHO the changes look fine and are ready for inclusion in the trunk. However, two minor improvements should be included:

• A different item image for result parameters, to distinguish them in the GUI (save as?)
• The result type should also be displayed in the ResultParameterView

[mkommend]

r14037: Refactored LookupParameter<T> to prepare for the ResultsParamter and make the name translation methods reusable.

[mkommend]

Reused parameter lookup introduced in r14037

[abeham]

r14056:

• Moved check if context contains a parameter of the requested translated name to the front of the loop
  • Reason is that ResultsParameter queries for a parameter "Results" which doesn't exist in its own context
• Added a flag to suppress the type check in LookupParameter's GetValue
  • Default value of that flag is true, so existing code is not affected
  • Reason is that ResultsParameter queries for ResultCollection while having a generic type e.g. IntValue which don't match
• Replaced some ContainsKey/Access combinations with TryGetValue

[abeham]

r14057: moved type verification to member method

[abeham]

The ResultsParameter has been committed to the PerformanceComparison branch in r14058:14059. I used the exception icon as it is more subtle and also fits more nicely into a pattern with the OperatorParameter. Also, it's a discoverable type now and can be used in e.g. ProgrammableOperators.

[mkommend]

Reviewed r14056, r14057 and the classes for the results parameter in the performance comparison branch (IResultParameter, ResultParamter, and ResultParameterView).

[abeham]

r14071: merged ResultParameter to trunk

I removed two references from Parameters.Views to Optimization and Optimization.Views respectively, because I needed them they other way around. They were not necessary for Parameters.Views.

We should release revisions: 14037,14056,14057,14071.

Please forward ticket to release if you're ready.

[mkommend]

I am ready.

[abeham]

r14100: Fixed description of result parameter not appearing in result (thx to mkommend)

[mkommend]

r14133: Merged r14037,r14056,r14057,r14071, r14100 into stable.

[abeham]

r14136:

• made setter more robust and removed redundant null check
• I had a backwards compatibility problem with previously stored files, resultCollectionName could never be set if it was null to begin with

[abeham]

r14138: merged r14136 to stable