On 11 July 2010 22:08, Jacob Nordfalk <[email protected]> wrote:
> First: Great work Jimmy, trying to improve transfer is a good thing.
>
> 2010/7/11 Jimmy O'Regan <[email protected]>
>>
>> > Of course, one can always acheive the same as <exception> by using
>> > <choose><when> and duplicating the contents of the single-item rules,
>> > but, well, that means duplicating content… this looks like it would be
>> > a lot simpler to maintain (and less ugly than output macros).
>> >
>>
>> Yeah; having to repeat almost all of the same rules in two layers of
>> transfer is a bit excessive.
>
> So now there would be 2 solutons to the rule duplication problem:
> - macros
> - 'exceptions' -
Not really. Macros don't solve the problem I mention in my second
mail, which I see I have to put in other terms.
Ok, so you have 4 rules
adj_nom
nom_adj
adj
nom
You have the input nom adj nom; the way transfer currently works, you
can only get either
{nom adj} {nom}
or (with internal checking, which is what the macro would be used for)
{nom} {adj} {nom}
There's no way to get
{nom} {adj nom}
without having a second set of more-or-less the same rules in t2x. Now you can.
> where you as far as I understand keep track of previous
> ''second longest" match of rules and in reality backtrack if the current
> rule 'fails'/throws an exception.
Yes; currently it tracks the last match, which is good enough for a
prototype, but for a user-ready version, it will have to keep a stack
of all positions since the last time output was written.
> Really, there is a 3rd solution which noone have used, but it might need
> consideration:
> Using XSLT on the transfer files to preprocess them, like the metadixes.
> In this way you could write the rule body just once and use it on several
> rules. Some smart XSLT might even allow to get rid of boring but nontrivial
> duplications like ADJ NOM, ADJ ADJ NOM, ADJ ADJ ADJ NOM, ADJ ADJ ADJ ADJ
> NOM expanding a single rule like ADJ[1-4] NOM. This would, at least in the
> Esperanto pairs, allow us to catch al lot of stuff that occurs too seldom to
> justify another rule duplication, but which would be nice to cover.
>
You've mentioned more or less the same thing before; for better or
worse, it didn't really catch anyone's attention - I don't want to get
into why or why not right now - but it still doesn't solve the problem
I mentioned above.
>>
>> >
>> > I'm still trying to make it break :)
>> >
>>
>> Well, as I mentioned, if the rule that it's falling back to also has
>> an exception, which also evaluates to true, then you will get
>> breakage: you'll either lose all but the first word, or it'll
>> segfault, which are both drastically bad outcomes.
>
> Thats becaurse you keep track of just the previous rule match.
> Really you'd need an array of all the shorter rule matchs (so a match of ADJ
> ADJ ADJ NOM would be in the 4th place in the array).
Yes, and I mentioned what I intend to do to change it in the first
email, but I want to get feedback from advanced users to see if
there's something I'm not taking into consideration.
> If you're interested I think I can implement that reasonable fast in the
> Java version.
Well, that's part of the idea of disclosing what is basically a sketch
of what I want to do :) As I mentioned earlier :)
> There are some things to consider: For example, if there is an ADJ ADJ ADJ
> NOM rule and both an ADJ ADJ ADJ and an ADJ ADJ NOM rule, and you'd like ADJ
> ADJ NOM to be applied. First longest match dictates ADJ ADJ ADJ, so you'd
> have to make that fail, as well as ADJ ADJ and also ADJ.
>
Yes; this is what I meant by a stack of pairs; stack< pair<
rule_to_evaluate, buffer_position > >
> --
> Jacob Nordfalk
> एस्पेरान्तो के हो? http://www.esperanto.org.np/.
> Memoraĵoj de KEF -. http://kef.saluton.dk/memorajoj/
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Apertium-stuff mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>
>
--
<Leftmost> jimregan, that's because deep inside you, you are evil.
<Leftmost> Also not-so-deep inside you.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
