Changeset 1274 for cpp/frams/genetics/f4

Timestamp:

09/09/23 15:12:57 (8 months ago)

Author:

Maciej Komosinski

Message:

Cosmetic

Location:

cpp/frams/genetics/f4

Files:

• f4_conv.cpp (modified) (4 diffs)
• f4_oper.cpp (modified) (1 diff)

cpp/frams/genetics/f4/f4_conv.cpp

@@ -247 +247 @@
         {
                 const char* nclass = C->neuclass->name.c_str();
-                if (C->neuclass->getPreferredLocation() == 0)
+                switch (C->neuclass->getPreferredLocation())
+                {
+                case NeuroClass::PrefLocation::PREFER_UNATTACHED:
                 {
                         if (strcmp(nclass, "N") == 0) //special case just to specify the only neuron properties supported by f4, i.e., the properties for neuron class 'N'
@@ -253 +255 @@
                         else
                                 sprintf(tmpLine, "d=\"%s\"", nclass);
-                }
-                else if (C->neuclass->getPreferredLocation() == 1) // attached to Part or have no required attachment - also part
+                        break;
+                }
+                case NeuroClass::PrefLocation::PREFER_PART: // attach to Part
                 {
                         int partno = C->dadlink->p2_refno;
@@ -260 +263 @@
 
                         sprintf(tmpLine, "p=%d,d=\"%s\"", partno, nclass);
-                }
-                else // attached to Joint, assume there are only three possibilities of getPreferredLocation()
+                        break;
+                }
+                case NeuroClass::PrefLocation::PREFER_JOINT: // attach to Joint
                 {
                         int jointno = C->dadlink->joint_refno;
@@ -273 +277 @@
                         else
                                 sprintf(tmpLine, "j=%d,d=\"%s\"", jointno, nclass);
+                        break;
+                }
                 }
 

cpp/frams/genetics/f4/f4_oper.cpp

@@ -8 +8 @@
 
 
-// This representation has a tendency to bloat - adding a small penalty to fitness such as "this.velocity - 0.000000001*String.len(this.genotype);"
-// may help, but it would be better to improve the source code to make genetic operators neutral in terms of genotype length. Adding such a penalty
-// removes "work in progress" changes in genotypes thus promoting immediate, straightforward improvements while hindering slower, multifaceted progress.
+// This representation has a tendency to bloat - adding a small penalty to fitness such as "this.velocity - 0.000000001*String.len(this.genotype);" may help, but it would be better to improve the source code to make genetic operators neutral in terms of genotype length. Adding such a penalty removes "work in progress" changes in genotypes thus promoting immediate, straightforward improvements while hindering slower, multifaceted progress.
 // TODO getting rid of redundancy (valid genotypes with a lot of "junk code") in this representation looks like a good idea; many improvements to this end have already been done in April & May 2023, so maybe it is not a big problem now?
-// 
+//
 //
 // 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 '['.