[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: A spell corrector for apropos
On Wed, Oct 5, 2011 at 2:39 AM, Matthew Mondor
> On Tue, 4 Oct 2011 23:39:30 +0530
> Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost> wrote:
>> I have referred to Prof. Peter Norvig's article  on spell
>> correctors and translated his Python implementation to C. Following
>> are some of the results:
>> $ ./apropos "funckiton for coping stings"
>> Did you mean "function for copying strings" ?
> Very nice.
> If I understand, it would ask the question, although non-interactively,
> followed with results for the original string (as opposed to results for
> the corrected string)?
No, actually the reverse. This is how the spell corrector is
implemented. If a word exists in the dictionary then the spell
corrector assumes that the word is correctly spelled and does not
bother with computations. So if apropos returns search results with
the original query then it means that all the keywords were properly
spelled and the spell corrector would be useless. If even one of the
keywords was misspelled, apropos would not return any results and then
the spell checker kicks in. It scans the query to find the misspelled
words and informs the user. Then it is possible to show the result
with the corrected query (you can see this in the CGI version
On the other hand, if we modify the definition of misspelled words
slightly for the spell corrector, it would be possible to have the
behaviour as suggested by you. This goes back to what Dave hinted on.
Words with negligible probability should also be considered as
misspelled, in which case although apropos would produce the results
with original query but the spell corrector might think otherwise and
it would warn the user that s(he) probably meant to search the
> At least for me, this would be the least surprising mode, and if I
> really want I could run apropos again with the corrected string. It
> also would be no problem for the case you describe where the user
> really meant "acp" rather than "tcp", etc; it would not get in the way
> at all.
Yes, makes sense from usability point of view.
> If you want to then support a more fancy interactive mode (perhaps even
> a full screen mode with curses, or whatever), then an option/switch or
> ENV var could probably be used to enable the wanted mode...
I don't think that would be necessary :)
Main Index |
Thread Index |