On Tue, 18 Apr 2006, Ethan Bradford wrote:
> Here's a proposal for the API:
> We add the type AspellIntEnumeration (or maybe a better name -- lower-case
> L next to cap I is ugly, but it would be nice if it was like
> AspellStringEnumeration).
> We add a call to extract that from an AspellWordList:
> AspellIntEnumeration * scores = aspell_word_list_scores(suggestions);
I was more thinking of using a struct something like
struct Suggestion {
const char * word;
int word_len;
int score;
}
and new methods to go along with it....
Is there an iterator to go through a list of these, like AspellStringEnumeration? And does AspellWordList contain all the data necessary to create that list?
>
> Behind the scenes, we add to AspellWordList a list of scores. The list of
> scores is set in Working::transfer when the list of words is created.
>
> On 4/2/06, Kevin Atkinson <address@hidden> wrote:
>>
>> On Fri, 31 Mar 2006, Ethan Bradford wrote:
>>
>>> I'm mystified as to how the definition of *AspellStringEnumeration* is
>>> hidden from us, so I can't peek inside of that. It seems obvious from
>> the
>>> outside that edit distance (
i.e. the # of changes necessary to get from
>> the
>>> checked word to a proposed suggestion) is used to sort the results
>> presented
>>> to the user. I'd like to use outside information to sort the results
>> with
>>> equal edit distance w.r.t. eachother. So how do I get the edit
>> distance?
>>
>> The "edit-distance" is not stored in AspellStringEnumeration. It is only
>> stored internally inside data structures in suggest.cpp. Also its not a
>> simple edit-distance function that is used to rank the suggestions, but a
>> combination of several factors, most of them being closely related to an
>> edit-distance. In the future other factors, such as frequency, may be
>> used to rank the suggestions. The more correct term to use is "score".
>>
>> As far as making the score available outside of
suggest.cpp, I am not
>> against it. I just haven't gotten around to it. I will gladly accept a
>> patch to this effect, however I will be fairly picky about how it is done.
>> For example I won't accept something that hacks AspellStringEnumeration to
>> include the score. A separate data structure should be used. Also,
>> backwards compatibility will need to be maintained.
>>
>