Changeset 1247


Ignore:
Timestamp:
05/21/23 22:52:02 (10 months ago)
Author:
Maciej Komosinski
Message:

Cosmetic

Location:
cpp/frams/genetics
Files:
4 edited

Legend:

Unmodified
Added
Removed
  • cpp/frams/genetics/f1/f1_conv.cpp

    r1244 r1247  
    199199                                setPartMapping(part1, g);
    200200                                SList ga;
    201                                 int i, count;
    202                                 count = countBranches(g + 1, ga);
     201                                int count = countBranches(g + 1, ga);
    203202                                c.muscle_reset_range = false;
    204203                                c.muscle_bend_range = 1.0 / count;
    205                                 for (i = 0; i < count; i++)
     204                                for (int i = 0; i < count; i++)
    206205                                        grow(part1, (char*)ga(i), k + Pt3D(0, 0, -M_PI + (i + 1)*(2 * M_PI / (count + 1))), c, part1);
    207206                                return;
  • cpp/frams/genetics/f4/f4_oper.cpp

    r1241 r1247  
    1515//
    1616// 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 '['.
    17 // 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!
     17// 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)
    1818// TODO add support for properties of (any class of) neurons - not just sigmoid/force/intertia (':' syntax) for N
    1919// TODO add mapping genotype character ranges for neural [connections]
    20 // 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?
     20// 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?
    2121// 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.
    2222
  • cpp/frams/genetics/geneprops.h

    r1246 r1247  
    119119        double assimilation;      ///<incremented by A, decremented by a. Biological property, assimilation, photosynthesis (a vertical stick can assimilate twice as much as horizontal one)
    120120        double stamina;           ///<incremented by S, decremented by s. Biological property, stamina (increases chance of survival during fights)
    121         double ingestion;         ///<incremented by I, decremented by i. Biological property, ingestion (ability to gain energy from food)
     121        double ingestion;         ///<incremented by I, decremented by i. Biological property, ingestion (ability to gain/transfer energy from food)
    122122
    123123        double twist;             ///<incremented by Q, decremented by q. Twist of a stick
  • cpp/frams/genetics/genooperators.cpp

    r1243 r1247  
    44
    55#include <ctype.h>  //isupper()
     6#include <algorithm> // std::min, std::max
    67#include "genooperators.h"
    78#include <common/log.h>
    89#include <common/nonstd_math.h>
    910#include <frams/util/rndutil.h>
    10 #include <algorithm> // std::min, std::max
    1111
    1212//
     
    537537string GenoOperators::simplifiedModifiers(const string & original)
    538538{
    539         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.
     539        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.
    540540        int counter[256] = {}; //initialize with zeros; 256 is unnecessarily too big and redundant, but enables very fast access (indexed directly by the ascii code)
    541541        string simplified = "";
Note: See TracChangeset for help on using the changeset viewer.