> 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

Reply via email to