With the new interface injection method, we could really have everything in a single assembly.
I think that raises circular dependency issues.

This can be as simple as storing all text that passes through it in a spare file and recalculating with the corpus + that file.

Could also be on the fly, I think manipulation of counts and NW* values is O(1)

Use small and large corpus with select known phrases and validate values.

Don't have to force SpellCheck & friends to use it. But we can write additional unit tests around it.

Is this just another case of INextWordModel? It fits the description, would just require a single rename of the Predict(...) method in Auger.

Could alternatively argue for a different interface that takes a list of previous words and a string representing the partial next word.

Branch them from their respective repositories. then add to Augury as submodules.

• Create with small, known corpus. Test things we know are true and things we know aren't true.
• Create with large corpus. Present with selections from corpus.
  • Create some metric for evaluating prediction score. Words guessed immediately should give more points than after 1 letter. Guesses after 3 or more letters should rank poorly.

Could add them as a passed-in parameter in the constructors. Will also need to add the information to the serializers.

Should be pretty easy, just

• Create ISerializer for each implementation of IStringMetric. That serializer can be empty and return an object created with the default constructor.
  • Could create an abstract class where T : class, default. Then empty subclass for the string metrics.
• SpellCheck and SymmetricPredictor can use Serializer.SerializeInterface

More generic than Augury.Lucene unit tests.

• Ensure results are the same when order is swapped.
• Ensure matching value is greater than or equal to non-matching value.
• Do the same for transpositions.
• Insertions
• Deletions
• Test against empty and null strings. Test different lengths.

Check to see if .Equals is overriden, if so, can simply serialize and deserialize.If not, need custom equality code in unit test.

Expected outcome is that it will take a bit less space but run slower.

Could just implement both and leave them available for injection based on user preference.

Trade-offs:

• DADAWG uses less memory. Maybe somewhere on the order of 30% less.
• DADAWG can traverse down a know branch in O(1) while DAWG needs O(log |alphabet|).
• DAWG can traverse all branches in O(|branches|) while DADAWG requires O(|alphabet|) in all cases.
• Creation of DADAWG might be slower. Depends on how good of a space-filling algorithm I can create.

These all cause strings to be stored in memory/interned. That takes up a large majority of the memory consumed by Auger.

Could consider creating a radix trie that stores int indices instead.

If using a trie, the DAWG will be redundant information. The exact same traversal method can be used.

Pretty sure it could use a rewrite of that ugly switch statement. Something like

var temp = history.skip(history.length-3).toList();
previous = temp.last();
partial = temp.take(temp.lenth-1);

Or, just change the method signature to accept partial and history separately.

I can probably draw from some existing code online. Also, try to make it work on a stream rather than a giant string.

• Create with small, known corpus. Test things we know are true and things we know aren't true.
  • Use the injected string metric to validate results. Add manual results that you know were traversed in the tree (or w/e) and should not make it past the metric. Use a case where you know all the words expected, make sure they're present.
• Create with large corpus. Present with selections from corpus.

Test JaroWinkler and BoundedJaroWinkler.

• Make sure BoundedJaroWinkler is always less than or equal to JaroWinkler.
• Test known values. Test cases with 0,1,all of matches and transpositions.
• Test various string lengths. Nulls and empty strings as well.

• Use small corpus and hand-calculated values to double check.
• Use large corpus and ensure some select known phrases compare predictably with each other. aka "How are you" > "How are monkeys"

It should be simple enough.

• Attempt inserts in sorted, unsorted, reversed orders.
• Try with lists that are full, too small, empty, too big.
• Try with tie breakers. Use a list where you would expect them and validate. Then add a value and see that the tie-breakers are gone. Then add more tie-breakers and validate.
• Try negative values only. Mixed negative and positive. Positive only.
• Try adding the same string twice.

It's possible StringComparison.Ordinal is not what the algorithm intends to use. Can double check by comparing node counts.

Instead of the completely arbitrary "maxErrors = prefix.Length > 4 ? 2 : prefix.Length > 2 ? 1 : 0", we could use the metric. A more likely scenario is a new interface type that would be a preemptive filter-metric, since a partial traversal of "word" by "wo" will fail, even though we mean to go further.
If there is a new interface for this and we feed it to the constructor, we should really provide a default, because this is going too far down the rabbit-hole of customization.