Information Technology Reference
In-Depth Information
to decompose it further into constituent sub-issues, which are then also entered into
the pool. The “system software” (henceforth: “system”) keeps track of which issues
are parts of which larger ones; i.e., the system knows the
hierarchy
of the problem
decomposition.
As soon as a prover-codelet feels that the solution of the issue that the codelet was
working on is available, it informs the system of this fact. The system informs the
supervisor codelet (who had inserted that issue into the pool), and the latter acts as an
interpreter of the solution. If the solution is validated by the interpreter-codelet, the
system is informed, so that other codelets do not attempt to assign to themselves the
solution of the same issue, which appears as “solved” in the pool. The system is also
informed when the interpreter-codelet finds that all the sub-issues of the undertaken
issue have been solved. Thus, each codelet acts as both a prover (for the single issue
that the codelet selected from the pool), and an interpreter (of all the sub-issues that
the codelet entered into the pool, after decomposing the selected issue).
In addition to parts of a proof (sub-proofs), codelets may make various other con-
tributions, such as incomplete or even false proofs, ideas, comments, suggestions,
opinions and methodology transfer rooted in past experience and expertise. These
contributions are also entered into the pool, each distinguished by its type, and are
conceived as directed toward the solution of a stated problem. Hence, the contribu-
tions are independent, goal-directed processes that evolve over the Web space and
time and accumulate as building blocks or modules of a generated Web proof-event.
Particular contributions may turn out to be blind, i.e. to lead in due time to a
recognizable deadlock situation. This may entail a change of approach towards the
problem, change of methodology applied, etc.; that is, it may give rise to a new con-
tribution and the abandonment of the unfruitful undertaking. After all, as explained
in the introductory sections, some codelets might act destructively, invalidating par-
ticular sub-proofs and contributions (e.g., when they find an error in a sub-proof, or
that an idea is unfruitful, etc.). However, such destructions are local, whereas overall
the system proceeds to a coherent solution, if one can be found.
In Web-based proof events codelets have certain specific features:
1. Each codelet, acting as a prover, knows neither who its supervising interpreter-
codelet is, nor its “peer” codelets who might be working on other sub-issues of
the same problem. However, when that prover-codelet becomes a supervising
interpreter-codelet (due to having decomposed the issue and entered its parts into
the pool), then it can keep track of which codelets work on which sub-issues.
This information is made available to the supervising interpreter-codelet by the
system.
2. When agents see that an issue is marked as “being worked on” (or “taken” by a
codelet), they are not prevented from taking it as well, forming a new codelet.
This is because some codelets may feel they can give a neat solution that might
be missed by other codelets. If, eventually, two or more solutions arise for a given
issue, it is up to the supervising interpreter-codelet to choose one and inform the
system, which incorporates it into the overall solution.
Search WWH ::
Custom Search