>>When I wrote about calculating every second vs. every day (for example), I was referring to the time you are modelling.
>
>Ah, yeah, that makes more sense. This is apart of having adjustable physical units. For example, in the speed you could use m/s or km/h or anything else one coudl dream up.

For the physical units, I would suggest, to keep it simple, to do all calculations in SI units: that is, masses in kg., distances in m, velocities in m/s, accelerations in m/s^2, forces in Newton (m * kg / s^2).

If you want the user to input data in any other units, like miles/hour, do this only on the input - and perhaps output - side. Convert to SI for the internal calculations.

>
>
>>>I wonder if it would be necessary for something like the following:
>>>
>>>A two tiered model, one simply crushes the numbers and puts them into a DBF. This has the position and speed of each object. The second one is able to "play" this data like its a movie, being able to slow down, speed up, rewind, zoom, and what have you.
>>
>>I think objects in memory, as you did, are OK - except for the rewind part.
>
>I don't know. I like the new idea more. You need the raw data if you're going to do any analysis anyways. I like the two tiered approach. You could wind up writing something so much faster (which mean so much larger in what can be modeled).
>
>>>If you had two threads running (in VFP's case it would have to be two different EXEs accessing the same DBF) you could be populating the objects as fast as possible and viewing the model graphically at whatever speeds you'd need.
>>>
>>>This is particularly cool because you could build a SETI-like distributed application to crush the numbers for research far more easily without wasting any cycles on the graphics side.
>>>
>>>Hehehe. The plot thickens.