Re: Re: Can I get "edit distance" for the suggestions?

On 5/1/06, Kevin Atkinson <[email protected]> wrote:
>
> On Mon, 1 May 2006, Ethan Bradford wrote:
>
> > On 4/27/06, Kevin Atkinson <[email protected]> wrote:
> >>
> >> On Thu, 27 Apr 2006, Ethan Bradford wrote:
> >>
> >>> On 4/27/06, Kevin Atkinson <[email protected]> wrote:
> >>>>
> >>>> On Wed, 26 Apr 2006, Ethan Bradford wrote:
> >>>>
> >>>>> On 4/26/06, Kevin Atkinson <[email protected]> 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.cppwhich
> > 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).

_______________________________________________
Aspell-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/aspell-devel