Re: [aspell-devel] Re: Can I get "edit distance" for the suggestions?

[Ethan Bradford]

On 5/1/06, Kevin Atkinson <address@hidden> wrote:

On Mon, 1 May 2006, Ethan Bradford wrote:

> On 4/27/06, Kevin Atkinson <address@hidden> wrote:
>>
>> On Thu, 27 Apr 2006, Ethan Bradford wrote:
>>
>>> On 4/27/06, Kevin Atkinson <address@hidden> wrote:
>>>>
>>>> On Wed, 26 Apr 2006, Ethan Bradford wrote:
>>>>
>>>>> On 4/26/06, Kevin Atkinson < address@hidden> wrote:
>>>>>>
>>>>>> On Wed, 26 Apr 2006, Kevin Atkinson wrote:
>>>>>>
>>>>>>> On Tue, 25 Apr 2006, Ethan Bradford wrote:
>>>>>>>
>>>>>>>> So I should clone common/string_enumeration.* and string_list.*
>> with
>>>>>>>> "suggestion" instead of string, right?
>>>>>>>
>>>>>>> That sounds reasonable.
>>>>>>>
>>>>>>>> Those files are in the common
>>>>>>>> directory.  Do the suggestion list/enumeration utilities belong
>>>> there,
>>>>>> or
>>>>>>>> closer to modules/speller/default /suggest.cpp?
>>>>>>>
>>>>>>> No they should still be in common since it will become part of the
>>>>>> public
>>>>>>> interface which is not directly related to the current speller
>> module.
>>>>>> (Ie a
>>>>>>> different speller modules, if one was every written, would likely
>> want
>>>>>> to
>>>>>>> them).
>>>>>>
>>>>>> I should also add, that if the files are automatically generated you
>>>>>> should modify "auto/mk- src.in" if possible.  Just use the other
>> entries
>>>> as
>>>>>> example it should be easy to figure out.  If it looks like mk-src
>> won't
>>>>>> do what you want than let me know.
>>>>>
>>>>>
>>>>> I found and modified auto/mk-src.in; it's working like a champ!
>>>>>
>>>>> The SuggestionList class it creates is abstract,  I'm thinking I want
>>>> the
>>>>> implementation in common/, since there's likely to be only one kind of
>>>>> SuggestionList, and as such, I'm thinking to override the produced
>>>>> suggestion_list.hpp with a concrete implementation, as is done for
>>>>> string_list.hpp.  I'm leaning towards keeping the abstract class for
>>>>> SuggestionEnumeration, and defining (also in common/)
>>>>> SuggestionListEnumeration as a concrete implementation working on a
>>>>> suggestion list.
>>>>
>>>> SuggestionListEnumeration?  What exactly will that do?
>>>>
>>>> I suggest you just copy what is done with String{List,Enumeration} But
>>>> instead of returning a "const char *"  return a "const Suggestion *"
>>>> object.  Suggestion should be a structure something like
>>>>
>>>>    struct Suggestion {
>>>>      const char * word;
>>>>      size_t word_size;
>>>>      float score;
>>>>    };
>>>>
>>>
>>> But StringEnumeration is an abstract class, with concrete
>> implementations
>>> attached to various things to enumerate through: DictStringEnumeration,
>>> IstreamEnumeration, StringListEnumeration.  SuggestionListEnumeration
>> would
>>> be like StringListEnumeration: a concrete class for
>> SuggestionEnumeration
>>> whose target data is a SuggestionList.
>>
>> Sorry, I though StringEnumeration had a concrete implantation.  Since
>> Suggestion Enumeration would have only one logical implementation it
>> doesn't make much sense to make it an abstract class.  None of my C++
>> interface is meant to be used by external programs, so if it becomes
>> necessary to make it into an abstract class that can be done latter.
>> However, I don't have any strong objections to making
>> Suggestion Enumeration an abstract class.
>
>
> All the various indirection in the data structures confuses me, though I
> think I've settled in to a proposal for the internal architecture.
>
> (1) I leave the SuggestionList and SuggestionEnumeration virtual.
> (2) In suggest.cpp, I rename the SuggestionList class to SuggestList (so as
> not to collide with the new acommon::SuggestionList).
> (3) I add a vector of Suggestions to SuggestionListImpl (renamed
> SuggestListImpl), parallel to the vector of Strings in the field
> "suggestions"; I can call it "scored_suggestions".
> (4) When Speller->suggest is called, it calculates scored_suggestions, then
> copies that into suggestions and continues as now.
> (5) I create a derived class of (new) SuggestionList in suggest.cpp which
> contains SuggestListImpl, called SuggestionListImpl.
> (6) Its elements() call returns a SuggestionEnumeration pointing to the the
> new scored_suggestions field of its SuggestionListImpl.
>     -- I hope this can use MakeEnumeration from enumeration.hpp.
> (7) A new method in Speller (maybe "scored_suggest") returns a new
> SuggestionList initialized with code common to the existing suggest method.
>
> An option is to store only the vector of Suggestion and make the enumerator
> which returns string suggestions know about the Suggestion structure,
> extracting the string it needs from that.  I don't favor that because it's
> extra work and doesn't save much space.

I'm not sure I 100% understand.  Please show me some what the interface
will look like so I can have a better understanding of what you propose.

At the interface level, a dialog will look something like this, matching (as far as I understand it) what you asked for:

     AspellSuggestionList * suggestions = aspell_speller_scored_suggest(spell_checker,
                                                           word, size);
     AspellSuggestionEnumeration * elements = aspell_suggestion_list_elements(suggestions);

     while (!aspell_string_enumeration_atend(aspell_elements))
     {
       AspellSuggestion sug = aspell_suggestion_enumeration_next(aspell_elements);
       // Use sug...
     }
     delete_aspell_suggestion_enumeration(elements);

 

At a lower level, I'm planning to add memory for an extra vector of Suggestion in the class that aspell_speller_suggestion returns (which will also be the main part of the class that aspell_speller_scored_suggest returns).