Amir Plivatsky

You once added a comment in `extract-links.c` on getting the lower cost parse, with a partial implementation under ` #ifdef FINISH_THIS_IDEA_MAYBE_LATER`. https://github.com/opencog/link-grammar/blob/acb424d5a464b161ccbbd1fb61faa4c7dd69941d/link-grammar/parse/extract-links.c#L358-L364 I finished its implementation 4 years ago in...

It can indeed be removed.

> * By knowing the (weighted) average of costs in a tree, we can know the likelihood of finding a low-cost path in that tree, and so searches for low-cost...

> which should have a low cost, because, at each step, you were picking from a collection having the lowest average. Are there paths that you can path fragments that...

``` text 755 * \k num_linkages_found-1 (by extract_links(), see process_linkages()). ... 794 * within the range of 0 to \k set->count-1 in order to extract all the ``` Just note...

> some ascii-art The various `S0` and `S1` can also be shared between the C elements. This is hard to draw. I think this may happen only at the same...

> If you see any mistakes in the above In an old analysis, I once did, I got convinced you cannot find the lower-cost path by assigning costs to parse-set...

What is `x_table_size` in that case? How many `Pset_bucket` and `Parse_choice` elements are used? It may also be interesting to know how many `Parse_set` elements point only to a single...

> Several choices: 1) predict in advance that there will be an explosive number of parse_choices, and skip creating the parse_set structure entirely (i.e. no linkages, just fail). The number...

See the long discussion in the still-open issue #783. I don't remember (and didn't compare now) if my proposed change is the same as your change here. In any case,...