Amir Plivatsky

BTW, note the magic in the AND_type handling.

> `setlocale(LC_NUMERIC, "C")` in `dictionary_six_str()`, a thing that is not a good idea to have I had a problem in eliminating it, because it also controls printing (and numbers could...

> but the *print_l() functions are not yet universal (e.g. missing in Linux) Since now costs are converted to strings only using `cost_stringify()`, it will be enough to make this...

I'm now trying to prepare my floating-point handling branch for a PR. Among other things, I would like to eliminate any double-precision conversion. The primary motivation for using `float` instead...

Comments to what I wrote above: 1. An additional API with `double`: `static inline double lg_exp_get_cost(const Exp* exp)`. 2. These changes will not really eliminate `double` from the library, due...

> `grep -r USE_SAT_SOLVER * |wc` indicates there are over a dozen places where ifdefs could be removed. There are 27 places, some of which are due to different memory...

Yet another thing on the SAT parser: It naturally can lead to parallel processing per sentence if used with a parallel (multi-thread) SAT library. On 40 cores 10x speedup may...

> **one thing** with three brackets: `[[[@Xc-]]]` There are also things that get a cost >= 4 through `4.0.dialect`, the first one had originally 4 brackets: 1. `: [()]headline;` 2....

> get rid of it 1. Do you mean that we should get rid of `parse_options_set_disjunct_cost()`? 2. What is so bad about this concept? 3. Without a disjunct cost limit,...

> The discussion and confusion in https://github.com/opencog/link-grammar/issues/783 and about what Dennis had done indicate that its a poorly formed concept, at least for the English dict. Have you looked again...