Hacker Newsnew | past | comments | ask | show | jobs | submit | lexiathan's commentslogin

Hi wolfgarbe,

I don't believe my benchmark of SymSpell is misleading. I used the webassembly repository that is listed on your github: https://github.com/justinwilaby/spellchecker-wasm

Here is the code I used for my benchmark: https://gist.github.com/Eratosthenes/bf8a6d1463d2dfb907fa13c...

I reported the results faithfully and I believe these results reflect the performance that users would typically see running SymSpell in the browser, using the default configuration. If I had increased the edit distance, then the latency performance gap between Lexiathan and SymSpell would have been even larger, and then arguably I would have been gaming my metrics by not using SymSpell as it is configured.

Regarding dictionary size: The dictionary size (as you can verify from the gist) was 82k words. I didn't specify the dictionary size I used for Lexiathan, but it was 106k words.

Lastly, three of the words in the benchmark have edit distances greater than three:

distance("pronnouncaition", "pronunciation") = 4

distance("maggnificntally", "magnificently") = 4

distance("annnesteasialgist", "anesthesiologist") = 6

So I do not believe SymSpell would correct these even with the edit distance increased to 3.


Peter Norvig shows that an edit distance = 2 will cover 98.9% spelling errors. https://impythonist.wordpress.com/2014/03/18/peter-norvigs-2...

That's the reason why the default maximum edit distance of SymSpell is 2.

Now, all your 6 out of 6 examples are chosen from that 1.1% margin that is not covered by edit distance 2, presenting a rather unlikely high amount of errors within a single word.

The third-party SymSpell port from Justin Willaby, which you were using for benchmarking, clearly states that you need to set both maxEditDistance and dictionaryEditDistance to a higher number if you want to correct higher edit distances. That you neither used nor mentioned. This has nothing to do with accuracy; it is a choice regarding a performance vs. maximum edit distance tradeoff one can make according to the use case at hand.

https://github.com/justinwilaby/spellchecker-wasm?tab=readme...

pronnouncaition IS within edit distance 3, according to the Damerau-Levenshtein edit distance used by SymSpell. The reason is that adjacent transpositions are counted as a single dit. https://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_di...


The examples that I chose for my benchmark demonstrate that Lexiathan maintains accuracy and performance even on severely degraded input. On less corrupted input, Lexiathan runs significantly faster and is even more accurate.

Lexiathan also doesn't have any edit distance parameters that need to be configured, so there is no "tuning" required. In particular, it's worth mentioning that using a very large dictionary, e.g. 500,000 words, often degrades accuracy rather than improves it, and likely increases memory usage and latency as well.

Regarding Norvig's 98.9% figure--this seems to be from Norvig's own made-up data. In the real world, users often generate misspellings that exceed 2 edit distances in many use cases (OCR, non-native speakers, medical/technical terminology, etc), and published text (often already spell-checked) doesn't reflect the same level of errors. And in any case, Norvig's spell-checker apparently only achieves an accuracy of 67% on its own chosen benchmarks, so clearly the 98.9% figure is not a realistic reflection of actual spell-checker performance, even for an edit distance of 2. Lexiathan is extremely accurate and retains high performance even on heavily degraded input, and the benchmark data (and demo) that I presented reflect that.


For the curious: The article doesn't name the ally, but is probably referring to Qatar, which hosts the Al-Udeid Air Base, where the USAF has a significant presence. Geographically, the US could potentially strike Iran from Qatar; they are only separated by the Persian Gulf.


It probably did damage the runway a bit, but given that these ancient planes are no longer in production, the cost to repair whatever damage was done to the plane (looks pretty extensive, from the video) is likely much more expensive than whatever work is needed to fix the runway.


In defense of the students: the types of films that you watch as part of a film study curriculum are generally not the same as what most cinema-goers are watching. For example, "Man with a Movie Camera"--or 150 minutes of someone's black and white movie about the life of urban pigeons... present-day film students who grew up watching movies with tight editing, fast cuts, high resolution color and sound, and quick narrative payoffs are not going to respond to these movies the same way that people did a century ago.

This is not to say that historical films lack value; but sitting all the way through them with rapt attention is not necessarily as easy as you'd imagine.


The prior generation of film students grew up the same way, and the one before that. Remember westerns, for example?

If you're a film student, presumably you are interested in the art and technique, and then films like "Man with a Movie Camera" are fascinating and beautiful. Similarly, Vim does not appeal to a public accustomed to simple apps, no learning curve, gamification, and lots of graphics; but computer professionals see it as a thing of beauty.


Yeah but you have to watch Man with a Movie Camera with a good soundtrack like The Cinematic Orchestra one. Then it becomes the best non verbal movie ever.


I'll add it to my list!


I thought about doing this sort of thing a while back by parsing code into an AST + using a debugger API. Using an LLM is an interesting approach, but I would be concerned whether (a) it is reliable and (b) whether it is deterministic and replicable.


Hey! I'm glad to hear that you had a similar idea. It uses deterministic AST parsing and static analysis for the core spec generation. LLMs are only optionally invoked for natural language descriptions and documentation enhancement. The structural extraction (functions, parameters, types, dependencies) is fully deterministic and replicable since it's based on tree-sitter parsing, not probabilistic inference.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: