Sunday, January 03, 2010

Getting sure IT should be 50% working, 50% continuous research

I'm getting more and more sure IT should be 50% working, 50% continuous research. As for medicine research means fixing more mankind problems, IT research means getting closer to artificial intelligence, not necessary to unviversal computation pourposes, but to solutions from a science that is cross boundaries for all the others.

“...clouds on the left and clocks on the right and animals
and men somewhere in between.”

(K. Popper 1965)

Emergence from systems, of intelligent new features. Evolution hits cells and logic, order, caos at the same time ? Is there a fractal model for all ?

Emergence showed in "Game of Life"



(look at it on Google, or on "Feltz - Self-organization and emergence in life sciences, Springer", if you are a rich man) is very strong but there are other mechanisms by which simple rules lead to complex dynamics. The neuron in brain is a simple,
deterministic machine that cannot lie or make an cannot make errors, but emergence ensures that we (the brains) can lie, using and being made of neurons. There is so hope that a more complex "Game of Life" built on structured and meaningful representations of information could evolve from simple rules to self generated and generating complex schemas ? Does it mean that a simple but well generalized "Game of life" could produce new schemas or rules (entities involved and rules moving the entities) able to seem intelligent, NOT BY CREATION, BUT BY ITS OWN EVOLUTION ?

IS INTELLIGENCE SOMETHING THAT CANNOT BE ACTUALLY CREATED, BUT SOMETHING YOU CAN PUT THE BASIS FOR AND WAIT FOR "EVOLUTION" TO CREATE IT FOR YOU ?

From the "Game of life" I saw that new entities and entities' distribution schema appears. Not new rules. Could new rules be self defined like it happens in the above mentioned "Game of life" for entities' distribution schema ?

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.