[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Atkinson
Subject: Re: [aspell-devel] Re: Can I get "edit distance" for the suggestions?
Date: Mon, 1 May 2006 18:40:18 -0600 (MDT)

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.*
"suggestion" instead of string, right?

That sounds reasonable.

Those files are in the common
directory.  Do the suggestion list/enumeration utilities belong
closer to modules/speller/default /suggest.cpp?

No they should still be in common since it will become part of the
interface which is not directly related to the current speller
(Ie a
different speller modules, if one was every written, would likely

I should also add, that if the files are automatically generated you
should modify "auto/" if possible.  Just use the other
example it should be easy to figure out.  If it looks like mk-src
do what you want than let me know.

I found and modified auto/; it's working like a champ!

The SuggestionList class it creates is abstract,  I'm thinking I want
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
attached to various things to enumerate through: DictStringEnumeration,
IstreamEnumeration, StringListEnumeration.  SuggestionListEnumeration
be like StringListEnumeration: a concrete class for
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]