Stuff in order of being written: orb.[hc]: an interpretive virtual machine in C other .c: ...and associated utilities.

icomp/ideco: translate input traces from/to a text format; invoke like cat sim: the simulator; "./sim foo.obf bar.osf" or "./sim foo.obf < bar.osf"; prints outputs changed at each time step disas: disassembles scenario binaries (requires input on stdin)

hohmann.zsh: Yes, I did the Wikipedia-cribbed math in zsh. Why not. meetgreet.zsh: Likewise. (Note the variable "fudge" in this and the above.)

orbit_caml.c, orbit.ml: OCaml bindings for the interpreter &c orbutil.ml: attempts at doing physics on my own; never quite worked right

pretty.pl: takes output of disas and makes it prettier

disas.ml: Now I can disassemble VM programs in ML... ncmplr.ml: ...and compile them to C.

The VM-to-C compiler is noteworthy in that it can cause a subset of the inputs to be vector-valued, thus running several instances of the machine in parallel. In particular, values and computations which are not influenced by the vectorized inputs remain scalar. Thus, for example, bin4.obf vectorized on the delta-v input but not the scenario input will compute the target satellite positions only once, while at the same time simulating arbitrarily many spaceships. Aside from cutting down on reduntant computation, the vectorization should allow gains from data parallelism (to whatever extent it can be juiced out of the C compiler; there is likely room for improvement here).

Also, it is possible to have multiple simulations living in the same C namespace, and have one initialize its state to that of another. This, for example, could be used for efficiently simulating many flight plans with a common prefix.

gridtrace.(ml|c): a failed attempt at finding a path to some satellite by casting a parallelogram-grid of delta-v's and, in theory, proceeding recursively into grid cells which wind up somewhere useful. (The set of parallelograms is closed under the action of the group generated by rotations and scalings, which seems to go not entirely badly with orbital mechanics.) In practice, for cells of large enough size to be useful in the initial stages of such a search, the grid bends too far out of shape to be useful. Oh well.

scattertrace.(ml|c): oddly like my 2008 strategy; cast a bunch of rays at random, and repeatedly focus the dispersion around the "best" ray. This is where I finally got something working enough to make the common-prefix stuff happen. Became piled high with dodgy heuristics in the later hours, but I've tried to more or less keep compatibility, and record the flags I used (on a new OCaml process, which has a deterministic random seed).

Building/Using:

Assumes that a subdirectory "specs" has been created and the scenario files are within.

Applying GNU make to the default target should take care of building. Note that the scenario number to use in scattertrace is hard-coded into the C file; it shouldn't be hard to find.

(Requires GCC, OCaml with dynamic library support, and zsh for the section 1/2 stuff. Assumes a little-endian machine with IEEE floating point; AMD64 is one such. (A static-only OCaml can be accomodated without much work, as probably could a generic C99 compiler.) Also perl for the pretty-printer.)

Near the bottom of scattertrace.ml are my notes on the arguments I gave the function there for the various problems. Basically, inside "ocaml scattertrace.cma", "let at = Scattertrace.moreauto [the arguments];;", hope it eventually terminates, "print_string (printout [scenario#] at);;", copy that text, then in a shell "./icomp > whatever.osf" and paste the text. If done first thing in a new OCaml process, that should get the same random seed as I did.