The patch was against 0.60.4. I don't really have an opinion on your design questions, except a question of my own: why do you want the extra information? I wanted to get the scores out so that I could (1) filter on them and (2) combine them with other information (frequency information from another source) to better sort the result list.
On 11/16/06, Gora Mohanty <[EMAIL PROTECTED]> wrote:
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": > http://sourceforge.net/tracker/index.php?func=detail&aid=1489981&group_id=245&atid=300245 [...] 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 step. 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. Regards, Gora _______________________________________________ Aspell-devel mailing list Aspell-devel@gnu.org http://lists.gnu.org/mailman/listinfo/aspell-devel
_______________________________________________ Aspell-devel mailing list Aspell-devel@gnu.org http://lists.gnu.org/mailman/listinfo/aspell-devel
