Free cookie consent management tool by TermsFeed Policy Generator

Opened 10 years ago

Closed 10 years ago

#2376 closed defect (worksforme)

Selection of function symbols from the grammar is biased

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

Description (last modified by gkronber)

Steps to reproduce:

  • Create symbolic regression problem
  • Also activate "Special Functions" group in the grammar
  • Start a run

Expected: distribution of function symbols in the initial population should be nearly uniform. Actual: Symbols from the "Arithmetic Functions" group are much more likely then symbols from the "Special Functions" group.

As explained in the comments below the likely reason for this is that the tree creator (PTC2) introduces a bias against unary functions because it must also produce larger trees.

Attachments (1)

Script - Symbol Distribution.hl (7.2 KB) - added by mkommend 10 years ago.

Download all attachments as: .zip

Change History (4)

Changed 10 years ago by mkommend

comment:1 Changed 10 years ago by mkommend

This is simply not true. The symbol selection does not prefer any symbols, regardless of the group size. See the attached script which calculates the symbol distribution for any arbitrary number of created tree.

I suspect that the phenomena you are seeing results from the interplay between the grammar, the tree creator and the size constraints. All special symbols are unary symbols and to create larger trees within the depth limits, binary symbols have to be included in the trees.

comment:2 Changed 10 years ago by gkronber

  • Description modified (diff)
  • Summary changed from Selection of function symbols from the grammar prefers symbols from smaller groups to Selection of function symbols from the grammar is biased

Thanks for inspecting this.

comment:3 Changed 10 years ago by gkronber

  • Resolution set to worksforme
  • Status changed from new to closed

Solution to this problem is to set very large depth limits.

Note: See TracTickets for help on using tickets.