RealVectorAdditiveMoveWrapper is visible through the discovery mechanism

HeuristicLab-Trac-Bot commented 13 years ago

Issue migrated from trac ticket # 1309

milestone: HeuristicLab 3.3.3 | component: PluginInfrastructure | priority: medium | resolution: done

2010-12-01 17:14:00: @discostu105 created the issue

HeuristicLab.Problems.TestFunctions.RealVectorAdditiveMoveWrapper is not a storable class. It should be one!

Update: I still think it should not be storable, but I removed the default constructor to prevent discovery.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-01 17:23:27: @abeham commented

Why?

It does not live beyond the scope of the move evaluator's apply method and will thus not get serialized.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-01 17:27:30: @discostu105 commented

When configuring a MetaOptimization parameter tree, it can be a possible operator of a parameter. When this parameter configuration tree is stored, those possible operators also need to be stored.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-01 17:37:56: @abeham commented

The RealVectorAdditiveMoveWrapper is not an operator. I don't know what you're doing, but you shouldn't use this data type in any way.

Here is the scope where it lives:
protected override double Evaluate(double quality, RealVector point, AdditiveMove move) {
  RealVectorAdditiveMoveWrapper wrapper = new RealVectorAdditiveMoveWrapper(move, point);
  return AckleyEvaluator.Apply(wrapper);
}
It's not meant to be used in any other context.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-02 09:55:00: @gkronber commented

I guess the problem is that RealVectorAdditiveMoveWrapper is a RealVector. Thus, automatic discovery of all possible values of a RealVector parameter also returns an instance of this class.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-02 10:40:12: @abeham commented

How can I prevent such a discovery? Would it be enough to kill the default constructor (which doesn't make sense anyway) so that a default instance cannot be created?

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 12:55:03: @abeham changed status from new to accepted

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 12:55:03: @abeham commented

I will remove the default constructor.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 13:00:07: @abeham changed status from accepted to reviewing

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 13:00:07: @abeham changed owner from abeham to cneumuel

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 13:00:07: @abeham changed milestone from HeuristicLab x.x.x to HeuristicLab 3.3.3

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 13:00:07: @abeham edited the issue description

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 13:00:07: @abeham changed title from RealVectorAdditiveMoveWrapper is not storable to RealVectorAdditiveMoveWrapper is visible through the discovery mechanism

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-07 13:00:07: @abeham commented

r5058

Removed default constructor to prevent discovery

Please check if this solved your problem, otherwise we'll make it Storable.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-15 09:13:15: @discostu105 changed status from reviewing to assigned

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-15 09:13:15: @discostu105 changed owner from cneumuel to abeham

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-15 09:13:15: @discostu105 commented

The current solution throws an exception when the type is discovered. This can be verified with the following code:
var items = ApplicationManager.Manager.GetInstances(typeof(DoubleArray)).ToArray();
Exception: System.MissingMethodException: No parameterless constructor defined for this object.

The exception is thrown directly in LightweightApplicationManager.GetInstances and is uncaught:
    public IEnumerable<object> GetInstances(Type type) {
      return from t in GetTypes(type, true)
             select Activator.CreateInstance(t);
    }
Now, I certainly could catch the exception in my code, but this implementation would make it possible to break other plugins by introducing types without parameterless constructors. In my opinion either the ApplicationManager should catch the exception (1), or types which must not be discovered should be attributed with something like [Undiscoverable] (2). Or we just make RealVectorAdditiveMoveWrapper Storable (3).

(1) has the disadvantage that types which accidentally have no parameterless constructor can be introduced without any warning.

(2) would force the developer to think about the type discovery mechanism which i think is OK for types which should explicitly not be discovered.

(3) ok, if the scenario that a type should not be discoverable is really rare.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-15 09:13:15: @discostu105

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-17 15:01:47: @s-wagner changed status from assigned to accepted

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-17 15:01:47: @s-wagner changed owner from abeham to swagner

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-17 16:23:07: @s-wagner commented

Implemented solution (1) in r5131. Solution has been reviewed by abeham and mkommend.

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-17 16:23:37: @s-wagner changed status from accepted to readytorelease

HeuristicLab-Trac-Bot commented 13 years ago

2010-12-17 16:23:37: @s-wagner changed component from Problems.TestFunctions to PluginInfrastructure

HeuristicLab-Trac-Bot commented 13 years ago

2011-02-05 19:07:44: @mkommend changed status from readytorelease to closed

HeuristicLab-Trac-Bot commented 13 years ago

heal-research / HeuristicLab