Emacs Artificial General Intelligence Algorithmic Game Theory: Prediction Markets (po polsku) Systemy Inteligentnych Agentów
|
Jak działająPorównujemy języki na bazie OCamla: Lucid Synchrone http://www.lri.fr/~pouzet/lucid-synchrone/, Reactive ML http://rml.inria.fr/, JoCaml http://moscova.inria.fr/jocaml/, biblioteki dla OCamla Objective Caml Reactive Toolkit http://users.wpi.edu/~squirrel/ocamlrt/, moduł Event http://caml.inria.fr/pub/docs/manual-ocaml/libref/Event.html, oraz podejście obiektowe. Zbadamy też bliżej FrTime. Reactive Toolkit jest wzorowany na Yampa http://www.haskell.org/yampa/, oraz na FrTime dla PLT Scheme http://citeseer.ist.psu.edu/cooper04frtime.html. Reactive ToolkitReactive Toolkit FrCorePodstawowym typem są funkcje sygnałowe, dla danego wejścia obliczające wyjście oraz kontynuację (funkcję sygnałową w miejsce obliczanej, dla kolejnego kroku systemu). Obliczanie kontynuacji oznacza, że funkcja sygnałowa może ewoluować, posiada pamięć (stan). Z mniejszych funkcji sygnałowych składa się większe, tak że wyjścia jednych funkcji sygnałowych stają się wejściami innych. Obliczenia są synchroniczne: krok systemu to zaaplikowanie głównej funkcji sygnałowej do wejścia systemu, obliczenia “rozchodzą się top-down”. Zdarzenia (events) to wartości funkcji sygnałowych będące typu Reactive Toolkit FrPodstawowym typem są sygnały: zdarzenia (events) i zachowania (behaviors): w rzeczywistości są to funkcje sygnałowe. System rejestruje sygnały “wynikowe” programu: punkty końcowe (endpoints) i uaktualnia się przez zaaplikowanie wszystkich (?) punktów końcowych do wejścia systemu. W tym sensie jest synchroniczny. Z drugiej strony, uaktualnienie następuje na życzenie bibliotek generujących wejścia systemu (wywołujących FrTimeJest to w pełni asynchroniczna, imperatywna implementacja programowania reaktywnego. Cytując “FrTime: Functional Reactive Programming in PLT Scheme” (Gregory Cooper and Shriram Krishnamurthi): For each signal in a FrTime program, we construct a signal data structure. The
data structure contains an update procedure, which computes the signal’s value, and a
mutable field that stores the signal’s most recently computed value. Thus, there is an
implicit notion of real time, which the system exhibits directly.
A special thread called the signal manager is responsible for keeping signals current.
It maintains an explicit graph of the dependencies between signals. For example,
when we evaluate (even? seconds), the resulting behavior depends on seconds, so the
signal manager needs to recompute it whenever seconds changes.
The manager uses an asynchronous message queue to control all computation. For
example, when seconds changes, the manager sends itself an update message for each
dependent signal. When it dequeues such a message, it recomputes the corresponding
signal. This in turn may demand recomputation of yet more signals, so evaluation proceeds
recursively in a breadth-first, bottom-up manner.
Some signals require re-evaluation after intervals of time. For example, seconds
needs to update once every second. The signal manager supports this capability by
keeping a prioritized “alarm” queue, which maps signals to update times. On each iteration
of its processing loop, the manager checks whether the current time exceeds
the earliest alarm in the queue. If so, it executes the corresponding update; otherwise,
it sleeps until either the next alarm or the arrival of a message. Our asynchronous
message-passing library makes this easy by providing a receive construct with a fine
(millisecond-granularity) timeout parameter.
To rozwiązanie przypomina Adaptive Functional Programming http://citeseer.ist.psu.edu/acar01adaptive.html. Reactive MLJest systemem synchronicznym. Podstawowymi obiektami są procesy, które komunikują się ze sobą przy pomocy nazwanych sygnałów. Procesy buduje się ze zwykłych wyrażeń OCamla, złożenia sekwencyjnego procesów ( Jeśli w jednej chwili wyemitowano kilka wartości danego sygnału, to są one zwijane przez funkcję zadaną dla tego sygnału ( Lucid SynchroneJest to system synchroniczny. Podstawowymi pojęciami Lucid Synchrone są strumień i zegar. “Behaviors = Streams”Zwykłe wartości OCamla są zamieniane na strumienie stałe, funkcje liczą na strumieniach “po osiach” (pointwise). Można dostawiać wartość z przodu strumienia, opóźniając ten strumień, np. ZegaryKażde wyrażenie ma oprócz zwykłego typu typ zegarowy, mówiący jak jego części są taktowane, np. jak taktowanie wyniku funkcji zależy od taktowań argumentów funkcji. Zegar to strumień boolowski, przetaktowujący (spowalniający) jakiś inny zegar: tyknięcia zegara są w chwilach “Events = Valued Signals”Sygnały (czyli zdarzenia w terminologii Yampa), to strumienie powstałe ze strumieni taktowanych innym zegarem: sygnał jest obecny, jeśli zegar oryginalnego strumienia ma tyknięcie, i wartością sygnału jest wartość z oryginalnego strumienia. Można dopasowywać wartości obecnych sygnałów na zasadzie dopasowywania wzorca: jeśli definiujemy strumień, to trzeba podać gałąź domyślną gdy nie ma żadnego z dopasowywanych sygnałów, a jeśli definiujemy sygnał, to przy braku dopasowania nie zostanie on wyemitowany. Automaty (w szerokim sensie)Wzorowane na http://citeseer.ist.psu.edu/maraninchi98modeautomata.html. Ze stanami (trybami, modes) programu są związane równania określające wartości strumieni (lokalnych i wyjściowych strumieni automatu), taka definicja przez przypadki. Stany zmieniają się zgodnie z funkcją przejścia z wartownikami (warunkami na strumieniach, które muszą być spełnione, żeby przejść do danego stanu). Threads / EventPodejście obiektoweJoCamlSzerszy kontekst“Rachunki procesów” (process calculi) |