Toggling software characteristics in a fault tolerant and combinatorial software environment system, method and medium6634019Abstract A fault tolerant software environment, in which various program components (e.g., portions of computer programs, applications, etc) are objectized into entities represented by "codons." This allows for improper syntax to occur, enabling, for example, combinatorial operations such as genetic programming. The present invention also contemplates such features as the ability to probabilistically execute individual codons, to switch between treating information as executable code or as data (or passing over it), provides that the individual codons can be tagged so that additional information can be associated with them, and provides for tagging of the stack. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
======================================================
#include "Lamarck.h"
#define L_ErrorNegOverflow -1
#define L_ErrorPosOverflow -2
---------------------------------------------------------------------------
long vmfn_ADD(T_VMRECORD *pvm)
{
--------------------------------------------------------------------------
-
double y = a + b;
if (_finite( y))
{
pvm->vmRets[0].value = y;
pvm->vmRets[0].type = ID_DOUBLE;
return 1;
}
else /*An error has occurred*/
{
_clearfp(); /*Clear floating point register*/
if (a < 0 && b < 0) return L_ErrorNegOverflow;
if (a > 0 && b > 0) return L_ErrorPosOverflow;
}
}
==================================================
The num rets column 318 of FIG. 3 indicates the number of values that can be expected to be returned when a codon is executed. In this particular example, with the exception of the "end" codon, all of the codons will return one value. The errors column 320 indicates the number of errors that occurred due to the execution of a particular codon. Embodiments of the present invention contemplate that various different types of errors can be kept track of using column 320. In addition, embodiments of the present invention also contemplate that multiple error columns can be utilized to keep track of different types of errors separately. One example of a type of error that could be kept track of is where the proper number of arguments for a codon does not exist. Thus, where a "+" codon is encountered and only one argument is available when that codon is executed, an error may be generated (even though as indicated above, the program would continue to run, and as such might not be viewed as a true "error"). Examples of other types of errors would include division by zero, where a division operator is concerned (in this example, codon number 4). Instances column 322 indicates the number of times that a given codon has been executed. This can be kept track of from one or more perspectives. For example, the present invention can keep track of the number of times a codon is encountered for all programs running within a given environment (e.g., it would keep track of the total number of times a codon is encountered in all programs) and/or the total number of times the codon is encountered over some set time period or within certain select units (e.g., within one or more specified programs, subroutines, etc). Various other criteria for tracking the number of instances are also contemplated by embodiments of the present invention, as well. As with errors column 320, it is envisioned that multiple instance columns can also be utilized. As will be discussed further, keeping track of the number of instances allows the present invention to, e.g., determine which portions (e.g., features, subroutines, etc.) of a program are being used. This has numerous potential applications, including those relating to the rental of software (e.g., a user can be charged based upon the features that he or she actually uses). Keeping track of the instances can also be used for debugging purposes, and can be used to differentiate one initially-identical program from another based upon how each user has utilized their copy of the program. The run time total column 324 indicates the total time of execution for a codon during, e.g., the execution of a program. The next three columns indicate whether or not certain types of events (e.g., errors) should be handled for the given codon. TrapGrammar column 326 will be set to "true" or to the value of a grammar correction codon, if it is desired that grammar errors be corrected. An example of a grammar error is where a function that is expecting a numeric argument instead receives something else, such as an operation (e.g., as would be the case for the program "+cos" where the cosine expects a number rather than a "+"). TrapError column 328 relates to whether control should be transferred to a handling function on encountering an error. TrapSuccess column 330 relates to whether control should be transferred to a handling function on encountering a success, which can be useful in the context of, e.g., probabilistic execution, as will be described further below. In this particular example, all codons in that column 330 are set to "false," but if probabilistic execution were implemented with regard to a particular codon, one might set the TrapSuccess entry for that codon to "true" or to a specific handling codon, so that some context specific logic can be executed. Some additional columns (not shown) also contemplated by the present invention include those that would indicate the author/creator of a codon. For example, a program could be assigned a certain identification number, and if that program should create a codon (using, e.g., "define agent" function, discussed below), the identifying number of the program would be placed in the appropriate spot in the author/creator column. Another contemplated column involves access privileges for a codon, where, e.g., only certain programs would have access to certain codons. Thus, to be given access to a codon, a program's identification number, for example, could be placed in the appropriate location in a "privileges" column. Similarly, in multi-tasking environments, it might be useful to include a "Mutex" or mutual exclusion field indicating that a codon was in use, and/or, that is was temporarily locked. The present invention also contemplates the flexibility to allow users to define their own columns that can be associated with the codons as well. This is indicated by column 332. In general, the various columns mentioned above are exemplary in nature, and the present invention contemplates that different columns (and/or the same ones used in somewhat different functional ways) can also be used. An exemplary manner for execution of the program described above for converting Celsius to Fahrenheit will now be described and explained with regard to FIG. 4. Referring to FIG. 4, an Excel spreadsheet 402 is shown, where the number 10 was placed in the cell at the first row, fourth column. Referring to the program depicted at 404, the various steps of the program and results of each step will be explained in conjunction with master codon table 304 of FIG. 3. Referring to the program at 404, the first codon encountered during execution of the program is codon number 8. When this codon is evaluated against master codon table 304, it is determined that it represents the numeric constant "1." The result of encountering and executing a constant is merely to fetch the constant and place it on a stack in memory. Thus, the result of Step 1 is that the number 1 is placed on a stack 406, as shown. Consequently, the stack 406 shows the number of items that are on the stack after the completion of each step (note that the last element added to the stack is at the bottom). (As will be shown with regard to FIG. 5 below, embodiments of the present invention contemplate that the stack consists of a set of uniform "items" or structures which contain value, type, and other tagging information. The items are an extension of the "variant" or "union" data type, as they can encapsulate a multiplicity of fundamental and derived data types.) In Step 2 of program 404, codon number 2 is encountered which, according to the master codon table 304, represents the numeric constant 4. Having thus encountered another constants the present invention also places this number on the stack 406. Consequently, the result of Step 2 is that the numbers 1 and 4 are on the stack 406, as shown. In Step 3 of program 404, codon number 10 is encountered which, according to the master codon table 304, represents the user-defined function for obtaining the value of a cell of a Microsoft Excel spread sheet. As per this exemplary function, the specific cell location in the spreadsheet at which the value is to be obtained is designated by two arguments, where the first argument represents a row number and the second represents a column number (note that the Num Args column 314 of master codon table 304 contains a "2" in the "xlCell.R.Value" entry). As embodiments of the present invention contemplate that operations, functions, etc. receive their requested arguments from the stack 406 (either, e.g., directly via a stack pointer, or a by calling a stack pop function, or indirectly via an argument buffer which would contain copies of the pertinent stack items) the Excel function takes the number 4 off of stack 406 as its second argument, and the number 1 off of stack 406 as its first argument. Thus, the value of the cell located at column 4, row 1 is obtained. In this example, the value at that location is the numeric constant 10. Consequently, the result at Step 3 is that the 4 and 1 will have been removed off the stack and replaced by the numeric constant "10." In Steps 4 and 5 of program 404, codons 5 and 6, respectively, represent the numeric constants 9 and 5, respectively, and each of these constants is placed upon the stack 406, as shown. In Step 6, codon number 4 is encountered, which represents a "divide" operation. The divide operation takes two arguments and divides the first by the second. Thus the top and penultimate items on the stack 406 (in this example, the numeric constants "5" and "9") are divided to yield the numeric value "1.8". Consequently, this result is then placed on the stack 406, as shown in Step 6. In Step 7, codon number 3 is encountered, which represents a "multiply" operation. In this example, this operation causes the top and penultimate items on the stack 406 (in this case, 1.8 and 10, respectively) to be multiplied together, resulting in the number 18. Thus, the result of Step 7 is to place "18" on the stack 406. In Step 8, codon number 7 is encountered, which represents the numeric constant "32". Consequently, the result of Step 8 is that "32" is placed on the stack 406, as shown. In Step 9, codon number 1 is encountered, which represents an "add" operation. Consequently, the top and penultimate items on the stack will be added together, resulting in the numeric constant "50," as shown. While the use of stack 406 and its utilization as described above is as contemplated by embodiments of the present invention, it should be understood that the present invention also contemplates other methodologies for executing programs and implementing the virtual machine contemplated herein. This includes, for example, concepts using conventional and pre-fixed notation rather than post-fixed notation. Embodiments of the present invention contemplate that the items that are placed on the stack 406 (or on similar structures) can be "tagged" such that they are associated with various additional items of information. Embodiments of the present invention envisioning the tagging of items on stack 406 are described with regard to FIG. 5. Referring now to FIG. 5, an exemplary stack tag table 502 is shown containing information relating to the stack 406 and values thereon (particularly the value at the top of the stack) at each step in the program. A stack count column 504 indicates, for each step, the number of items on the stack after the completion of each step. Thus, in Step 1, it is shown that there was one item on stack 406, in Step 2 there were two, in Step 3 there was one, etc. A stack value column 506 indicates the value of the top item on the stack 406 at each given step (which, as generally envisioned herein, is considered to be the "value" of the stack for a given step). For example, at Step 5, the stack value column contains a "5" (indicating that the value of the stack 406 at that step was "5"), while at Step 6 (after the division operation) the value of the stack 406 as shown in stack value column 506 is "1.8." The remaining columns in stack tag table 502, discussed below, relate in this example to the value of the stack (i.e., the top-most value) for each given step. The "stack type" column 508 indicates the type of value (e.g., the fundamental storage class, integer, double, etc., or object type, or codon type for a derived or pointed to data type) for each step. Thus, the value of the stack at Step 5 (i.e., the number "5") is shown to be of type "integer," whereas the value at Step 6 (i.e., the number "1.8") is of type "long." The "origin" column 510 indicates the step in the program at which each item on the stack was generated. The "origin codon label" column 512 indicates the codon that generated the value. For example, at Step 3, the number "10" is shown to have been generated by the "xlCell.R.Value" function, while in Step 8, the number "32" is shown to have been generated simply by the encounter of the numeric constant 32. The dependency column 514 indicates the earliest position in the program that each value on the stack relied upon for its calculation. In some cases, (for example, looping logic) it may be useful to also record the step. For example, in Step 2, the value of stack 406 (which is "4") came from the numeric constant 4 encountered at Step 2 of the program at 404 of FIG. 4. Thus, in Step 2, the dependency column 514 has a number 2 (indicating that Step 2 is the earliest position in the program 404 that the value of the stack 406 at that step depends upon for its existence). In Step 6, the value "1.8" came from the division of 9 by the number 5. Thus, since the earliest of the numbers relied on for this calculation was the number 9 of Step 4, a "4" is in the "dependency" column 514 for step 6. In Step 9, the entry in the "dependency" column 514 is a "1," indicating that the first step that was relied upon to produce the number "50" was Step 1. The "dependency codon label" column 516 indicates the value of the stack at the step indicated by the corresponding dependency column 514. It should be understood that the items depicted in the stack tag table 502 are by way of example. Other types of information relating to the stack 406 can also be associated with the various values thereon, and added as columns in stack tag table 502. In addition, other types of structures for recording and retrieving information relating to values on the stack 502 (or similar items) are also contemplated by embodiments of the present invention. Embodiments of the present invention envision that tagging items on the stack is useful to help determine where a particular item came from, the functional unit it is part of, and the instructions and data on which it depends. This information can be used to break a program into functional units for breeding, and for allocation among processors or computers, e.g. run-time parallelization. Potentially, by tracking a particular item's origin, the process of calculation can be reversed. For example, in Step 5 above, the three items on the stack are the values "10," "9," and "5." Thus, if someone were interested in where the number "10" came from, they could find the entry in the "stack value" column 506 containing the value "10." In this case, it can be seen that the value was placed upon the stack at Step 3. Then, looking at, e.g., the "origin codon" column associated with Step 3, one would see that the "xlCell.R.Value" was executed. In addition, one could also see from the "dependency" column 514 at Step 3 that the earliest item relied upon for the value was at Step 1 of the program. When looping and branching logic is involved additional information may be needed to properly tag data such as the step at which an item was placed on the stack, as well as the step at which its dependent items were placed on the stack. In addition to the various items of information in the master codon table 304 of FIG. 3 that relate to the number of errors and instances for, e.g., a given type of codon (such as a "+" operation) that occur over the course of running, e.g., one or more programs, the present invention also contemplates that activities and characteristics of each individual codon in a program can be tracked and recorded. Thus, for example, if a program contained twelve different "+" operations, the activities and characteristics of each of these individual "+" operations could be individually tracked and recorded. This would be in addition to keeping a total of the activities of all "+" operations within, e.g., a given program, groups of programs, time frame, etc., as generally anticipated would be the case with regard to information stored in the instances column 322 of the master codon table 304, as contemplated by embodiments of the present invention. As an exemplary analogy, a conventional program can be considered as a tape of numbers or instructions, while the multi-property instructions contemplated herein would be a fat tape in which the normal tape had been expanded with additional fields for read/writeable information. The program is then streamed and a fat reader head would read the instruction and the properties associated with it each time the program was executed. In addition to simply reading the tape, the fields could be modified as the program was executed. FIG. 6 depicts one manner contemplated by embodiments of the present invention for implementing the tracking and recording of activities and characteristics of individual codons as mentioned above. Referring now to FIG. 6, a multi-property codon information table 602 is shown for keeping track of the various items of information relating to the individual codons of a particular functional entity (e.g., programs, subroutines, etc.) This is evidenced by the existence of a codon number entry 604, containing the codon numbers for each instruction of the functional entity. In the example of FIG. 6, that entity is the exemplary temperature conversion program mentioned previously. The exemplary information that embodiments of the present invention envision can be tracked and recorded in the multi-property codon information table 602 for each codon in, e.g., a program, is now described. An "activity level" entry 606 indicates whether a codon is on or off. A value of 1 indicates "on" and a value of 0 indicates "off." Intermediate values suggest fuzzy or "probabilistic" activation. Specifically, given an activity level, the present invention has the capability of determining whether or not (based upon any number of chosen factors) to execute a particular codon. The activity level number, itself, in the multi-property codon information table 602, is envisioned to be indicative of the level at which the codon would execute (e.g., an activity level of 0.33 might mean that the codon would have a 1 in 3 chance of executing when encountered). It should be realized that the fault-tolerant aspects of the present invention facilitate implementation of this feature, since the act of suppressing the execution of a part of a program may lead to incorrect syntax. The fault tolerant aspect, and the potential encapsulation of all language entities as codons, enables any codon to be remapped to another. To facilitate this feature, a "substitution codon" entry 608 allows one codon to be substituted for another one. Thus, for example, it may be useful in certain modeling situations to change a "+" operation in a given program to a "*" operation. Embodiments of the present invention envision that this could be accomplished with regard to the exemplary temperature conversion program by placing the number "3" at the "Instruction 9" column in the substitute codon entry 608 of multi-property codon information table 602. This is because codon number 3 represents the "*" operation, as per master codon table 304. Thus, this would cause the initial "+" operation of Instruction 9 (note the "1" in codon number entry 604 at Instruction 9, which represents the "+" sign) to be executed as a "*" operation. The present invention also envisions the implementation of global-type changes, where, e.g., all "+" operations in a program are changed to "*" operations. Of course, this feature may cause circularity (e.g., A.fwdarw.B, B.fwdarw.C, C.fwdarw.A). To prevent this from occurring, embodiments of the present invention contemplate checking whether any codons being redirected appear twice. If any do, the redirection is stopped at that point. The instances entry 610 indicates the number of times that a codon has been encountered during, e.g., a single execution of the program. Thus, embodiments of the present invention contemplate that, e.g., the number of times a codon has been encountered in a most recent execution of a program or subroutine (potentially at, e.g., a particular virtual machine level, discussed below) would be recorded by this instances entry 610. The total instances entry 612, on the other hand, is envisioned to keep track of the total number of times that a codon has been encountered during, e.g., the course of multiple executions and/or virtual machine levels of the program. It should be understood that the distinction generally mentioned above as to when an encounter of a codon should be registered in the instances entry 610 and/or total instances entry 612 is by way of example, and that any number or criteria can be used. Also, it is envisioned that additional types of "instances" entries can be added to multi-property codon information table 602 (or the "fat tape") that can be used for recording when certain codons are encountered under any number of different types of circumstances. An example describing a use of recording the "instances" and "total instances" within the multi-property codon information table 602, generally, and as compared with a contemplated use of the instances recorded in the master codon table 304 of FIG. 3 is given as follows. In this example, it is assumed that the master codon table 304 also has two instance-related columns, one called "instances" and the other "total instances." The former is envisioned to record all encounters with a particular type of codon in the course of a single execution of a program, while the latter records all encounters with the type of codon over multiple executions of one or more programs. In the example below, assume the existence of two programs: a) "GreetingsWorld" is comprised of six codons. The first, third, and fifth are the text codons "Hello," "World," "Hello" respectively, and the second, fourth, and sixth is an operator that takes one text codon argument, "PrintText." b) "Greetings" is composed of two codons. The first is a text codon, "Hello", and the second is the print operator above, "PrintText." The following sequence of the programs mentioned above is executed: GreetingsWorld, Greetings, Greetings, and Greetings. The table below shows how the properties in the multi-property codon information table 602 for "Hello" in Greetings and the master codon 304 table for "Hello" would change with respect to the "instances" entries and "total instances entries":
"Hello" in
"Hello" in Greetings Master Codon Table
Program Total Total
Executed: Instances Instances Instances Instances
1 GreetingsWorld 0 0 2 2
2 Greetings 1 1 1 3
3 Greetings 1 2 1 4
4 Greetings 1 3 1 5
After the execution of GreetingsWorld, there was no change in the instances entry of the multi-property codon information table for "Hello" in Greetings because the program Greetings was not executed. But the master codon table for the codon "Hello" recorded two instances of "Hello." (Remember, GreetingsWorld's programs is "Hello", PrintText, "World," PrintText, "Hello," PrintText). Still with regard to FIG. 6, the errors and total errors entries (614 and 616, respectively) keep track of errors and total errors that occur with regard to a codon, with an envisioned distinction between the usage of the errors entry 614 versus total errors entry 616 being that as described above with regard to instances. As with the errors column 320 described with regard to the master codon table 304 of FIG. 3, recording any number of different types of errors is contemplated by embodiments of the present invention. The parent agent entry 618 contemplates containing an indication of the agent from which the codon was copied. More specifically, embodiments of the present invention contemplate that parent agent entry 618 can contain the codon number of the agent from which the codon was copied. In particular, this has application in a genetic programming environment where various portions of agents are cut and spliced together to form new agents. In such environments, it may be advantageous to readily determine the agent (i.e., the parent) from which a particular codon came from in the cutting and splicing process. In this way, when a new piece of code is formed in a genetic programming environment, one can readily determine the "parents" of that piece of code (and, in particular, the parent of any given codon). In addition, items such as an author identification number or TCP/IP address can be assigned to indicate who created the program. The parent index entry 620 indicates the position within a particular parent agent from which a codon was copied (in, e.g., a genetic programming environment). Thus, for example, if codon number 8 at Instruction 1 in the multi-property codon information table 602 had been in the fourth position (i.e., the fourth codon) in the program from whence it came, then the number "4" would be put into the parent index entry in the Instruction 1 column. User tag 622 and "other user-defined fields" 624 indicate that embodiments of the present invention contemplate that various other types of entries are envisioned, and thus other types of information can be tracked and recorded. One such additional entry envisioned by the present invention relates to keeping designated instructions together in the event that they achieve (or are dose to) some pre-defined score or threshold level from a fitness function in a genetic programming environment. Thus, for example, if a piece of code comprising Instructions 3-7 is found to have scored very well, an entry in the multi-property codon information table for each of those instructions can indicate that the codon should not be separated from the preceding and/or following codon, thus making sure that those instructions are kept together as the genetic programming process precedes (e.g., keep codons 2 through 6 together). Another use would be to record the IP address of a computer on which the codon was recorded to further help identify the codon's origin. In general, the concept of the multi-property codon information table 602 essentially allows programs to, in effect, become "read/write" in nature, in that the elements of the program (i.e., the codons) can be given dynamically changeable attributes. In this way, various items of information can be associated with each codon in a program and a population of initially identical programs can be individualized. Tracking and storing information about individual codons in the manner described above has numerous advantages. One such advantage relates to debugging programs. A programming language that uses the concepts described above would effectively contain a built-in debugging mechanism, since it can inherently track where the program logic has been (e.g., which codons have been encountered), and thus which aspect of a program (e.g., which subroutines) has been entered. Use of the concepts described above also allow two initially identical programs to differ from one other as they are used by different persons (assuming, of course, that each is not used in an identical manner). Thus, each program will have its own individual footprint. Also, as mentioned above, the parent agent and parent index entries (618 and 620, respectively) allow an added advantageous level of analysis in genetic programming environments. Another advantage of implementing a multi-property codon information table 602 as discussed above relates to protecting aspects of the virtual machine environment from potentially unwanted effects of genetic programming, while at the same time facilitating a reasonable amount of flexibility for the genetic programming process. More specifically, when programs are arbitrarily spliced and recombined in a fault tolerant environment, in which data and instructions are intraconvertible, it can be difficult, if not impossible, to predict the potential outcomes. Consequently, embodiments of the present invention envision that certain sensitive aspects of the virtual environment and host computer system need to be safeguarded and/or restricted to prevent undesirable and potentially destructive effects, and that direct access to the master codon table 304 is not permitted by the code that is being bred and executed. However, the aspects of the multi-property codon information table 602 are accessible, but as indicated above, the table relates only to a particular program and not the entire environment (so a potential negative result would not be as catastrophic). Thus, certain precautions are implemented while preserving much flexibility. Of course, it should be understood that the present invention envisions any number of specific ways and degrees to implement this concept. While the particular mechanism described above for keeping track of codon information utilizes a table format, it should be understood that the present invention contemplates that any number of other different types of structures can be used. For example, in order to stream programs or transfer information from machine-to-machine, certain properties must be attached, and structures are envisioned for use to accommodate this. In addition, any number of different types of information relating to the codons (i.e., in addition to and/or less than and/or different than the entries of multi-property codon table 602 described above) is contemplated by embodiments of the present invention. As indicated above, one of the features contemplated by embodiments of the present invention is the ability to treat programs as data and vice versa. For example, when a codon number is encountered, rather than looking it up in the master codon table 304 and executing it in accordance with its meaning in that table, the present invention has the ability to instead treat the codon number simply as data (i.e., as a numerical constant). As indicated above, an advantage to being able to treat programs as data is the enhanced ability to execute the programs in a genetic programming environment. Furthermore, treating programs as data also facilitates program self-analysis, self-modification and the ability for programs to readily create other programs. An example of this latter advantage is now shown with regard to FIG. 7. The example of FIG. 7 contains the labels "Arg1" and "Arg2". These labels are "keywords" and refer to the parameter space of an agent. (A number of exemplary keyword codons contemplated by embodiments of the present invention will be discussed below in conjunction with various figures and features.) Embodiments of the present invention contemplate that all agents can use these same terms to access and modify their parameters. The maximum number of agent parameters is contemplated to be a user-configurable element of the system. As a default, the size of the parameter space is set to equal the size of the stack space. When an agent that requires n parameters is invoked, the top n items on the active virtual machine stack are copied into a set of private registers, named "Arg1", "Arg2", . . . "ArgN" within the current virtual machine record. This standardization of parameter space and nomenclature is envisioned to enhance the "evolvability" of programs by increasing the overlap of terminology and data structures between two arbitrary programs. Referring now to FIG. 7, an agent called "ProductMaker" 706 is shown. This agent requires three parameters. In effect, the agent takes the first two parameters, both codon numbers of one-parameter functions, and creates a new agent having the name of the third parameter. The resultant one-parameter agent computes the product of the two one-parameter functions evaluated at a given value. In this particular example, the two arguments passed to ProductMaker are the codon numbers of FunctionA and FunctionB. FunctionA 702 multiplies arg1 by the constant "2." Thus, as indicated in 702, the first item in FunctionA is the variable "arg1", the second item is the number "2", and the third is the multiplication sign (thus, the format used is post-fix). Though comprised of codons itself, FunctionA also exists as a codon. Here, FunctionA has been assigned the codon number of 3482. (It is envisioned that such assigned numbers can be arbitrary, or can in some way be representative of the entity that they represent, e.g., all arithmetic operators are three digit codons that begin with the number "1". Similarly, when converting programs from text to codon representations, certain words can automatically be associated with specific codon types, for instance, any word enclosed in brackets is considered a "marker" codon, described below.) Similarly, FunctionB contains the codons arg1, the number "2," and the function "POW". "POW" is an abbreviation for the 2-parameter power operation, which raises the value of its first argument (arg1) to the power of the second argument (which, here, is "2"). FunctionB is, itself, also a codon, and in this example it has been assigned the codon number of 8113. The ProductMaker program 706 in this example thus creates a new program that multiplies FunctionA with FunctionB. The ProductMaker program 706, itself requires three input arguments (which are envisioned to come from an input stack). The first two arguments, each denoted here as "AgentCodon," represent the functions to be multiplied (in this example, Function A and FunctionB). The third argument (called "TextCodon") represents the name that a user wishes to give to the new program that is going to be created. In this particular example, the new program will simply be called "NewFunction." Program stack 710 as shown in FIG. 7 represents the contents of the program stack 710 after the ProductMaker program 706 has executed all its steps just prior to the step of actual defining the contents of a stack as an agent (i.e., objectizing those contents). Those steps that obtained that result will now be described. Referring to the ProductMaker program 706, in the first step, the codon "AsData" is encountered. This codon (which can be thought of as a toggle) indicates to embodiments of the present invention that the subsequently encountered codon should be translated as data rather than executed in normal fashion. Consequently, in Step 2, rather than executing the methods associated with Arg1 (which involves retrieving the current value of an active agent's first parameter register), the codon number of "arg1" is placed on program stack 710 at position 1. As can be seen from a block designated "assigned numbers" 708, "arg1" was assigned codon number 684. In Step 3, the codon "arg1" is again encountered, this time in normal operating mode. The value of the first argument passed to the agent, in this case the codon number of FunctionA (3482), is retrieved and placed on the stack 710 in position 2. Consequently, Steps 2 and 3 illustrate the distinction between treating codons as data and executing them. In this example, when the new program that ProductMaker is creating is executed, arg1 at position 1 will be what will ultimately grab the value necessary for input to FunctionA. In Step 4, again, the "AsData" codon is encountered, thus treating the codon in step 5 (i.e., "arg1") as data. Again, rather than executing "arg1", its codon number (i.e., 684) is placed on the stack 710 at position 3. In Step 6, "arg2" is encountered, and since it is not preceded by an AsData codon, it will be translated (i.e. executed) in normal mode. The execution of "arg2" is similar to "arg1", except that the second (rather than the first) argument is passed to the ProductMaker program from the input stack. Specifically, in this case, the codon number of FunctionB (8113), is placed on the program stack 710 at position 4. At Step 7, the "AsData" codon is again encountered so that, at Step 8, the multiplication operation will be treated as data. Thus, the codon number of the multiplication operation (230), seen from the assigned numbers block 708, will be placed on the program stack 710 at position 5. (It should be understood that the present invention also contemplates the potential toggling in the opposite direction, such that data can be treated as an executable program) At this point, it can be seen that positions 1 through 5 of the data stack contain the makings of a program where FunctionA (as defined above) and FunctionB (also defined above) will both receive a value in the form of arg1, wherein the two functions are then multiplied together. In other words, the new program created by ProductMaker can be interpreted as follows: (arg1*2)*(arg1 2). Referring back to the ProductMaker function of 706, Step 9 contains "arg3," which takes the third argument passed to the ProductMaker function. Here, that third argument is the text "New Function," which was previously encapsulated and assigned the object number 8866. This number is placed on the program stack 710 at position 6. Step 10 of ProductMaker indicates the number of arguments that NewFunction expects to receive (in this case, it expects one argument). Thus, the codon representation for 1 (i.e., codon number 809 in this example, as indicated at assigned numbers block 708) is placed at position 7. It should, of course, be understood that the number representing the number of arguments could itself have been yet another argument (e.g., arg4) in the event that ProductMaker allowed for FunctionA or FunctionB to have more than one input argument. In step 11, a "DefineAgent" codon is encountered (which in embodiments of the present invention is envisioned to have the effect of "encapsulating" the contents of the program stack 710) and assigns a new codon number (not shown) to represent the newly created agent in the master codon table 304 of FIG. 3. The present invention contemplates that there are any number of ways to actually call functions such as the ProductMaker one described. One exemplary syntactical form for doing this is as follows: {[FunctionA FunctionB] "New Function" ProductMaker}. In this example, placing FunctionA and FunctionB within the brackets causes them to be treated as data (i.e., causes their codon representation to be treated as data) which in the example above, enabled the codon number for FunctionA and FunctionB to be placed upon program stack 710. Other syntactical forms contemplated by embodiments of the present invention include the following: Asdata FunctionA Asdata FunctionB ProductMaker 81133482 ProductMaker 81133482 #ProductMaker transform #FunctionA # FunctionB ProductMaker [FunctionA FunctionB] ProductMaker "FunctionA" LabelToCodon "FunctionB" LabelToCodon ProductMaker "FunctionA FunctionB" TextToCodons ProductMaker The present invention envisions that agents also can utilize a codon named "pop", which returns the top item from the calling (or parent) agent's input stack. This allows an agent to access more data than it was originally provided and to utilize an indefinite number of arguments. Such functionality is useful for implementing functions such as C's printf( ). The ability to treat programs as data and vice versa allows the present invention the ability to perform many different types of tests and data manipulations not possible using conventional methodologies. Embodiments of the present invention envision the inclusion of a "transform" codon that takes a given number and, if a corresponding codon exists, carries out the procedures associated with that codon (i.e., it executes the operation of the codon associated with that number). The "transform" operator is metaphorical to invoking a function through a pointer. The C/C++ language provides this facility, but not in a fault tolerant fashion; the pointer may refer to an address that does not contain a valid function. To provide pointer safety, a list of all function addresses must be available at run-time (but this is currently not a provision of C/C++). However, the "transform" operator of the present invention is "safe" or fault tolerant, since all prospective transform operations can be checked against the master codon table for validity. Moreover the fault tolerance is such that, in a preferred embodiment, any and all mathematical functions in the environment can be performed on codon numbers and the result transformed into an operation without risk of failure. Additionally the current environment may be extensible at run-time, allowing new instructions to be added. Other key codons similar to "transform" which provide conversion and execution of data and are contemplated by embodiments of the present invention include: Stack.Evaluate--interprets the numbers on the stack where possible as codons, loads them into the virtual machine program's buffer, and executes said program as a sub-agent. Mem.Evaluate--given a memory address, reads/casts the memory where possible as codons, loads them into the virtual machine program's buffer, and executes said program as a sub-agent. LabelToCodon--Returns the codon number of a given label. CodonToLabel--Returns the label of a given codon. LabelsToCodons--Returns the codon numbers given a piece of text (in effect makes the language parser available for use in the language itself.) CodonsToLabels--Returns the text representation of a list of codons. DataToGenome--Interprets the numbers on the stack as codons and inserts them into the current agent thereby modifying the current program (not executed as a sub-agent). Agent: "F-name"--Any label in this form is interpreted as an agent program stored in a text file. (Of course binary representation could also be introduced.) CreateFileAgent--Takes a list of codons and a file name, and creates a file containing a program. FileNameEvaluate--Given a file name and a flag, interprets the file as binary or text where possible as codons (which are long integer numbers), loads them into the virtual machine program's buffer, and executes said program as a sub-agent. The present invention extends the space of programs that can be evolved by the Genetic Programming process. Conventional environments require that all programs included in a Genetic Programming population be grammatically correct. In effect, this is akin to knowing, in form, what each program is going to do in advance of being run. With the introduction into the environment of codons such as "transform" which convert data to instructions, and generally with the utilization of functions which can, for example, take an indeterminate number of arguments (discussed below) as well as "junk" instructions, the invention facilitates the execution of programs whose output cannot be known in advance. Such ungrammatical, indeterminate programs can be included in the genetic programming process when run on the present invention, thus broadening the space of potential solutions. A simple example of the genetic programming process is now described with regard to FIG. 8. Referring to FIG. 8, two starting programs, one termed a "mother" program 802, and the other a "father" program 806, are shown. Each of these programs has 10 codons associated with them. In this example, during the genetic programming process, a piece is taken from the mother program 802 in the form of piece 804. Similarly, a piece is also taken from father program 806 in the form of piece 808. These two pieces (i.e., constructs, where the term simply refers to one or more codons), 804 and 808, are then spliced together to form a child piece 810. This child piece can then be tested in accordance with a fitness function as per the general principles of genetic programming, or for any other purpose. Although the example manipulates programs in their codon form, as a result of the intraconvertiblity of text and codon forms, it is also possible to perform genetic operations on the programs in their textual representation. In the latter case, the genetic operations are simply text operations (e.g. string concatenations). In either case, during the cutting and splicing phase, the representations are treated as data. After breeding, the resultant data is, if necessary, converted from text to codons and again treated as an executable program. The fault tolerant aspects of the present invention enable innumerable ways of rearranging and recombining pieces of code to create new programs. As indicated previously, it is envisioned that any element (e.g., function, operator, constant, etc.) of a program in the environment can be a codon. Due to fault tolerance, codons can be deleted, inserted, swapped, and reordered without impinging the ability to execute. Thus, the invention inherently facilitates Genetic Programming. The multi-property codon information table 602 (discussed above with regard to FIG. 6) automatically tabulates a variety of information that is useful in Genetic Programming and biological simulation. Specifically, as mentioned previously, multi-property codon information table 602 contains a parent agent entry 618 and parent index entry 620 that is available for each codon in a program. Consequently, each codon in the child program 810 is envisioned to have an associated entry indicating where it came from (i.e., indicating it's parent program). Thus, for example, the third codon (e.g., instruction) in child 810 (i.e., the codon whose numeric value is 10) would have in its parent agent entry 618 the codon number associated with the "mother" program 802, since that is where the "10" came from. Then, in parent index entry 620 of the multi-property codon information table 602, that entry for the aforementioned codon in the third position would be 3, since it came from the third position of the "mother" program 802. Thus, the number 3 would be placed in the appropriate parent agent entry for the child program 810. Similarly, for the tenth codon of child program 810 (here, with a value of 1), the parent agent entry 618 for that codon would be the codon number that represented the father program 806, while the parent index number 620 would be the number 6 (since it came from the sixth position of the "father" program 806). While the point in the mother program 802 and father program 806 at which a piece of the program is obtained may be arbitrary (e.g., determined by a random number generator), embodiments of the present invention contemplate that the length of code (i.e., number of codons) taken from the mother program 802 and father program 806 can depend upon the functionality of the code. More specifically, it may be desirable to obtain portions of code that produce some complete (or quasi-complete) functional results, or that contain codons of a specific type (e.g. codons that create computer graphics). This strategy will in many cases increase the chances that the resultant spliced code will score higher in a "fitness" test where a solution to a particular problem is sought, or generate output of interest to a designer conducting directed evolution. In conventional Genetic Programming frameworks, wherein all programs are grammatically correct, determining logical units is simply a matter of parsing. This method is not always effective in the more general and fault tolerant framework provided by the present invention. A more effective procedure for determining logical units when working with ungrammatical, indeterminate, "junky" programs, is to evaluate the program in a step-wise fashion and to note the codons contributing to the result at each step. Besides parsing and step-wise evaluation, embodiments of the present invention provide another facility for obtaining a functional portion of a parent program in a genetic programming environment. The method involves utilizing dependency information such as that found in the stack tag table of FIG. 5, and particularly the dependency column 514. Specifically, this dependency column 514 can be used to indicate how many codons of a parent program to obtain so that a functional unit is procured. As an example, and referring back to FIG. 5, it should first be observed that the program represented in this Figure by the Origin Codon column 512 is the mother program 802 of FIG. 8 (see program 404 of FIG. 4 for the codon correlation). In any event, if through the use of, e.g., a random number generator, an indication exists that the program represented at Origin Codon column 512 should be split (or copied) at the "multiply" operation at Step 7, then the present invention would note that the corresponding entry in the dependency column 514 at Step 7 is a "1." This would be an indication to grab the codons from Step 1 through 7, since they make up a functional unit (and yield a functional result). Similarly, if it is desired to make the split at the "divide" operation of Step 6, then since the dependency column contains a "4" at that step, the codons from Steps 4, 5 and 6 would be taken, and spliced with other codons to form the new child 810. This works, because the dependency column 514 indicates the earliest step from which the value of that current step depended, and thus obtaining the codons from that earliest step forward will produce a unit of codons likely to yield some kind of result. It should be understood that the scheme for determining what codons to use in a genetic algorithm environment as described above is by way of example, and that the present invention contemplates any number of other techniques for determining where in a parent program a cut (or copy) is to be made, and how many codons are to be used from each parent in creating the new child program. Another example of advantages of the fault tolerance of the present invention with relation to genetic programming is that the present invention has the ability to explore and develop solutions from a larger search space than the space permitted by conventional genetic programming environments. The exemplary code written below generates a random integer between 1 and 10 and assigns it to variable n. It then generates n random integers between 0 and 1 and sums the result. An exemplary manner for doing this using the present invention is as follows:
Do
/*generate a random integer between 1 and 10
and assign it to n*/
1 10 Randlnt n let
/*generate n random numbers between 0 and 1*/
n 0 1 RandlntNTimes
/*within the current context add any items on the stack*/
sum
Loop
This program could not be executed in conventional genetic programming environments because of the uncertainty of the numbers that should be summed. Specifically, codons such as "sum" would not be possible, since conventional environments would require, e.g., many conditional statements for taking into account the number of possible integers that may need to be summed, depending upon the number generated by the random number generator. In particular, because of the stack-based framework contemplated by embodiments of the present invention, all of the numbers on the stack (no matter how many there may be, within certain physical or architectural limits) can simply be summed. Alternatively, the present invention can also indicate that it will take exactly n numbers from the stack, indicative e.g., of the number of random numbers generated. These types of codons (termed variadic and argomatic, respectively) will be mentioned further below. Thus, the present invention allows for keyword codons such as "Sum" to be variadic (i.e., it is not known how many inputs into Sum will exist at the time of execution). As noted previously, the present invention contemplates a fault tolerant environment, where a program having incorrect syntax will be executed and not crash the system (although such a program may or may not yield a worthwhile result, or even any result at all). However, the present invention does envision instances where it would still be useful for an otherwise meaningless sequence of codons to yield at least some result. Such a situation can be envisioned in a genetic programming environment where, in the course of creating and testing pieces of code that have been spliced together, it is still useful to ensure that there is at least some type of output against which fitness can be tested. In other words, if the results of executing the program were allowed to yield no result at all, then there would (typically) be absolutely no chance at all that the program would score well on the fitness function, whereas forcing at least some result to occur would allow for at least some (albeit typically slim) chance that it may score favorably, or that it's performance can be differentiated from others in a population of programs. In view of the above, the present invention contemplates a scheme for "grammar repair," where the grammar of a program to be executed is repaired. One way that the present invention contemplates implementing this is now described with regard to FIG. 9. Referring to FIG. 9, the four-step program at 902 would, in conventional programming languages, be considered syntactically incorrect. Specifically, Step 1 is an addition operation, which expects to receive two arguments to be added together. However, in program 902, there are no such arguments available. Similarly, the cosine operation of Step 2 would expect one argument (but has none), and the multiplication operation of Step 3 would expect two arguments (and has none). Regarding the exemplary program 902 described above, embodiments of the present invention contemplate that a user can, if desired, initiate a grammar repair feature to allow the program 902 to yield some meaningful output. When this feature is implemented, then upon encountering the addition operation of Step 1, the present invention would recognize an insufficient arguments situation. Embodiments of the present invention then envision that, e.g., a grammar repair codon is used to attempt to generate meaningful arguments. A simple implementation would be to generate the arguments randomly. In the example of FIG. 9, the two numbers generated are 4 and 7, which are placed upon the stack as indicated at 904. These two numbers are then added together in accordance with the addition operation of Step 1 in program 902 (yielding the number 11), which is then placed on the stack at Step 2. Still referring to program 902, Step 2 is the cosine operation which, requiring one argument as input, receives the 11 from stack 904, and yields .9816, as shown at Step 3 of stack 904. Then, upon encountering Step 3 of the program 902, which is the multiplication operation, the present invention looks for two arguments. Finding only one (i.e., the .9816), the present invention's grammar repair generates a second argument (which in this example is the number 3) and places it on the stack at step 3 as shown. The multiplication can then commence, yielding the number 2.9448. Thus, the program 902 can then be tested for fitness using the numbers generated, as shown on stack 904. It may very well be that the results are unlikely to score well with the fitness function, but at least there will be some result to work with. Embodiments of the current invention contemplate that the specific type of grammar repair function used can differ depending upon the specific codon(s) encountered. Furthermore, it is envisioned that the grammar repair function can vary with each codon and can be set at any time. In addition to the data mode and program mode described above, the present invention also contemplates embodiments where a program can be running in a "silent mode" such that, when the silent mode is turned on, codons that would otherwise be executed are simply skipped over in the sense that no operation is performed, i.e., no result is generated, only the codon status and machine information (e.g., various counters) is updated, and there will be no return values. This feature will be further explained with regard to FIG. 10. Referring now to FIG. 10, a program 1002 is shown, wherein the first Instruction (i.e., the first codon) is "SilentModeOn" (as shown by the "label" row) indicating that the silent mode should be turned on. The next three Instructions of program 1002 (i.e., Instructions 2-4) each contain a function for obtaining the machine code representative of a particular color that can be displayed on a computer display screen (when, e.g., that machine code is stored in an appropriate color register of a computer). Because the silent mode has been turned on by virtue of Instruction 1, to Instructions 2-4 are skipped over, as described above. In Instruction 5 of program 1002, a SilentModeOff codon is encountered, thus turning the silent mode off and resuming regular program execution. In Instruction 6 of program 1002, the numeric constant "2" is encountered, which is placed on the stack. The state of the stack, after each instruction is executed, is shown at 1006 of FIG. 10. The number of items on the stack is indicated at 1008. Thus, the constant "2" is placed on the stack at Instruction 6 of 1006, and 1 item is shown to now exist on the stack (as indicated by 1008). As indicated by the "codon" representation shown at program 1002, codon number 2829 represents the numeric constant 2. Note that the stack 1006 at Instruction 5 is empty. The next codon to be encountered in program 1002 is at Instruction 7, at which resides the numeric constant 4. Thus, 4 is placed on the stack 1006, as indicated at Instruction 7 thereof, the "4" being represented by codon number 2830. At Instruction 8, the codon "RandInt" is encountered, which as contemplated by embodiments of the present invention is a function (e.g., a built-in keyword) that takes the two arguments (from the stack) and returns an integer in the range between the two arguments. Thus, in this example, "RandInt" will return the integer 2, 3 or 4. As shown at Instruction 8 of the stack 1006, in this particular example, RandInt returned a numeric constant of "3" (thus, a "3" is shown on the stack 1006 at Instruction 8). The next codon in program 1002 is "genomeItem" at Instruction 9. In this example, that represents a function that takes one argument from the stack 1006 and returns the codon number of the codon at that particular position within a program (e.g., in this case, within program 1002). Since the number 3 was placed on the stack 1006 at Instruction 8, "genomeItem" returns the codon number at the third position (i.e., the third instruction) of program 1002. That item is "White" which, as indicated by the "codon" row, is represented by codon number 869. Here, "869" is placed on the stack at Instruction 9. The next instruction of program 1002, which is Instruction 10, contains the function "Transform", which takes the data item on the top of the stack (in this case, "White," as represented by 869) and executes it. This then returns the constant 16777215 (which is the color white in the Microsoft Windows API) and places it on the stack 1006. Instructions 11 and 12 call the xlRow and xlCol function which returns to the stack the row and column respectively of the active cell of an Excel spreadsheet. Then, at Instruction 13 of program 1002, the codon "xlCell.W.InteriorColor" is encountered, which is a function that takes three values. The first value indicates a particular color while the second two indicate a particular cell in an Excel worksheet. The function thus takes the three values that are on the stack and proceeds to set the color of the cell indicated. Thus, program 1002 shows an example of the usage of the silent mode and, in addition, depicts in an exemplary manner the nature of the codon-oriented environment contemplated by embodiments of the present invention. An important feature of silent mode is that it allows logic and data to be inserted anywhere in a program without having to affect the flow of the program. Embodiments of the present invention provide the capability to search programs for any codon. Thus, branching into an otherwise "silent" section of a program can be accomplished by searching for a specific codon within the silent section. Related to silent mode, embodiments of the present invention contemplate a special type of codon called a "marker." In effect, markers are a named instance of the "nop" (no operation) instruction. Markers are envisioned for use as a reference point to tag the elements of a program for various purposes, such as branching to a particular point in the program. In addition to branching, markers can also be used for identifying target sites for genetic programming operations and for identifying code that performs a particular function or contains a data field. For example, a program can be employed to demonstrate markers to identify various attributes of a picture; these markers can be used to mutate the picture. The code fragment below shows an exemplary syntax for silent mode and marker codons. This allows the main program loop to skip over the silent section(s) and in some contexts execute it. The naming convention of markers is arbitrary; the program below uses an HTML like format.
/* Exemplary use of marker codons */
SilentModeOn
<Count> 33 </Count>
<TimeSent> 36615.60596 </TimeSent>
<Sender> "Anonymous" </Sender>
SilentModeOFF
GetCurrentSystemTime MakeConstantCodon #<TimeSent>LocateFirst 1+genomeItem set Silent mode and markers facilitate modeling DNA in which a gene is distributed around introns. As in molecular biology the presence of a codon can be used to activate a particular gene. Aspects of the virtual machine environment as contemplated by embodiments of the present invention are discussed with regard to FIG. 11. Referring now to FIG. 11, a master agent library 1104 is envisioned to contain those programs that have been previously created and are authorized for use by the current user (e.g., a program such as the one indicated by 1102). It is also envisioned that the master library can be distributed across many computers on a network. A machine-generated agent library 1106 is contemplated to contain portions of the program(s) that are spliced together in a genetic programming environment. Consequently, it is contemplated that these two libraries 1104 and 1106 receive and provide material for the genetic program process. (as well as for other traditional software purposes). Both libraries can store multi-property codon information. In addition the present invention contemplates allowing these two libraries 1104 and 1106 to exist as part of a local machine operating system, and could work with various file formats (binary, text, html, etc.) In addition, embodiments of the present invention contemplate that machine-generated agent library 1106 can be set up, for example, to set aside a particular area for storing those pieces of code whose score indicates a high level of fitness so that they will not individually be broken apart (although they may continue to be spliced together with other pieces). A master codon table 304 (of the type discussed above with regard to FIG. 3) is shown. A data table 1112 stores various run-time data and codon types such as strings, vectors, and other derived data types. Global Variables and Switches 1114 keeps track of information that is shared by all agents such as overall codon statistics, error information tables, the number of processes running, records in use, etc. Upon encountering an agent within an agent (i.e., a program within a program), embodiments of the present invention initiate a new instance of a virtual machine record to execute the agent, and thus the individual codons within the agent will be processed at that new record level. N potential levels of virtual machine are indicated at 1116, which depicts N agents (and thus N levels). Each level of the virtual machine maintains information about the current execution contents of a particular agent. Embodiments of the present invention envision providing for a plurality of status variables, including those relating to an instruction index, addresses of stacks, buffers, and programs, information about logic nesting, and virtual machine modes. Refer to the appendix for the preferred embodiment of virtual machine fields (T_VMRECORD structure.) After the initiation of a new virtual machine record, the overall record counter is incremented and execution resumes at the beginning of the new record. All records are translated using the same process. When the child process is completed the values on its stack are passed to the parent. The child process could also raise an error condition to the parent. In either case the execution pops back to the parent level and resumes where it left off. By introducing a mechanism to keep track of users and allocate a certain percentage of CPU time and/or priority, etc., the present design envisions accommodating multi-tasking in two or more agents by alternating between them. The additional data structure would track the number of processes currently running and the agent and any sub-agents which belong to each process, and keep track of the current execution position (the virtual machine state) of each process. The virtual machine records, as envisioned by embodiments of the present invention, are symmetrical/generic (e.g., identical number of variables, variable names, size of variables, etc, which are envisioned to be configurable) to enhance the evolvability of software. Arbitrary agents (created, e.g., in a genetic programming environment) are more likely to create something useful because they have a common framework due to this symmetry. Moreover, the uniformity of the state information makes it possible for agent programs to inspect the state information of their parents, thereby facilitating context sensitive behavior. For example, if a program were called without any arguments, it could perform an analysis of its parent. Embodiments of the present invention contemplate that any number of types of entities can be designated that can cause the present invention to initiate a new virtual machine level. One envisioned implementation is by designating those entities that are to initiate a new virtual machine level as an "agent" in the "type" column 310 in master codon table 304 of FIG. 3. When such an entity is encountered in the course of execution, the present invention would initiate the new level, and, e.g., the codons within the agent would then be executed. Thus, for example, it could be determined that all entities in which two or more codons (e.g., from a set of kernel vm functions (e.g., keywords) that make up the basic building blocks of a language) encapsulated together will be defined as an "agent" for the purposes of initiating a new level of virtual machine. Of course, it should be understood that the present invention contemplates any number of other ways (and for any number of other reasons) that a new level of virtual machine can be initiated. Returning to FIG. 11, kernel vm functions 1120 are envisioned to contain certain functions that are contemplated to be part of the core functionality of the language used in the environment. Some examples of such functions as contemplated by embodiments of the present invention were described with regard to FIG. 10, and include RandInt, genomeitem, etc (and more will be described further below). In addition, it is also contemplated that the user can create his own functions, as indicated by block 1122. In general, embodiments of the present invention contemplate that any number of different types of general language structures could be used (e.g., C-like languages) in implementing the functionality of the virtual machine environment discussed herein. Thus, for example, a known computer language could be modified to include various kernel functions contemplated herein. Exemplary components of a computer processing system used as part of the present invention, and/or used in environments or in conjunction therewith are shown with regard to FIG. 12. Referring now to FIG. 12, a virtual machine environment (or portion thereof) 1208 having at least some of the various aspects, functionality and components described herein is shown to reside in a memory/storage device 1206. It is also envisioned that these aspects, etc. can be stored as part of virtual machine environment 1208 and/or as some other portion of memory/storage device 1206 and/or can originate from communications I/O 1212 (mentioned below). This means, for example, that portions of the virtual environment can be distributed among various hardware and/or software entities, and can even be distributed among various different computers linked together in a network such as the Internet and/or an intranet/LAN. Embodiments of the present invention contemplate that the memory/storage device 1206, itself, could be any number of different types of computer-readable mediums for storing information, including RAM memory, magnetic, electronic, atomic or optical (including holographic) storage, some combination thereof, etc. Memory/storage 1206 is shown as being in communication, via communication link 1202 (e.g., a bus), with one or more processor(s) 1204. Embodiments of the present invention contemplate that the processor(s) 704 can be those typically found in the types of computers mentioned below, or they can be any number of other types of processor(s). In addition, the present invention contemplates the use of processors running in parallel so that, for example, multiple portions of aspects of the virtual machine environment can simultaneously operate (e.g., in a genetic algorithm environment, various portions of code can be split apart (or copied), spliced and tested simultaneously). This could also facilitate, e.g., simulations where two opponents are playing a game against each other (with the results of the simulation being analyzed). Referring still to FIG. 12, a display device and user interface 1210 (e.g., a mouse, keyboard, and/or modem) is shown. Communications Is/O 1212 is envisioned to communicate with various communications networks such as local area networks, the Internet, etc. Here, Communications Is/O 1212 is shown to be in communication with processor(s) 1204 and memory/storage 1206. The present invention further contemplates that communications Is/O 1212 can serve to receive various transmission schemes such as those relating to telecommunications, cable or other transmission mechanisms, and that at least some of the aspects of virtual machine environment 1208 can, in whole or part, be a transmission. Thus, for example, at least some aspects of virtual machine environment 1208 that might otherwise originate from memory/storage 1206 could instead originate from communications Is/O 1212 (e.g., the medium from which aspects of the virtual machine environment 1208 originate can be a transmission). It should be understood that the configuration of the various aspects of the present invention depicted by FIG. 12 is by way of example, and that the present invention contemplates any number of different configurations and/or different components. With regard to the various specific processors 1204 contemplated for use with the present invention as depicted by FIG. 12, one exemplary embodiment includes the use of any of the Pentium line of processors from Intel Corporation of Santa Clara, Calif., and/or a Motorola 68000 series processor such as the 68040 processor from Motorola of Schaumberg, Ill. Exemplary operating systems include Microsoft NT from Microsoft Corporation, as well as any of the various varieties of Unix or Linux. It is also possible to extend the functions of the virtual machine so that it operates as an operating system. Of course, it should be understood that any number of different types and combinations of current or future processors and/or operating systems could also be used. In view of the nature of the present invention as indicated above, operating systems that facilitate parallel-processor and/or multi-processing environments are contemplated. A method of operation as contemplated by embodiments of the present invention is now set forth with regard to FIGS. 13-16. In particular, these figures depict an exemplary method by which the present invention processes codons. Referring first to FIG. 13, the first step is to obtain an item to be processed, as indicated by Block 1302. Thus, in the course of executing, e.g., a program, this is where an individual item is received for processing. The next step is to determine whether the item has been registered in the master codon table, as indicated by a decision Block 1304. Thus, for example, the present invention determines whether the item encountered exists in a master codon table such as the one described in FIG. 3. If it does not exist, then various records will be updated, and no operations will be performed, as indicated by a Block 1306. In particular, embodiments of the present invention contemplate that a codon called "undefined", which exists in the master codon table 304, exists for the purpose of recording such occurrences. In embodiments contemplated by the present invention, encountering an unregistered item could, e.g., cause the errors column 320 associated with the "undefined" codon to be incremented (although such an occurrence is not necessarily an "error," as described below). Of course, the present invention contemplates any number of ways to record such occurrences. In addition to recording the fact that an unregistered item has been encountered, embodiments of the present invention contemplate that the unregistered item can be encapsulated, thus becoming a codon. As part of this, it is envisioned that an entry in the master codon table 304 of FIG. 3 would be created for the unidentified item (i.e., the item would become registered). One way of defining the "type" (for inclusion in the type column 310 of FIG. 3) is that if the unregistered item were textual in nature (or a combination of text and numbers), the codon type is set to "variable" (i.e., it is assumed that the item was a variable name created by the user), whereas if the item were numeric, the type is set to "constant." Of course, the present invention envisions that any number of different criteria could be used for automatically assigning the "type" column 310 of FIG. 3, and that various other types in addition to those specifically mentioned herein are also contemplated (e.g. any text beginning with "var" could be a variable). In addition, it is also envisioned that a user can manually enter or declare the "type" of codon for a particular item. Of course, the present invention also envisions that other actions can be taken when encountering unidentified items (e.g., under certain circumstances, they can simply be ignored). In any event, the next step after encountering an unregistered item (and potentially processing it as described above) is to proceed to stage 2 at FIG. 16 (i.e., between Block 1602 and 1604). In general, as discussed above, a codon can represent any number of objects, including kernel functions, operators, etc., and also groups thereof (e.g., agents) which can be, and/or be a part of, an entire program. Returning back to Decision Block 1304 of FIG. 13, if the item exists in the master codon table, then the next step w | ||||||