Reply To: M+ (Ne) Computation

[Lautrec]

If we are to develop a formal pseudocode standard for the CTA then I think we must first determine the desired level of abstraction. As @safsom pointed out on Discord earlier today,  some lines in the current pseudocode point to incredibly complex algorithms. This appears to provide an accurate high level representation of the functions but it also creates a great deal of ambiguity concerning the lower level implementation of many processes. Consider the line:
IF st-memory theObjects[i].child-objects intersect st-memory theObjects[e].child-objects do
It effectively communicates the idea of checking for the intersection of two objects but not the way that such a check would actually work.
A better example of this would be the lines:
# Next, look for more objects adjacent to that one
SCAN visualSystem for adjacent
and:
# Then look for objects far away from that one
SCAN visualSystem for distant
In this case it is unclear exactly what the 'visualSystem' is and how it determines if an object is 'adjacent' or 'distant' to the current object. As a side note, without the comments it is unclear whether or not the current object is even being used as a reference. I think that this specific piece information needs be communicated through the pseudocode and not through additional comments. Going back to the issue of abstraction, I think that both the visual system and the intersection check could be fleshed out with matrical models. The visual system could be seen as a group of vectors forming a feasibility region which parses a 3D space for objects. An object within this space would then contain a 3D vector denoting its position as well as a pointer to an additional n-dimensional vector denoting its properties. For example, the property vector could exist within 4-dimensional space where the four dimensions are 'green', 'round', 'red' and 'smooth.' Thus the properties of a smooth green ball would be denoted by the vector [1, 1, 0, 1] (its location within 3D space would be denoted by the vector [x, y, z]). This model would allow for 'adjacent' and 'distant' to be shown as the result of explicit vector addition or subtraction within a 3D space and for the intersection check to be shown as the process of comparing the property vector elements of two objects. I think there are benefits to fleshing out the pseudocode in this way, however as it becomes less abstract it also becomes more difficult for a layman to understand and relate it to their own thought process. In my opinion this is the theory's greatest strength at the moment and I don't think it would be a good idea to forsake it. That brings me back to the initial problem: determining the desired level of abstraction. In order to retain the benefits of both the high level and somewhat lower level pseudocode, I think it would be best to split the standard into two branches, each with a level of abstraction which accommodates their respective strengths. I intend to write some code in order to simulate the interaction between J- and J+ during the process of articulation, when I'm finished that I think I will have a better idea of the way these two branches could be formatted.
Now to restate my previous comment, I think that the pseudocode should get rid of the current mix of camelCase and kebab-case in favor of snake_case. I personally find snake_case easier to read (not to mention more aesthetic) than camelCase. As for kebab-case, it just isn't allowed by most compilers that I've worked with. In most cases the statement 'x-y' is interpreted as a difference between two distinct variables and not a single variable name. While pseudocode is not directly subject to compiler limitations, I think it would be a good idea to align the two in order to provide a smoother transition. If that is to be done, kebab-case cannot be used.
Considering everything I've said so far, here is how I would rewrite the M+ pseudocode (without any lower level implementations):
FUNCTION mplus
   # Load the necessary systems
   IMPORT P_System # What is this?
   SIDELOAD Visual_System # Is there something significant about SIDELOAD?
   # Get the objects from the visual system after pre-processing
   short_term_memory.objects = GET Visual_System.preprocessed
   # Loop through environment objects which have been perceived by the visual system
   FOR i to lenght of short_term_memory.objects DO:
      # Check if this object is a duplicate of another object in short term memory.
      # This could be some sort of query to J- in order to determine if two objects are
      # similar enough to be considered duplicates.
      IF number of short_term_memory.objects[i] in short_term_memory.objects > 1 DO:
         # There is no need to add the object to short term memory here,
         # if the object is being processed in this way then I imagine it
         # is already being held in short term memory.
         # Look for objects adjacent to the current object.
         SCAN Visual_System for objects adjacent to short_term_memory.objects[i]
      ELSE DO:
         # Ignoring the object seemed redundant since the IF statement was already doing that,
         # so I removed it.
         # Look for objects distant to the current object.
         SCAN Visual_System for objects distant to short_term_memory.objects[i]
   # I removed 'END IF' and 'END FOR' because the indentation alone should be enough
   # to communicate when these blocks begin and end.
   # Begin associative operation.
   FOR i to length of short_term_memory.objects DO:
      FOR e to length of short_term_memory.objects DO:
         # Make sure an object isn't checked against itself.
         IF short_term_memory.objects[i] == short_term_memory.objects[e] DO:
            skip/continue
         # Check to see if the object's children intersect with another object's children.
         IF short_term_memory.objects[i] intersects short_term_memory.objects[e] DO:
         # Add the intersection to short term memory and remove parent-objects
         APPEND intersect to short_term_memory.objects
         REMOVE short_term_memory.objects[i]
         REMOVE short_term_memory.objects[e]