Re: TRM - Morbidity has set in, or not?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 18 May 2006 17:22:06 GMT
Message-ID: <232bg.9422$A26.235238_at_ursa-nb00s0.nbnet.nb.ca>


Marshall wrote:

> David Cressey wrote:
>

>>"Marshall" <marshall.spight_at_gmail.com> wrote in message
>>news:1147886349.702914.222780_at_38g2000cwa.googlegroups.com...
>>
>>
>>In order to build on the successes that OOP has acheived,  the messaging
>>scheme is going to have to go through a profound shift.  When people get
>>around to building a better messaging scheme,  they will discover that the
>>fundamental question is:  how can objects share data coherently?

>
>
> Hmmm. If you mean read-only data, then this is something of an
> implementation detail. If you mean read/write data (often called
> "state") then I think the right answer is externalizing them from
> the object. The separately-manageable database is the right
> answer.
>
> The problem with OOP is that it sprinkles state all through your
> program, like sprinkling sand into fine machinery. That state
> can't be managed or inspected, except with huge difficulty.

I think now is a good time to revisit Keith's statement about simulation. One should first note that there are different types of simulation.

Simula was invented for the sort of simulation that builts large unpredictable state machines by combining lots of small predictable state machines arranged in complex patterns.

What each simulation will look like will depend largely on what one wants to simulate.

A very simple simulation of digital logic circuits might involve:

A relvar of nodes { node, voltage }
A relvar of events { time, node, new_voltage } A relvar of devices { device }

Each node has a specific voltage.
A possible representation of a device is a device name and a relation of connections: { pin, node }
Each event specifies a time when a device will drive a node to a threshold voltage.

The nodes and devices define the circuit and initial voltages. Initially, the events relvar is empty.

The device supertype would declare a virtual state transition function that given the device, the connected nodes, and the time will calculate the relation of events on the pins driven by the device:

state_transitions(device,nodes,time): SAME TYPE AS events

Specific subtypes of device would define the state_transitions function differently. For instance, an AND gate type and an OR gate type might drive their output pins to different values with the same propagation delay while two different AND gate types might drive the output pins to the same value with a different propagation delay.

The simulation itself might appear something like:

t = time(0);
changed_nodes = nodes;
WHILE changed_nodes{} AND t <= time(simulation_end) BEGIN

	/* Determine the future events based on the current state */
	WITH EXTEND devices ADD
		state_transitions(
			device
			,nodes JOIN ( connections(device) {node} )
			,t
		) AS transitions
		{transitions}
	AS new_transitions,

		WITH UNGROUP new_transitions (transitions)
		AS new_events,

			events = events UNION new_events;

	/* Advance time to the soonest next event */
	WITH events {time} [time > t] AS future_time
		t = MIN(future_time,time);

	/* Trim the fat and remove no-op transitions */
	DELETE FROM events
	WHERE time = t
	AND (
		TUPLE { node node, voltage new_voltage } =
		TUPLE FROM nodes[nodes.node = events.node]
	)
	;

	/* Reflect the state transitions in the nodes
	   and record which nodes changed */
	WITH events[time = t] AS current_events,
		changed_nodes = ( current_events
				RENAME new_voltage AS voltage)
				{node, voltage},
		UPDATE nodes JOIN current_events
		SET voltage = new_voltage;

END; All that remains to make a fully functional simulation is to create the device subtypes, flesh out the type specifications and initialize the relvars. Each device subtype requires only a name and a state transition function. Received on Thu May 18 2006 - 19:22:06 CEST

Original text of this message