Sunday, March 30, 2008

Data samples to infer high level abstraction logic ?

Doc Mud, that is a great reader of intelligence design patterns (neural networks, expert systems... this, that...) asked me for some data samples to test one of his ideas. My first answer was: as we have now the first level of hardware abstraction, let's use the written part of system to get data, using the dummy devices added in the "lab" subpackage. Well, I tried and I found a reason to smile. Nature, physic, has its logic, it is like if it has a rule to produce numbers according to hidden perfect rules, able to take into consideration all the aspects. In order to have the system producing data samples that are valid for any game (DocMud one is this today) the data must have a rule behind (dummy devices should contain this logic), just like nature likes to do. Now, or I try to calculate some numbers using a principle every time, simple one, to give data to DocMud (for example some numbers that are coordinates belonging to a geometric place) or I can put a number generator inside the system, that allow to generate numbers every time, different numbers, but always having a sense behind, changing the rule. The sense is the rule (all numbers are coordinates in a bidimensional space for example). In this way it could be possible to use the system to read data generated by the dummy devices. Dummy devices will have to generate numbers with a rule (the coordinates) defined by a virtual space, that has constraints and principles like physic has in the real world. Of course in this virtual space abstractor, rules will be very simple and possible to be changed. This could be a part of the laboratory.

Example: with the virtual space simulation it should be possible to define a cube, or a face of a cube, and ask for some coordinates that fit the rule to belong from the cube surface, or from one cube surface, or... or...

This could complete the lab environment.

Doc Mud, your opinion please :)

Monday, March 24, 2008

Boxing infos and what will be "swarm-ed"

Propostions and review:

what about if the unit of the swarm is a behaviour of the system at a "t" instant ? What is a system behaviour ? A system behaviour is the collections of all the input and output performed by the system at that "t" time. Swarming should help in deciding what behaviours can be associated togheter to bring system to success. What is system success ? System success is bigger when the system is closer to the fullfillment of its needs. How could we define needs ? They are just simple master-rules or "perfect pre built" behavioural "trends" for the system itself. Now for the code is time to go versus data boxing, to bring to the upper logic subsystem the information to compute in a non linear way.

Saturday, March 15, 2008

Info unit flattening eterogeneity and incapsulated specificity ?

Is it a good idea to flat the complexity of different sources (device aliasese and device alias ports) generated info units, to the common paradigm of a single representation model ? Some info unit could hide incapsulated complexity:

a camera sensor could produce numbers, as pixels, or the whole image could be an info unit. In this case the info unit could be for example the context, the meaning of the whole image, and pixels as info units (1 pxel as 1 inof unit) could be useless. This is what I mean when I use the term of "incapsulated complexity".

New implementation diagrams

Jconsole view of the jmx implementation

Activity digramClass diagram

Collaboration diagram

Component diagram

Friday, March 14, 2008

Recap and status update

Up to now a small result is the comprehension of the path followed to performe the first analysis part: it is small income but interesting.

First: define the distance between reality and the intelligence that have to understand reality

Second: provide abstraction for the level of complexity the system will digest

Third: design the "gnoseologia", whose translation in English I don't know, I'm sorry

Fourth: define subsystems, the low level layers abstracting the world or delivering infos to the intelligence upper-subsystem is essential and must be suitable for the target of the project in terms of functionalities and non functional features.

Note: system design try normalize data received by hardware abstracted, acting also like a normalized message router. This because common units can be manipulated when they are all flatted down to the same type of object (for the code, it will be the same interface).

Status of coding: as suggested by doc mud, the two observer/observable patterns have been replaced by a jmx implementation. Parts missing are:

From the virtual device alias ports, data must be rendered as generalized abstracted information units.

The intelligent agent, that will act like the class provided for this pourpose in order to have a sample:

Sunday, March 02, 2008

LDAP as a jndi provider: this allow an easy view and management of configuration , in a centralized way. Easy to view, easy to understand

I'm going to post now two views of the jndi repository tree, keeping the software identities being part of the system hardware abstraction layer. Code on the google site is now mature up to this.

UML diagram of the hardware abstraction layer, up to now and nightly built

Uml for the hal subsystem