Saturday, December 10, 2016

Word Game

For fun, and to prove to myself that I still have coding chops after my hiatus, I put together a generalization of the game Boggle few months ago.

It's an extension to Boggle because it supports alternative rectangular grids to the standard 4x4. As published it uses the bsd unix wordlist but other wordlists can be used; this allows easy portability to other languages, though it is still hard-wired to the 26 character alphabet used in English.

The task of finding all solutions, i.e. words of arbitrary length, in a standard-sized or larger boggle array is nontrivial. Pruning the search tree is necessary, as the number of all possible sequences is immense. One version of the game that I often play on my iPhone limits solutions to 7 letter lengths, which is exasperating when you find an 8 or 9 letter word! My version does not have this limitation.

Also I have a version, a little behind the main one, wherein played with the Python curses library, because I can be a bit old-fashioned.

All visible here: https://github.com/mtobis/mt_word_game

Work done at U Texas for ensemble management

Work done at U Texas for management of large ensembles of large scientific calculations, with robustness to job failure or resource allocation expiry, is visible here:

https://bitbucket.org/mtobis/tex-mecs

This is structured as a framework. The computation code and the analysis code are plugged into the framework by the end user. This is designed to be minimally intrusive. If the varied parameters of interest are already read in from a file and the code is runnable on the target machine, the user need only understand a fairly simple method for declaring the structure of the computation in ensemble parameter files.

Because the models are presumed coarse-grained (running for hours, not milliseconds) operating system calls are not costly. Consequently it is possible to wrap the executables into python objects, which makes the underlying code quite clean.