The mass referred to is the mass of the Earth. While the mass of the vehicle can be neglected, orbital velocity is very much a function of the mass of the body that is being orbited. The mean angular motion of an Earth orbitting satellite is sqrt(G*m/a**3) where is the G is universal gravitational constant, a is the semimajor axis, and m is the mass of the Earth. In a circular orbit, the speed is mean motion * radius.
My first experience with something like object oriented program was back in the 60's using SIMSCRIPT, a simulation language similar to SIMULA. The language was actually a preprocessor to a Fortran compiler. The code generation idioms used in the translation were very interesting and could be used as a way of writing object oriented Fortran.
I'm not sure whether SIMSCRIPT came before or after SIMULA but I believe they were developed around the same time with similar ideas in mind. In SIMSCRIPT objects were called "entities" and classes were called "entity types". Entities had most of the features of what we now call objects. They had attributes, behaviours, agregation and a limited form of inheritance. There was a particular base class of entities called event-notices that were used wre used to schedule events in simulated time.
The power of this object orient approach to simulation comes into focus on problems where the behaviour of individual entities is well understood but consequences of interaction between entities boggles the mind. You write subroutines to model the response of each entity type to each event type, set some initial conditions, and let it rip. There are a significant number of engineering problems that fit this pattern.
This type of simulation can easily be written in C++, or any language that supports classes, by writing a simple scheduler that sequences event objects in simulated time.
Some examples are useful to illustrate the point. In each cases, it is relatively easy to imagine modelling the behaviour of each individual class in spite of the fact that the overall problem seems daunting. (These are actual problems that have been simulated with this technique.)
Simulation of an aircraft running a gauntlet of air defences. Classes: missiles, launch events, flares, manuever events, tracking radars, jammers, etc
If you are doing hard real time where timing tolerances are really critical, neither printf or a software debugger are of any use. The printf will alter the timing the very thing that you are trying to observe. Although there are some fairly expensive solutions, I like using the parallel port and an oscilloscope. Instead of printf's, insert direct io writes to the parallel port into your program. View the output on a multichannel oscilloscope or logic analyzer.
Some people find this approach incongruous with an operating system like Linux where such bare metal tactics seem at odds with the prevailing higher levels of abstraction. But timing tolerances can only be observed by direct viewing.
If this is a project with actual funding, there are solutions that are less improvisational. Many logic analyzers have bus preprocessor cards that can be inserted into an empty card slot of almost every conceivable chassis type. The logic analyzer also come with software that will display the traces in nice formats for viewing. You can then see the timing relationships of both your inserted I/O writes as well as any other activity. On a modern computer, often all the other activity is too confusing so the logic analyzer can be set up to filter it out. There are also complete logic analyzers that can be inserted into a card slot.
In spite of all the modern gadgets now available for real time debugging, I still occasionally find use for some of the improvised tricks I learned before such devices were for sale.
Larry
Slashdot Mirror
The mass referred to is the mass of the Earth. While the mass of the vehicle can be neglected, orbital velocity is very much a function of the mass of the body that is being orbited. The mean angular motion of an Earth orbitting satellite is sqrt(G*m/a**3) where is the G is universal gravitational constant, a is the semimajor axis, and m is the mass of the Earth. In a circular orbit, the speed is mean motion * radius.
My first experience with something like object oriented program was back in the 60's using SIMSCRIPT, a simulation language similar to SIMULA. The language was actually a preprocessor to a Fortran compiler. The code generation idioms used in the translation were very interesting and could be used as a way of writing object oriented Fortran.
I'm not sure whether SIMSCRIPT came before or after SIMULA but I believe they were developed around the same time with similar ideas in mind. In SIMSCRIPT objects were called "entities" and classes were called "entity types". Entities had most of the features of what we now call objects. They had attributes, behaviours, agregation and a limited form of inheritance. There was a particular base class of entities called event-notices that were used wre used to schedule events in simulated time.
The power of this object orient approach to simulation comes into focus on problems where the behaviour of individual entities is well understood but consequences of interaction between entities boggles the mind. You write subroutines to model the response of each entity type to each event type, set some initial conditions, and let it rip. There are a significant number of engineering problems that fit this pattern.
This type of simulation can easily be written in C++, or any language that supports classes, by writing a simple scheduler that sequences event objects in simulated time.
Some examples are useful to illustrate the point. In each cases, it is relatively easy to imagine modelling the behaviour of each individual class in spite of the fact that the overall problem seems daunting. (These are actual problems that have been simulated with this technique.)
Simulation of an aircraft running a gauntlet of air defences. Classes: missiles, launch events, flares, manuever events, tracking radars, jammers, etc
Network traffic simulation. Classes: packets, routers, transmission lines, store events, forward events etc
Simulation of mutual interference among cell phone users. Classes: Cell phones, Base stations, calls, start of call events, end of call events etc
Disaster casualty evacuation. Classes: ambulences, dead, wounded, ambulence arrival events, street obstructions etc
If you are doing hard real time where timing tolerances are really critical, neither printf or a software debugger are of any use. The printf will alter the timing the very thing that you are trying to observe. Although there are some fairly expensive solutions, I like using the parallel port and an oscilloscope. Instead of printf's, insert direct io writes to the parallel port into your program. View the output on a multichannel oscilloscope or logic analyzer. Some people find this approach incongruous with an operating system like Linux where such bare metal tactics seem at odds with the prevailing higher levels of abstraction. But timing tolerances can only be observed by direct viewing. If this is a project with actual funding, there are solutions that are less improvisational. Many logic analyzers have bus preprocessor cards that can be inserted into an empty card slot of almost every conceivable chassis type. The logic analyzer also come with software that will display the traces in nice formats for viewing. You can then see the timing relationships of both your inserted I/O writes as well as any other activity. On a modern computer, often all the other activity is too confusing so the logic analyzer can be set up to filter it out. There are also complete logic analyzers that can be inserted into a card slot. In spite of all the modern gadgets now available for real time debugging, I still occasionally find use for some of the improvised tricks I learned before such devices were for sale. Larry