Email Communications

Date: Forgot
From: Michael Wales
To: Dr. Moshell

I've been doing some work coding for the Cellular Automata simulation. Jeff right now is working on creating the code for the user interface for editing the simulation's initial state. I've been working on developing the transition properties window. I just want to make sure the direction I'm heading for the user's transition editting interface is what you would like. I've included a screenshot of the window in the attached file.

On the left side of the window will be a list (it's not shown in the screen shot that I gave you) of all the different states like living, dead, burnt, etc. The move up and move down buttons next to the list are used to move a state's precedence up or down. I decided the states would need precedence incase a cell met the requirements to transition into two different types of states.

The highest state on the precedence would be what the cell would transition to. States can be added (and taken away) from the list by using the menu bar. I felt that the simulator should not have a limited number of states.

The right side of the window is the different types of transitions that could be possible ( things that spread like living cells, things that attack their neighbors like oak trees, etc.). We will program 2 or 3 of these transition classes for the simulator and the other couple of transition classes could be used at later times so a user could code their own algorithm into the simulator.

The simulator will be limited to 5 different types of transitions that can be performed. Each state can select which types of transitions it will abide by selecting the check boxes. By selecting a state on the left side of the window in the list, the right side of the window will update with that state's properties.

Each box on the right (that correspond to a type of transition) will be it's own seperate class in its own seperate .java file. The class has 2 boolean attributes that declare which arguements the class needs from that menu. Thats why there are different numbers of parameters for each transition.

Other things we have determined so far while coding:

  • We are using Java 2 V1.3, this program will not work on older Java V1.1 runtime environments.
  • Minimum computer requirements are Pentium computer with a resolution of around 1024 x 768 or higher. These limitations have come about because I am actually developed most of this code on a 486 Windows 95 machine at 800 x 600. The window is already larger than the screen, and the performance of the JRE is very poor on this sytem. The are not problems on the computers we use in the ECE lab.

If you have any concerns or suggestions, please email me or we can schedule a meeting. I could also demonstrate the program as it is now if you would like also.


Date: Forgot
From: Dr. Moshell
To: Michael Wales

I've been doing some work coding for the Cellular Automata simulation. Jeff right now is working on creating the code for the user interface for editing the simulation's initial state. I've been working on developing the transition properties window. I just want to make sure the direction I'm heading for the user's transition editting interface is what you would like. I've included a screenshot of the window in the attached file.

I like what I see.

On the left side of the window will be a list (it's not shown in the screen shot that I gave you) of all the different states like living, dead, burnt, etc. The move up and move down buttons next to the list are used to move a state's precedence up or down. I decided the states would need precedence incase a cell met the requirements to transition into two different types of states.

I think this may be a tough way to do it, because the precedence situation may relate more to rules than to states themselves. Say you have rules A2 and A3 with overlapping input conditions, which can lead to state S2 or S3 respectively. You want A2 to fire whenever A2 and A3 are both in effect. But maybe you also have rules B4 and B5 which lead to states S2 and S3, but you wish B5 to fire whenever both are in effect. Rule-based precedence could deal with this and state-based couldn't.

The highest state on the precedence would be what the cell would transition to. States can be added (and taken away) from the list by using the menu bar. I felt that the simulator should not have a limited number of states.

One thing one might think about is a 'consistency checker' to verify that rules have mutually exclusive input conditions. However I believe that this turns out to be computationally impossible in practice.

The right side of the window is the different types of transitions that could be possible ( things that spread like living cells, things that attack their neighbors like oak trees, etc.). We will program 2 or 3 of these transition classes for the simulator and the other couple of transition classes could be used at later times so a user could code their own algorithm into the simulator.

You will need to tell users explicitly how the rules work, not just with verbal descriptions. I like the verbals very much but they are not really clear.

The simulator will be limited to 5 different types of transitions that can be performed. Each state can select which types of transitions it will abide by selecting the check boxes. By selecting a state on the left side of the window in the list, the right side of the window will update with that state's properties.

That's fine for this semester's worth of work.

Each box on the right (that correspond to a type of transition) will be it's own seperate class in its own seperate .java file. The class has 2 boolean attributes that declare which arguements the class needs from that menu. Thats why there are different numbers of parameters for each transition.

Separate, not seperate.

Other things we have determined so far while coding:

  • We are using Java 2 V1.3, this program will not work on older Java V1.1 runtime environments.
  • Minimum computer requirements are Pentium computer with a resolution of around 1024 x 768 or higher. These limitations have come about because I am actually developed most of this code on a 486 Windows 95 machine at 800 x 600. The window is already larger than the screen, and the performance of the JRE is very poor on this sytem. The are not problems on the computers we use in the ECE lab.

If you have any concerns or suggestions, please email me or we can schedule a meeting. I could also demonstrate the program as it is now if you would like also.

Looks like you are doing a good job. Keep on!

JMM


Date: Forgot
From: Michael Wales
To: Dr. Moshell

I came up with the idea of having the state's precedence when thinking about how to implement the simulation. These were my thoughts:

  • The simulator would create a duplicate cell map as a canvas for calculating the next state of each cell.
  • The simulator would start with the lowest precedence state, and test to see if the cell will transition to that state. The simulator then continues up the precedence list for that cell until it checks all the states. Each time it concludes a cell will transition to the new state, the simulator updates the canvas.
  • After all the states are checked for the 1st cell, the simulation continues on to the next cell and so on.
  • The canvas should then represent the way each cell should look for the next time cycle.

I envisioned that method to be the simplest to code. I'm not really sure how I would implement rule-based precedence. Would each state have it's own rule precedence, or would all states share the same rule precedence? Will rule-based precedence be a simple list or is it a set of conditions for each rule?

If you don't have a preference as to whether to have rule-based precedence or state-based precedence, I would prefer to use the state based precedence because I seem to have a better understanding of it. If you prefer to have the rule-based precedence, could you elaborate on how I should set it up.

Also, the transition rules labels in the GUI where just put there so I had something filling up the space as I developed it. We haven't really settled on what the parameters will be called or what they will even be. We are planning on having the online help and user's manual to include detailed descriptions as to how the rules work.

It's a great relief to get so much positive feedback on what we have right now. Thanks. We will keep you updated as the development continues.


Date: Forgot
From: Dr. Moshell
To: Michael Wales

I came up with the idea of having the state's precedence when thinking about how to implement the simulation. These were my thoughts:

  • The simulator would create a duplicate cell map as a canvas for calculating the next state of each cell.
  • The simulator would start with the lowest precedence state, and test to see if the cell will transition to that state. The simulator then continues up the precedence list for that cell until it checks all the states. Each time it concludes a cell will transition to the new state, the simulator updates the canvas.
  • After all the states are checked for the 1st cell, the simulation continues on to the next cell and so on.
  • The canvas should then represent the way each cell should look for the next time cycle.

I envisioned that method to be the simplest to code. I'm not really sure how I would implement rule-based precedence. Would each state have it's own rule precedence, or would all states share the same rule precedence? Will rule-based precedence be a simple list or is it a set of conditions for each rule?

Yes, I agree it's simpler. Just goahead with state based, I reckon.

If you don't have a preference as to whether to have rule-based precedence or state-based precedence, I would prefer to use the state based precedence because I seem to have a better understanding of it. If you prefer to have the rule-based precedence, could you elaborate on how I should set it up.

Also, the transition rules labels in the GUI where just put there so I had something filling up the space as I developed it. We haven't really settled on what the parameters will be called or what they will even be. We are planning on having the online help and user's manual to include detailed descriptions as to how the rules work.

It's a great relief to get so much positive feedback on what we have right now. Thanks. We will keep you updated as the development continues.

Onward!

JMM


This page last modified by Michael Wales ( Mag7Rule@aol.com ) on November 18, 2000.