Hi Tuh2009/6/29 minh thu <not...@gmail.com>
> > First step solved. (BTW: I am attaching the first version to this e-mail. > I > > will upload to Hackage upon completion, when getIEEE754float64le and > > putIEEE754float64le functions are done!) > > Indeed, I found the binary format a difficulty for haskell. But in > fact, hackage has a module that does the work: > http://hackage.haskell.org/package/data-binary-ieee754 > Shame on me! :-( If only I have posted this rant earlier! :-D > 2) Running the VM: > > > > This is the step I am working on. A really good and obvious approach to > run > > the VM is to use a RWS monad, since: > > > > a) I have a fixed environment (the program and the input ports) > > b) I have a state (the program counter, the status register and > the > > data memory contents) > > c) I have a monoid output (the output ports) > > > > Why a monad ? Why not just a function State -> State and the use a function > like > iterate to do the work ? > I am considering that using the monad all the state and environment threading will be simplified. The output part is optional. But you are absolutely right, I could use a state composed by (Inputs, program counter, status, data), which would do just as well, as it is just a matter of not touching the program and the input. > > > 3) Controlling the sattelites > > > > This is going to be a piece of cake (aheeem! Just kidding!!). After > > computing the VM iteration, another computation will take the output data > > time series and estimate the next move. > > The next move is easy to estimate : you have the vm and simulating code at > hand. > Of course, making the best move is another problem. > I think the simulator itself is another State->State function, but this time the state is a [Output]. > Good luck ! > Thanks! > Rafael Gustavo da Cunha Pereira Pinto
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe