Why Is This Ambiguity Here

Why is this ambiguity here?

It's actually quite straight forward. For t[1], overload resolution has these candidates:

Candidate 1 (builtin: 13.6/13) (T being some arbitrary object type):

• Parameter list: (T*, ptrdiff_t)

Candidate 2 (your operator)

• Parameter list: (TData<float[100][100]>&, something unsigned)

The argument list is given by 13.3.1.2/6:

The set of candidate functions for overload resolution is the union of the member candidates, the non-member candidates, and the built-in candidates. The argument list contains all of the operands of the operator.

• Argument list: (TData<float[100][100]>, int)

You see that the first argument matches the first parameter of Candidate 2 exactly. But it needs a user defined conversion for the first parameter of Candidate 1. So for the first parameter, the second candidate wins.

You also see that the outcome of the second position depends. Let's make some assumptions and see what we get:

1. ptrdiff_t is int: The first candidate wins, because it has an exact match, while the second candidate requires an integral conversion.
2. ptrdiff_t is long: Neither candidate wins, because both require an integral conversion.

Now, 13.3.3/1 says

Let ICSi(F) denote the implicit conversion sequence that converts the i-th argument in the list to the type of the i-th parameter of viable function F.

A viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then ... for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that ...

For our first assumption, we don't get an overall winner, because Candidate 2 wins for the first parameter, and Candidate 1 wins for the second parameter. I call it the criss-cross. For our second assumption, the Candidate 2 wins overall, because neither parameter had a worse conversion, but the first parameter had a better conversion.

For the first assumption, it does not matter that the integral conversion (int to unsigned) in the second parameter is less of an evil than the user defined conversion of the other candidate in the first parameter. In the criss-cross, rules are crude.

---

That last point might still confuse you, because of all the fuss around, so let's make an example

void f(int, int) { }
void f(long, char) { }

int main() { f(0, 'a'); }

This gives you the same confusing GCC warning (which, I remember, was actually confusing the hell out of me when I first received it some years ago), because 0 converts to long worse than 'a' to int - yet you get an ambiguity, because you are in a criss-cross situation.

why is this a ambiguous grammar?

No, this is not a correct demonstration of ambiguity.

Your understanding of point #2 is flawed. A grammar G is ambiguous iff some w in L(G) has more than one leftmost (or rightmost) derivation. You've shown one leftmost derivation for w=bbaa, so if you could show another (i.e., a different leftmost derivation for the same string), that would demonstrate ambiguity. However, there doesn't appear to be one, so you'll have to pick a different string.

Note that this has nothing to do with whether a derivation involves the application of recursive/reflexive productions.

Could someone help me understand the ambiguity here in Postgres?

The problem is that you have a function variable "Size" (an OUT parameter defined in the RETURNS TABLE clause) and a column "Size" in "Users"."SupplyItem". So you have to qualify the reference to indicate what you mean.

I recommend using an alias for simplicity:

UPDATE "Users"."SupplyItem" AS si
   SET "Size" = COALESCE("vSize" , si."Size")
...

There is no such ambiguity in your first example, because you didn't double quote the parameter TaxPercent, so it gets case folded to taxpercent and is different from the column "TaxPercent".

function ambiguity in java

both method can take the first parameters you've entered f(1,2); and that's why you get ambiguity.
if you'll do

f((float)1,2);

you won't get the error for example

How to parse this simple grammar? Is it ambiguous?

For starters, I’m glad you’re finding our CFG tool useful! A few of my TAs made that a while back and we’ve gotten a lot of mileage out of it.

Your grammar is indeed ambiguous. This stems from your R nonterminal:

R → b | RbR

Generally speaking, if you have recursive production rules with two copies of the same nonterminal in it, it will lead to ambiguities because there will be multiple options for how to apply the rule twice. For example, in this case, you can derive bbbbb by first expanding R to RbR, then either

1. expanding the left R to RbR and converting each R to a b, or
2. expanding the right R to RbR and converting each R to a b.

Because this grammar is ambiguous, it isn’t going to be LL(k) for any choice of k because all LL(k) grammars must be unambiguous. That means that stepping up the power of your parser won’t help here. You’ll need to rewrite the grammar to not be ambiguous.

The nonterminal R that you’ve described here generates strings of odd numbers of b’s in them, so we could try redesigning R to achieve this more directly. An initial try might be something like this:

R → b | bbR

This, unfortunately, isn’t LL(1), since after seeing a single b it’s unclear whether you’re supposed to apply the first production rule or the second. However, it is LL(2).

If you’d like an LL(1) grammar, you could do something like this:

R → bX

X → bbX | ε

This works by laying down a single b, then laying down as many optional pairs of b’s as you’d like.

---

Related Topics