ndaniels / mrfy Goto Github PK

Our paper claims that amino acid is represented using a newtype declaration. Phrase make it so.

Show instances for transition and emission probabilities should ease debugging by not showing transitions and emissions that are present with zero probability. The right filter should do it...

Confirm that commit 049883f is at worst no slower than 2f9bd4f on any machine or benchmark we know about.

(The first is "new HO Viterbi with strict scoring and preceders as a function".)

(The second is the ICFP version on the master branch.)

I'd like to have a meaningful viterbi benchmark that's short enough to use valgrind's profiler. That will give us some information about instruction counts and instruction mix. And the numbers should be comparable across platforms.

Benchmark ratios seem highly variable on different hardware platforms.

We need an automated way to accumulate and track this information, so we don't chase any will-o-the-wisps.

MonadRandom >= 0.4 contains instances for Control.Monad.RWS.Lazy

Would this instance suffice rather than the custom LazyRandom monad?

Are their any unique features it has that should be documented in comparison to MonadRandom?

Is their any performance issues with the RWS transformers?

The first thing to do is probably to revert to the identical array type used for the original Viterbi.hs. Just to eliminate a possibly gratuitous source of variation.

let's wait on this since I'm not sure if it's critical to the paper

Aging tenured faculty can't find their email.

Our manuscript has strictness annotations on type Scored. They need to be either removed or justified with a measurement.

Use the (presumed slow) list memo combinators, and no more suffering with indices.

We may get different results from x86 and AMD64.

[andrew@Liger nr-jfp-refactor] ./mrfy -test fight-path
*** Failed! Falsifiable (after 2 tests and 97 shrinks):    
fromList [
(#0: no-transitions; no-M-emissions; no-I-emissions),
(#1: D-1.00->M; no-M-emissions; no-I-emissions)]
fromList [AA 18]
OPATH: [Mat]
NPATH: [Del]

Notes:

me: it seems like a pretty subtle bug: when there are two nodes and a single observation, then the Oracle claims the state path should just be a
Mat
even if the
d->m
transition is most likely...
Sent at 7:41 PM on Sunday
Norman: I think Oracle is right here.
I think there is only one nonzero path.
Maybe I will try another diagram tonight.

Make sure that 'old viterbi' produces expected results on outside data, and get some kind of script or mk target or README instructions for running those tests.

This might be done already, but I haven't run mrfy-bench because the instructions are buried where I can't easily find them....

For testing purposes, I see no reason not to have 0-node and 1-node HMMs. Unless the old Viterbi can't handle it, they should be fine.

Also, the instance for HMMNode needs a shrink function.

Take the commit tagged first-consistent-ho-viterbi from the nr-jfp branch and see if you can get the compiler to specialize the internal [ edge ... ] computation by abstracting over the preceders and emission functions and telling the compiler to inline. Right now there are four calls to internal; it would be fantastic if each could be replaced by a call to a single function that is pragma'd to be inlined, without losing peformance.