> That's really interesting! I see it depends on lttoolbox, would it make > sense to include it in lttoolbox perhaps?
Potentially, though right now it's in the slightly odd state of depending on Lttoolbox because that's the backend I'm more familiar with but being intended to work with HFST because that's the frontend I'm more familiar with. > Can you explain a bit more about how it works / why it's faster? Perhaps > in the README, along with the string "600x faster" ;) The short version is that the twoc way is to generate all combinations of paths and then use restriction rules to get rid of unwanted combinations, whereas this internally copy-pastes the lexicons together to only generate desired paths in the first place. The speed boost is because lexd has runtime fairly similar to hfst-lexc, but then also eliminates the need for hfst-twolc .twoc and hfst-compose-intersect on that .twoc (there's still compose-intersect on the .twol, though). But yes, I'll see about adding a fuller description to the README or somewhere. On Mon, Feb 3, 2020 at 8:28 AM Kevin Brubeck Unhammer <unham...@fsfe.org> wrote: > Daniel Swanson > <awesomeevildu...@gmail.com> čálii: > > > https://github.com/mr-martian/lexd > > That's really interesting! I see it depends on lttoolbox, would it make > sense to include it in lttoolbox perhaps? > > Can you explain a bit more about how it works / why it's faster? Perhaps > in the README, along with the string "600x faster" ;) > _______________________________________________ > Apertium-stuff mailing list > Apertium-stuff@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/apertium-stuff >
_______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
