How do I get the rules' ranks in semantic actions?

8 views
Skip to first unread message

rns

unread,
Sep 8, 2012, 12:48:29 AM9/8/12
to marpa-...@googlegroups.com
This is needed for [1].

I can get the rule IDs and names and the grammar [2] but not the rank [3].

Am I missing something?

Thanks in advance.

[1] 
The most general way to sort Marpa parses is for the application to take control. The application can set up the Marpa semantic actions so that the parse result of every parse tree is a <rank, true_value> duple. The duples can then be sorted by rank. Once the resuls are sorted, the rank element of the duple can be discarded. 

[2]
    my $rule_id = $Marpa::R2::Context::rule;
    my $grammar = $Marpa::R2::Context::grammar;
    my ( $lhs, @rhs ) = $grammar->rule($rule_id);
[3]

sub Marpa::R2::Grammar::rule {
    my ( $grammar, $rule_id ) = @_;
    my $grammar_c = $grammar->[Marpa::R2::Internal::Grammar::C];
    my $rule_length = $grammar_c->rule_length($rule_id);
    return if not defined $rule_length;
    my @symbol_ids = ( $grammar_c->rule_lhs( $rule_id) );
    push @symbol_ids, map { $grammar_c->rule_rhs( $rule_id, $_ ) } (0 .. $rule_length - 1);
    return map { $grammar->symbol_name($_) } @symbol_ids;
}

Jeffrey Kegler

unread,
Sep 8, 2012, 1:02:02 AM9/8/12
to marpa-...@googlegroups.com
What I was trying to say in the quoted portion is that *you* must compute the rank as part of the parse value.  So the parse value might, for example, be a pointer to an array whose first element is rank, and whose second element is what would otherwise be the returned value.  You then collect all these and sort them.  In other words, in the most fully general ranking method, the application basically does almost all the work itself.

The ranking methods currently implemented within Marpa were the result of a lot of experimentation.  The ones Marpa implements directly are only those where Marpa's evaluator can clearly "add value", in the form of efficiency.  This means they are fairly simple and require only the kind of local knowledge that the evaluator can efficiently act upon.  If you are ranking, say, parses of English sentences, you could easily get into the kind of complexity where you may simply have to dump all possible parses from Marpa, and after the Marpa run is complete, compute the rank and sort them.

I hope this clarifies/helps,

jeffrey

rns

unread,
Sep 8, 2012, 1:12:33 AM9/8/12
to marpa-...@googlegroups.com
I hope this clarifies/helps,
Yes it does. Thanks a lot for the quick reply.

Then the true_value in "<rank, true_value> duple" is just a reference to a parse tree with that rank, am I right?

And the two orthogonal approaches to ranking when using Marpa are (1) assigning ranks to rules in the grammar and letting Marpa do the sorting/rejection ("rule" and "high_rule_only") and (2) assigning ranks to rules in the actions and sorting the parse trees by traversing them in the application?

Jeffrey Kegler

unread,
Sep 8, 2012, 1:21:35 AM9/8/12
to marpa-...@googlegroups.com
If the parse values in your application are trees then, yes, true_value would be a parse tree.  (In a calculator, for example, the parse value might be an integer.)  It may also be the case that it's more convenient to just return the tree and figure out its rank afterwards.

The two ranking approaches aren't necessarily orthogonal.  Again, take the example of ranking parses of English sentences.  You might be able to craft a strategy where you use "rule" ranking to get an approximation, and only generate (for example) the top 6 parses.  These you subject to a more expensive ranking algorithm and the winner of the second ranking becomes the parse.

-- jeffey

rns

unread,
Sep 8, 2012, 2:05:51 AM9/8/12
to marpa-...@googlegroups.com
On Saturday, September 8, 2012 8:21:38 AM UTC+3, Jeffrey Kegler wrote:
If the parse values in your application are trees then, yes, true_value would be a parse tree.  (In a calculator, for example, the parse value might be an integer.)  It may also be the case that it's more convenient to just return the tree and figure out its rank afterwards.
Sure, thanks for the explanation. 

The two ranking approaches aren't necessarily orthogonal.  Again, take the example of ranking parses of English sentences.  You might be able to craft a strategy where you use "rule" ranking to get an approximation, and only generate (for example) the top 6 parses.  These you subject to a more expensive ranking algorithm and the winner of the second ranking becomes the parse.
Well, yes. 

What I was trying to say by "orthogonal" is that the application can't see the ranks set in the grammar and the grammar can't see the ranks set by the application (well it can, if they are put in the scratch pad (action sub's first arg) but doesn't and doesn't need to). 

This feels like the right thing, but coming from Perl culture (TIMTOWTDI), I can't help thinking that in general the semantic actions might need to know (and perhaps to even modify) the rule's ranks set in the grammar. I can't come up with a proper use case at the moment though.

Thanks a lot for the great clarifications!
Reply all
Reply to author
Forward
0 new messages