Thursday, December 17, 2009

What if information (CIU) were measurable and numerically comparable ? Composable information units' chains can aggregate in one big chain of chains ?

When I think to a composable information unit chain, I see that one of the information unit in this chain could be an (x, y, z) position. This is an information made of 3 numbers. if two info units should be compared, this comparison would be numeric, to obtain the closest point, or the fastest. As echoes coming from virtualized sensors and actuators' invocation feedbacks are almost always numeric, so I can try to generalize and say that:

information units could be numerically comparable

here we are, we have now changed the original concept of composable information unit, onto composable comparable information unit

This should allow easier debugging of the units comparison actions' results.

Moreover, there could exist chains of composable information units chains. This would imply that system micro experiences, (micro means for me short in time), could aggregate spontaneously (spontaneously ? Wow..) in more structured and system relevant "experiences".


Chains of composable informaton units chains: spontaneous aggregation of short in time system experiences.


Question: should all composable information unit chains be part of one big overall chain ? Links between chains (and chains of chains) would be like synapsis ?

Tuesday, October 13, 2009

Social artificial intelligence

Answer me, you, reader: is social intelligence a design pattern for artificial intelligence ? It is a simple thinking this one coming from me but, looking at human society, it seems a spontaneous association to use rules automatically establised between humans, the simplest among them, to rule animed pieces of abstracted information. it seems sometimes that given a model, to obtain more from that model, you have to put in the model more complexity, or make the model capable of more complexity. I 've been speaking for a while about active pieces of information, "behaving" like bees of a beehive, linking each others to build structured "experiences" as a part of their artificial life, to make a knowledge base. The rules that rule these infomation-bees are the basic rules of a society of individuals. Competition, physiological needs, natural selection, mutations, adherence to enviroment' changing, are the drivers to move a society into non a static group. It makes me smile, that is generally good as a consequence, but it is like to steal honey from the beehive, if we steal the decisions taken by the swarm of composable information units, while this swarm does its best to survive in a virtualized world made by a virtual machine, acting as an hardware abstraction layer to sensors and actuators.

Monday, October 05, 2009

The behavioural engine pattern

I'd like to outline that I consider the approach of developing a behavioural engine as an intra application integration pattern:

1 to encapsulate the part of the application in charge of defining what the application itself should do in a defined, restricted, non entire application pervasive scope of objects

2 to create as a conseguence of point 1, an interface between the behavioural engine and the auxiliary objects using or being used by the behavioural engine itself. In the economy of the application, these classes not being part of the engine can be grouped up in a so called "shell"

Example of this is Linux: a kernel and a shell to allow the user to invoke kernel functionalities via pre defined paths.

Sunday, August 30, 2009

New approach needed: a structured data bag is needed to keep information: compose-able information units can't be that flat as expected

CIU need to carry the piece of info saying "I was generated because of a sensor reading operation" or "I was generated because of an invokation of an actuator, done with these values and whose result was". It is like driving a stepper motor: you have to read the feedback to understand if the pulse moved something, otherwise information could be useless and corrupt the knowledge base introducing false results.

Fix to data rendering for DTOs that have "setter" methods

Solution to data rendering for DTOs that have setter methods, could be actually easy. I will try making a call to send a write action notification whenever a "setter" or a "write to actuator" method is invoked (like driveLeft(), driveRight(), brake()). This should bring getters (like getCenterOfMassPosition(), getLinearVelocity()) and setters for data operations on virtualized sensors/actuators, at the same level of abstraction. At this point, this is the situation: virtualized sensors reading actions and virtualized actuators invokation actions can be represented with the same hardware-domain-neutralized objects. All the operations can be represented. Question is: operations need not only to be represented (I just did it hopefully), but also to be performed, of course for the operations of type "write" on actutators. If a "driveLeft()" call operation has been saved as performed, the same operation should be able to be replicated again. This way we are already facing with the needs of the agnostic decision maker working with relations among compose-able information unit.

Wednesday, August 26, 2009

How to transform a java object, a dto essentially, in a "shape" of the information it keeps

An object of the type I'm taking into consideration has few things to offer to be manipulated (and this is good): it has "getters" and "setters" methods, plus values kept is class variables accessed by these. Now, what do I mean for shape of an object ? I speak with myself but it is anyway a good question. Shape is the object represantion that can be viewed by an agent that must be able to do operations on these. I'm speaking about a composable information unit produced from a dto of data received by sensors. So, shape has not to change with time passing, and many read operations on the same object must find the same "shape". The conclusion of this analysis is that the shape of a dto is a sorted list of key-value pairs with its getters and setters methods names as key, and values retrieved by the calls to these as... values.

Example: object class "person"

key: value:
getName stefano
getAge 35

This seems to run fine until I don't get into considerations the writable methods: the setters.

Information rendering: from sensors' readings to composable information units

Code on svn repository is at a very interesting point: I need now to define how to render a DTO java object (the paylod in jmx notifications received by virtualized sensors), into a knowledge domain, how to render them into a composable information unit, removing its original nature of jmx:

package it.free.i.virtual.machine.hal.devicealias.echo;

import it.free.i.virtual.machine.hal.devicealias.command.DeviceAliasPortCommand;
import it.free.i.virtual.machine.hal.devicealias.laboratory.positioningsystem.physics.CenterOfMassPosition;
import it.free.i.virtual.machine.hal.devicealias.laboratory.positioningsystem.physics.LinearVelocity;

/**
* Positioning data DTO impl
* @author stefano
*/
public class PositionEchoImpl extends EchoImpl implements PositionEcho {

private CenterOfMassPosition centerOfMassPosition = null;
private LinearVelocity linearVelocity = null;
private DeviceAliasPortCommand deviceAliasPortCommand = null;

public PositionEchoImpl(){
super();
}

/**
* @return the centerOfMassPosition
*/
public CenterOfMassPosition getCenterOfMassPosition() {
return centerOfMassPosition;
}

/**
* @param centerOfMassPosition the centerOfMassPosition to set
*/
public void setCenterOfMassPosition(CenterOfMassPosition centerOfMassPosition) {
this.centerOfMassPosition = centerOfMassPosition;
}

/**
* @return the linearVelocity
*/
public LinearVelocity getLinearVelocity() {
return linearVelocity;
}

/**
* @param linearVelocity the linearVelocity to set
*/
public void setLinearVelocity(LinearVelocity linearVelocity) {
this.linearVelocity = linearVelocity;
}

/**
* Set the command that caused this response to be generated
* @param deviceAliasPortCommand is the source do read command
*/
public void setInitiaLDeviceAliasPortCommand(DeviceAliasPortCommand deviceAliasPortCommand) {
this.deviceAliasPortCommand = deviceAliasPortCommand;
}

/**
* Get the command that caused this response to be generated
* @return source command that caused the do read operation
*/
public DeviceAliasPortCommand getInitiaLDeviceAliasPortCommand() {
return this.deviceAliasPortCommand;
}


}
In other words: I have some setters and getters and values associated. I think that the name of the method could generally become the name of a property, whose value is obtained invoking that method. Doesn't matter the semantic of the name of the property, they just have not to collide each other or overlap (this approach satisfy this need and make it simple to see original data). Can be that every composable information unit is a bunch of key-value pairs, where the keys are the methods' names and values associated are the values obtained invoking the "keys" ? Of course a dto can have nested objects to render in a flattened representation (no nested objects please), so every dto must provide its rendered version because of the paradigm interface defining what a payload for jmx notifications is.

Monday, July 13, 2009

Where are CICs in relation to the whole system ?


This schema to explain where are the CICs in relation to where the hardware is and the domain objects associated with the system hardware's components. The CICs objects and the hardware related objects are unbounded: meaning get translated from a domain to the other via a domain neutralizer, behaving like an hardware abstraction layer.

Monday, June 22, 2009

Thoughts

A group of information (DNA can be an example ?) can be considered as an informaion context ? If information are grouped up for unit of time they were captured in, is that the time context for those information ? It is not of small importance this, has it gives a new light to next steps in theory. How do different context with different meanings interact ? Phrase semantic, a new further view on this new concept (that is composable inormation unit chains HBRWCIC, HBROCIC, HBWOCIC), could help. Every time I find a new view on the elments of the theory, It implies having more opportunities to find a better approach based on a different meaning and analogy/pattern.

Wednesday, June 17, 2009

A collection of information units makes an experience


Explaining: a composable information unit is a bunch of data received by a virtual sensor installed on the virtual simulation environment (the car with the simple shape of a box). This info is transformed into a DTO that generalize the concept of information into a "composable information unit" (CIU, CIU can be CIU obtained by a read or write operation: CIU(r), CIU(w) ), neutralizing the specificity. In a unit of time (a clock class capture them) several iformation are received, usually of different type. All the info collected in a unit of time are grouped together to build a so called "experience". Experiences will be all saved to make a knowledge base that will be source-agnostic. We will call this collection a "composable information unit chain": a chain of CIUC. Every CIU and CIUC has a timestamp as a reference on the time axis. So every CIU and CIUC has an age. Let's now think about how to work on the several obtained CIUC.

I'm thinking about introducing "generations" for CIUC as well as for generations for the steps I make refining my theory, producing a new version of it every time.

Tuesday, June 02, 2009

Requirements for the DTO that should carry data for the ciu

Going to design the java object for carrying data taken from the jmx notification what should be considered a requirement ?

1 Must be generic enough to be able to absorbe differences between different types of notifications into a common interface.

2 Could be needed to be thread safe, like a non mutable object.

3 Its properties must be able to be explored by external agents (that could be one or more threads, see point 2).

4 Could be needed to be link-able or group-able with other composable info units.

From virtual devices' echoes to composable information units

About the first point let's analize how to render a composable information unit. These need to change domain as the
format they have when they are received by the clock class (DeviceAliasPortReadClockDaemon) is still very jmx-
notification like. In a very simplified view every information received is a property (sometimes structured) object.
Thinking to this (I ilike this game of watching objects as physical shapes) as geometric elements, what is that is
defined by a variable eguals to a number, another variable equals to another number, like:
x = 1y = 3z = 5anothervariable = 7stillanothervariable = 12
It seems to me to be a point. A point in a space defined by as many dimensions as how many are the properties
carried by the composable information unit received. So, for example, let's analize a sample (one unsolicited echo
received because of the fuel limit notification, an interrupt driven echo received because the vehicle bumped
against an obstaclea, an echo sent back as an answer to a read request generated by the clock class to gather the
vehicle position):


Sample of fuel notification that says "GREEN" level: ****************************Sequence number: 4Source: FuelTimestamp: 1243956311584User data: User data payload: it.free.i.virtual.machine.hal.devicealias.echo.DynamicParameterChangingEchoImpl@7ec028Dynamic parameter changing echo parameter name: FuelDynamic parameter changing echo parameter level: GREENUser data payload data type: nullClass: class javax.management.NotificationMessage: Fuel FuelType: UNSOLICITED_VALUE_CHANGED****************************

Sample of a collision detected echo:
****************************Sequence number: 21Source: devicealias.port.positioningsystem.collisiondetector-1243956298973Timestamp: 1243956311506User data: User data payload: it.free.i.virtual.machine.hal.devicealias.echo.CollisionEchoImpl@191777eCollision echo impacted object type: 0Collision echo center of mass position: x: 1.8370745 y: -3.553998 z: 1.1854142Collision echo impacted object description: BoxUser data payload data type: nullClass: class javax.management.NotificationMessage: devicealias.port.positioningsystem.collisiondetector-1243956298973
devicealias.port.positioningsystem.collisiondetector-1243956298973Type: PORT_INTERRUPT****************************

Sample of an echo received by the on board virtual GPS:
****************************Sequence number: 8Source: devicealias.port.positioningsystem.locator-1243956300864 READ verb answer Timestamp: 1243956312178User data: User data payload: it.free.i.virtual.machine.hal.devicealias.echo.PositionEchoImpl@10e18baPosition echo center of mass position: x: -0.022259876 y: -4.7243595 z: -0.15895882Position echo linear velocity: Vx: 0.011706882 Vy: 0.16265121 Vz: -0.14992155User data payload data type: nullClass: class javax.management.NotificationMessage: devicealias.port.positioningsystem.locator-1243956300864 devicealias.port.positioningsystem.locator-
1243956300864 READ verb answer Type: PORT_DO_READ_ANSWER****************************


These logs come from the application running a test. Now, these three types of echo you can find in package
it.free.i.virtual.machine.hal.devicealias.echo, are always communicating a bunch of information (as seen, solicited,
unsolicited, interrupts) but they have heterogeneous formats, as some have a structure, some have different
properties. This implies that a neutralizer and a common format is needed. possibly the format will be made as a
property object representing so an n-dimensional point in a n-dimensional space. This sounds particularly
interesting if taking into account that these will all become what we defined as composable information units. From
a geometric perspective these will be points going to be linked together and, still to play with solid
representations for java objects in design, these points linked in a structure will create a sort of "segment" or a
solid volume. Important to note: different points derived from different composable information unit could have a
different number of properties: points with different number of coordinates, so points in spaces with different
numbers of dimensions. The reason why I continue with this parallelism between java objects and geometric shapes is
that the closer I get to the "experience store" (knowledge base) representation, more It seems that the aggregation
is something more easy to understand if it is "visible". Well, it is also funny.
First problem by now, important to be solved, is the definition of a DTO for the composable information unit, and
(this comes for second and it is simpler to me) of a renderer to change every echo object into a unit of generalized
information.

swarm-i code evolutions

Code in warm-i is now at this point: a simple vehicle using jbullet demo has been instrumented using jmx. This allow for virtual device aliases (plugged on the jbullet demo) to collect informations and push them into a "clock" that every "n" milliseconds set on configuration, group up these data bags received from different virtual sensors into snapshots of the system. These informations received have attributes. These are composable information units. There are interrupt generated values for collisions, a positioning system, dynamic parameter fluctuating as fuel and structural consistency. These decrease with time but could be increased when hitting a specific shape. Commands are also available to: brake, accelerate, turn right and left. These will be made available to the clock thread as well. Now problem will be two:

First: how to render these data (as specified before all are echoes from read input commands sent by the clock class, or unsolicited interrupt-like jmx notifications) into composable information units. These are already collected in bundles grouping them toghether for the unit of time they took place.

Second: interesting game, defining how to create relationsships to build composable information units' chains.

It is necessary to solve first point 1.

Second: how to start

Tuesday, January 20, 2009

Answer is not a secret

As staten before, answer to that question is in:

http://en.wikipedia.org/wiki/Natural_Select

This can be applied to a swarm of composable information unit population ? Ok, but so linking between units, as they are composable, how does it much with natural selection algorithm ?

Problem is here again: two main features:

  1. composable
  2. natural selection population
Is one of these two wrong ?

Monday, January 19, 2009

"Rational" of the swarm common consciousness

At http://en.wikipedia.org/wiki/Natural_Select I can read about natural selection rules, and it is clear that looking for a rational cause for the swarm consciousness, it is possible to find that most of the units composing the swarm will act in a certain way. This will build "the trend" in the swarm behaviour. Now, let's change the previous question into this one: why most of the units act in that correct way that is positive in the balance of the swarm, whose intent is to survive and perfect the life of the swarm itself ? Why most of the units behave in "that" way ? Back to the unit, is it unit that somehow choose how to behave, as most of them choose in the correct way, how does it choose ?

Sunday, January 18, 2009

Natural selection of better software units in the composable information unit theory

It is not so common to have to think to natural selection theory, if you are not in the traffic. Yes. It is not something complex but interesting for me, so I take note to avoid to forget, here in my composable information studying journal. In a community the weakest unit dies to allow the community to have more change to survive (the community makes it die). The selection is performed by the swarm itself, like to say that the swarm makes choices. Swarm makes choices ? So swarm has conscience ? I correct: so the swarm has an its own intelligence ? Who gaves it to the swarm ? If no one gaves to the swarm any intelligence, is this a sort of side effect of the single intelligences of the units that compose the group ? There is a trend so of all the units to go in a "direction", in that way instead of a different one ? Moreover, according to natural selection the weakest units are selected to be abandoned because not productive for the whole swarm ? So the swarm knows which unit is weak, and so knows about every unit ? It really seems to me that the swarm projects over itself a super entity that is an emanation of all the units. This is like the behaviour of all the units creates its own GOD in a trend put in place by the fact that every unit main intent is to preserve its life, this through the existence of the species it belongs to.
I see incredible scenarios about the possible social aspects of the natural selection theory applied to the composable information units, swarm computing theory derivation. is the super entity the result of driving chaos of units ' behaviour behind the common and single unit intent of survival ? What can produce a swarm of much more complex entities (for example units having social and ethic rules) when projecting the common super entity that will performe the natural selection of strongests units ? Yes this is already part of genetic programming, but what happens if the code tries to distil the creation of a swarm conscience in the context of the composable information unit theory ? The intent in this context so, is to use this collateral derived intelligence to drive the system equipped with this software. I need to go to read about natural selection and Darwin, topics like random mutations created by "nature" to produce better units.

Monday, January 05, 2009

A particular learning curve: using inouts and outputs being unaware of what they are intended for

Let's play a game: a person is closed in an cockpit of an unknown vehicle type with no labels on leds and no labels on displays, no labels either on buttons and control levers. The person there inside can only see that when values changes on displays and leds turn on/off, "good" or bad "things" happen. The person in the cockpit has not a driving expertise for the misterious vehicle it is in, but starts associating things to do and values to keep under controls with the correct things to do to keep the vehicle running, preserving the vehicle. Maybe the driver will not associate the correct meaning to each display or button. Simply, the driver cans drive the vehicle without being aware of what controls are but just associating commands with useful or useless conseguences. This seems important, the driver associate values read and commands given on buttons and levers, the first with the second each other creating commands/value read associations in "paths" refined with experience. More experience will lead the driver to create "named paths", so specific path to allow the driver to do "macro" operations on the vehicle. More macros combined together gives "higher" macros. Here there is a new result: until the driver learns all the paths (combinations of controls usage and values to read from displays) the diver has an important learning curve that is essential. It is a sort of consciousness raising the driver has, without it the driver will lead the vehicle to crash somewhere.
What happens if the vehicle is compared to the a software application, displays and leds are vitual input devices, buttons and levers are virtual output devices ? Now new elements are needed to actually compare the system and the driver of the misterious vehicle:

1 The concepts of "good" and "bad" = "advantageous" and "disadvantageous" for the systems, rules
2 Rules to associate "advantageous" and "disadvantageous" with display reads and buttons/levers activations
3 Rules for associating reads and commands activations together in "paths"
4 Rules to update the paths refining them with increasing system eperience, improve the associations

We fall again in the concept of composable info unit but, this time, there are big news: system can absorbe the controls available to the system, without the need to define what displays and buttons to push are. There is an initial learning curve to transforme an unaware system into an aware one. Aware of unnamed inputs and actuators.