TWiki> GRM Web>NGramSuggests (revision 6)EditAttach

OpenGrm Suggestions

  1. ngramapply takes --verbose, but -v=n (e.g. =v=1) is already provided (BER: fixed to use --v)
  2. ngramapply appears to be more of a debugging tool than than applicator given its human-readable type output. Perhaps a name that suggests or at least a comment in the quick tour that this is the case and that 'fstintersect' (possiby with a phi matcher) is the heavy-duty way to do this.
  3. Classes such as NgramModel are defined entirely internal to the class. Assuming it is not intended to be templated, then all the but trivial (read short) definitions should be turned into declarations and the definitions moved to a companion cc file (e.g. lib/ngram-model.cc). If it is intended to be templated, then long definitions should be moved out below the class defnition in the header file.
  4. Use true/false not 1/0 for bool values.
  5. NgramModel has a lot of member functions. Would it make sense to refactor to have a few key member functions and make other operations either part of derived classes or separate functions?
  6. Functions like NGramModel::AppendWordToNgramHistory should be static.
  7. NgramModel has useful methods defined privately. Shouldn't they be public or external?
  8. Use enum for ngrammodel 'method' e.g. enum NgramSmoothing { KATZ_SMOOTHING, WITTEN_BELL_SMOOTHING, ... };
  9. Use string as flag to ngrammake --smoothing=katz (and a switch to set enum).
  10. Improve memory usage of ngramread - uses 14 gb for 1.5gb input

-- MichaelRiley - 05 Nov 2010

Edit | Attach | Watch | Print version | History: r18 | r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r6 - 2011-01-29 - MichaelRiley
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback