Opened 3 years ago

Closed 20 months ago

#2175 closed feature request (done)

Calculate the complexity of symbolic expression trees

Reported by: mkommend Owned by: mkommend
Priority: medium Milestone: HeuristicLab 3.3.13
Component: Problems.DataAnalysis.Symbolic Version: 3.3.12
Keywords: Cc:

Description (last modified by mkommend)

Currently the only measure that gives an indication of the complexity of an symbolic data analysis model is the length of the expression tree. Better estimators based on the the tree length or the functional complexity are needed to perform multi-objective optimization.

Change History (33)

comment:1 Changed 3 years ago by mkommend

  • Status changed from new to accepted

comment:2 Changed 3 years ago by mkommend

Branch creation

r10748: Added branch folder for complexity analysis.
r10749: Branched DataAnalysis.Symbolic with local changes.
r10750: Branched DataAnalysis.Symbolic.Regression with local changes.
r10751: Added solution for complexity analysis.

Last edited 3 years ago by mkommend (previous) (diff)

comment:3 Changed 3 years ago by mkommend

r11310: Merged trunk changes into complexity branch.

comment:4 Changed 3 years ago by mkommend

  • Description modified (diff)

comment:5 Changed 3 years ago by mkommend

r11407: Added nested tree size evaluator and simplification operator.

comment:6 Changed 2 years ago by mkommend

r11861: Merged trunk changes.

comment:7 Changed 2 years ago by mkommend

r11862: Commited additional files from trunk merge.

comment:8 Changed 2 years ago by mkommend

r11863: Corrected accidentally commited type in tree simplifier.

comment:9 Changed 2 years ago by mkommend

r11883: Additional calculation of results for EuroCast 2015.

comment:10 Changed 2 years ago by mkommend

r12130: Updated complexity branch with trunk changes.

comment:11 Changed 2 years ago by mkommend

r12147: Added rounding of quality values to multi-objective sym reg evaluators.

comment:12 Changed 2 years ago by mkommend

r12187: Corrected error in complexity calculation for sine.

comment:13 Changed 2 years ago by mkommend

r12214: Merged trunk changes into complexity branch.

comment:14 Changed 2 years ago by mkommend

  • Milestone changed from HeuristicLab 3.3.x Backlog to HeuristicLab 3.3.12

comment:15 Changed 2 years ago by mkommend

r12233: Merged trunk changes.

comment:16 Changed 2 years ago by mkommend

  • Milestone changed from HeuristicLab 3.3.12 to HeuristicLab 3.3.13

comment:17 Changed 2 years ago by mkommend

r12848: Merged trunk changes and extracted parameters of evaluators to their base class.

comment:18 Changed 2 years ago by mkommend

r12849: Updated license year to 2015.

comment:19 Changed 2 years ago by mkommend

r12850: Forgot to commit merge info and some files in r12848.

comment:20 Changed 20 months ago by mkommend

r13211: Added parameter for constant optimization iterations.

comment:21 Changed 20 months ago by mkommend

r13213: Merged trunk changes into branch for complexity analysis. r13216: Merge info commit for ComplexityAnalyzer branch.

Last edited 20 months ago by mkommend (previous) (diff)

comment:22 Changed 20 months ago by mkommend

r13220: Improve source code and usability of complexity calculator.

comment:23 Changed 20 months ago by mkommend

r13221: Removed unused features from complexity analysis.

comment:24 Changed 20 months ago by mkommend

  • Owner changed from mkommend to gkronber
  • Status changed from accepted to reviewing

I recommend to perform the trunk integration locally and just review the changes in the working copy. Otherwise it could be quite cumbersome to identify all changes.

comment:25 Changed 20 months ago by gkronber

r13241: merged all changes from branch to trunk (preserving the original .csproj-files so that I don't have to change reference and output paths)

comment:26 follow-up: Changed 20 months ago by gkronber

Review comments:

  • Why is the tree simplified twice in the SymbolicDataAnalysisExpressionTreeSimplificationOperator?
  • I think it is more readable if cases that are treated equally in the ComplexityCalculater have 'fall-through' cases in the switch statement.
  • The calculation of the complexity for the power and root symbol should be explained (in a comment?)
  • Why have properties TrainingBestSolutions and TrainingBestsolutionQualities in ...MultiObjectiveTrainingBestSolutionAnalyzer been changed from public to private? The values are accessible anyway through the parameter properties.

r13300: made some changes while reviewing the code r13307: fixed a typo while reviewing

Last edited 20 months ago by gkronber (previous) (diff)

comment:27 Changed 20 months ago by gkronber

  • Owner changed from gkronber to mkommend
  • Status changed from reviewing to readytorelease

comment:28 Changed 20 months ago by gkronber

  • Version changed from branch to 3.3.12

comment:29 Changed 20 months ago by gkronber

r13308: terminated feature branch (changesets have been merged to trunk)

comment:30 Changed 20 months ago by gkronber

Release following changesets to stable before closing this ticket as done:

comment:31 Changed 20 months ago by mkommend

r13310: Merged r13241, r13300, r13307, r13308 into stable.

comment:32 in reply to: ↑ 26 Changed 20 months ago by mkommend

Replying to gkronber:

Review comments:

  • Why is the tree simplified twice in the SymbolicDataAnalysisExpressionTreeSimplificationOperator?

Because the simplifier does not perform all simplification in one pass. Hence, the simplifier is called twice.

  • I think it is more readable if cases that are treated equally in the ComplexityCalculater have 'fall-through' cases in the switch statement.

I totally agree.

  • The calculation of the complexity for the power and root symbol should be explained (in a comment?)

The calculation of the complexity of power and root have not been extensively tested, because I use mostly use square and square root while modeling instead of power and root.

  • Why have properties TrainingBestSolutions and TrainingBestsolutionQualities in ...MultiObjectiveTrainingBestSolutionAnalyzer been changed from public to private? The values are accessible anyway through the parameter properties.

Because these access the actual value of the lookup parameters and are therefore only accessible when an execution context is set for the operator (exception otherwise). When I access those values through the ILookupParameter I am aware of this issue.

r13300: made some changes while reviewing the code r13307: fixed a typo while reviewing

Thanks

comment:33 Changed 20 months ago by mkommend

  • Resolution set to done
  • Status changed from readytorelease to closed
Note: See TracTickets for help on using tickets.