Changeset 1247

Timestamp:

05/21/23 22:52:02 (18 months ago)

Author:

Maciej Komosinski

Message:

Cosmetic

Location:

cpp/frams/genetics

Files:

• f1/f1_conv.cpp (modified) (1 diff)
• f4/f4_oper.cpp (modified) (1 diff)
• geneprops.h (modified) (1 diff)
• genooperators.cpp (modified) (2 diffs)

cpp/frams/genetics/f1/f1_conv.cpp

@@ -199 +199 @@
                                 setPartMapping(part1, g);
                                 SList ga;
-                                int i, count;
-                                count = countBranches(g + 1, ga);
+                                int count = countBranches(g + 1, ga);
                                 c.muscle_reset_range = false;
                                 c.muscle_bend_range = 1.0 / count;
-                                for (i = 0; i < count; i++)
+                                for (int i = 0; i < count; i++)
                                         grow(part1, (char*)ga(i), k + Pt3D(0, 0, -M_PI + (i + 1)*(2 * M_PI / (count + 1))), c, part1);
                                 return;

cpp/frams/genetics/f4/f4_oper.cpp

@@ -15 +15 @@
 //
 // TODO the behavior of neuron input indexes during mutation seems badly implemented (see also TREAT_BAD_CONNECTIONS_AS_INVALID_GENO). Are they kept properly maintained when nodes are added and removed? This could be done well because during mutation we operate on the tree structure with cross-references between nodes (so they should not be affected by local changes in the tree), and then convert the tree back to string. Yet, the f4_Node.conn_from is an integer and these fields in nodes do not seem to be maintained on tree node adding/removal... change these integer offsets to references to node objects? But actually, do the offsets that constitute relative connection references concern the f4_Node tree structure (and all these sophisticated calculations of offsets during mutation are useful) or rather they concern the f4_Cells development? verify all situations in f4_Cell::oneStep(), case '['.
-// TODO in mutation, adding the '#' gene does not seem to be effective. The gene is added and genotypes are valid, but hardly ever #n is effective, i.e., it hardly ever multiplicates body or brain parts... investigate!
+// TODO in mutation, adding the '#' gene does not seem to be effective. The gene is added and genotypes are valid, but hardly ever #n is effective, i.e., it hardly ever multiplicates body or brain parts... investigate! And maybe, during repair or mutations, simplify/remove ineffective #N genes, if there is no chance/hardly any chance that they will be turned effective after future mutation (or crossover)
 // TODO add support for properties of (any class of) neurons - not just sigmoid/force/intertia (':' syntax) for N
 // TODO add mapping genotype character ranges for neural [connections]
-// TODO The f0 genotypes for /*4*/<<RX>X>X> and RX(X,X) are identical, but if you replace R with Q or C, there are small differences - check why and perhaps unify?
+// TODO The f0 genotypes for /*4*/<<RX>X>X> and RX(X,X) are identical, but if you replace R with Q or C, there are small differences (they were present both before and after the Q,C change in f1 in 2023-05) - check why and perhaps unify?
 // TODO F4_SIMPLIFY_MODIFIERS in f4_general.cpp: currently it works while parsing (which is a bit "cheating": we get a phenotype that is a processed version of the genotype, thus some changes in modifiers in the genotype have no effect on its phenotype). Another (likely better) option, instead of simplifying while parsing, would be during mutations (like it is done in f1): when mutations add/modify/remove a modifier node, they could "clean" the tree by simplifying modifiers on the same subpath just as GenoOperators::simplifiedModifiers() does. This way, simplifying would be only performed when we actually modify a part of a genotype, not each time we interpret it, and there would be no hidden mechanism: all visible genes would have an expected effect on the phenotype.
 

cpp/frams/genetics/geneprops.h

@@ -119 +119 @@
         double assimilation;      ///<incremented by A, decremented by a. Biological property, assimilation, photosynthesis (a vertical stick can assimilate twice as much as horizontal one)
         double stamina;           ///<incremented by S, decremented by s. Biological property, stamina (increases chance of survival during fights)
-        double ingestion;         ///<incremented by I, decremented by i. Biological property, ingestion (ability to gain energy from food)
+        double ingestion;         ///<incremented by I, decremented by i. Biological property, ingestion (ability to gain/transfer energy from food)
 
         double twist;             ///<incremented by Q, decremented by q. Twist of a stick

cpp/frams/genetics/genooperators.cpp

@@ -4 +4 @@
 
 #include <ctype.h>  //isupper()
+#include <algorithm> // std::min, std::max
 #include "genooperators.h"
 #include <common/log.h>
 #include <common/nonstd_math.h>
 #include <frams/util/rndutil.h>
-#include <algorithm> // std::min, std::max
 
 //
@@ -537 +537 @@
 string GenoOperators::simplifiedModifiers(const string & original)
 {
-        const int MAX_NUMBER_SAME_TYPE = 6; // max. number of modifiers of each type (case-insensitive). rR is treated separately in simplification because their influence follows different (i.e., simple additive) logic - so the simplifiedModifiersFixedOrder() logic with cancelling out antagonistic modifiers is appropriate for rR.
+        const int MAX_NUMBER_SAME_TYPE = 5; // max. number of modifiers of each type (case-insensitive). The more characters, the closer we can get to min and max values of a given property at the expense of the length of evolved genotypes. 5 is "close enough", but how close we get to the extreme also depends on the initial value of a given property, which is not always exactly in the middle of min and max. rR is treated separately in simplification because their influence follows different (i.e., simple additive) logic - so the simplifiedModifiersFixedOrder() logic with cancelling out antagonistic modifiers would be appropriate for rR.
         int counter[256] = {}; //initialize with zeros; 256 is unnecessarily too big and redundant, but enables very fast access (indexed directly by the ascii code)
         string simplified = "";