[Top][All Lists]

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

Re: [aspell-devel] Thoughts on using aspell for Indian language checking

From: Gora Mohanty
Subject: Re: [aspell-devel] Thoughts on using aspell for Indian language checking
Date: Fri, 17 Nov 2006 04:19:11 +0530

On Sun, 2006-11-12 at 22:41 -0700, Kevin Atkinson wrote:
> On Sun, 12 Nov 2006, Ethan Bradford wrote:
> > As luck would have it, I already added the scores to the C API.  Depending
> > on Kevin's and your preferences, I could send you a patch on 0.60.4, or
> > Kevin can get you an early version of the next release, or you can just wait
> > for it...
> I take it you mean patch [ 1489981 ] Implement export of "Score":

Some queries for Kevin and Ethan, specifically. I take it that the
submitted patch is against aspell 0.60.4? I have gone through the
patch file very quickly to get a flavour for it, and here are some
additional scoring details that I would like to see returned:
1. The word score and soundslike score should be returned separately,
   in addition to the total score. Actually, in this case, returning
   the total score can be dispensed with, as it can be calculated from
   the other two scores, given the known weights.
2. I am not sure if this is a good idea, but I was thinking that it
   should be possible to separately access scores after each step in
   Working::get_suggestions(), i.e., after each time that score_list()
   is called, and finally after fine_tune_score() is called. This would
   make it possible for someone testing the working of aspell in a new
   language/domain to access all relevant details. 
     One way to do this in Ethan's patch would be to make
   SuggestWordListImpl::suggestions an array of NearMissesFinal objects.
   The size of the array is known beforehand (the total no. of calls to
   score_list(), and to fine_tune_score()), and the index into the array
   defines the point at which the scores for the list of suggestions
   in that element were recorded. The scores for the suggestions in each
   array element are entered by calling transfer() after each call to
   score_list(), with the current index into the array as an argument.
   For calls to score_list() that are skipped by the setting of
   suggestion mode, the corresponding element will just be a zero-length
   Vector. The last non-zero-length element in the array is always the
   final set of scores.
     Thus, in the public C interface, aspell_scored_suggest() would
   return the final set of scores (as Ethan does now), but a second
   function, say aspell_scored_steps_suggest(), with the desired array
   index as parameter could return the set of scores at the desired
3. Currently, the patch I have for changing soundslike weight, and edit
   distance costs uses separate class methods for each such parameter,
   e.g., get_del1_cost()/set_del1_cost(), with the methods exported
   upwards till they are exposed through similarly named functions in
   the C interface. I see nothing fundamentally wrong with this
   approach, though it adds many tiny functions to several classes. Is
   this an acceptable design?

If nobody sees any major issues with the above points, I will write up
a short design document, and work on a patch over the next few days.


reply via email to

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