Skip to content

Draft: Verify Lumiere with independent Matlab implementation

John Hennig requested to merge verification into master

Adds a dedicated verification folder containing only the Matlab code needed to verify Lumiere with an implementation independent of Beast. Run verification.m to output the MFBD likelihood for a simple, but non-trivial case of a phylogenetic tree with only two tips, and export a Beast input file beast_config.xml with the same parameters that can be run with Lumiere to compare the result.

The code here is based on the content of the sim folder. Components not needed for this verification were removed. The remaining code was cleaned up and refactored.

Functional changes:

  • Fix seed and select algorithm for random-number generation. We are using the Mersenne Twister alogrithm (mt19937ar), the default in Matlab. Lumiere uses "MersenneTwisterFast" (MT19937), from beast.util, which might be exactly the same, though Matlab also has 'simdTwister' a.k.a. "SIMD-oriented Fast Mersenne Twister", so this can be questioned.

Refactoring changes include:

  • Render Beast config file from an XML template containing placeholders such as {{alignment}}. This makes the code that exports the Beast file more flexible and robust. Also avoid creating other output files that are never actually needed.
  • Use "handle semantics" for all classes, i.e. inherit from handle. This lets us use a sane method call syntax such as obj.set(value). With Matlab's default class implementation, objects are (inexplicably) immutable, which leads to unnecessarily confusing syntax like obj = set(obj, value).
  • Use the more recently introduced string type (marked by literals in "double quotes") rather than the traditional character vector (literals in 'single quotes') as much as possible. It's the better abstraction for strings and was arguably introduced when MathWorks finally realized that Matlab sucks at handling strings.
  • Cosmetic changes to improve readability, such as breaking very long lines, following common naming conventions like capitalized class names, shorter function names, suppressing irrelevant console output, doc-comments for important functions and methods, etc.
Edited by John Hennig

Merge request reports

Loading