Ticket #31 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

prependToSubst: Eric broke unification. Prepending K-t-73 twice

Reported by: kowey Owned by: kowey
Priority: blocker Milestone: GenI 0.20
Component: core Version:
Keywords: Cc:

Description

Yikes!

geni: Bug in GenI! prependToSubst: Eric broke unification. Prepending K-t-73 twice

geni -m dist/build/grammar/valuation-sem.geni -l dist/build/lexicon/lemmas.glex -s suite/verbs --testcase=t110 --batchdir=/tmp/b

Change History

Changed 5 years ago by kowey

It seems to be t150 in the XMG-GenI integration demo

Changed 5 years ago by kowey

In the debugger, it happens at iteration 142 (or 141?)

Changed 5 years ago by kowey

  • milestone set to GenI 0.18

Changed 5 years ago by kowey

  • owner changed from somebody to kowey
  • status changed from new to assigned

I can confirm that GenI 0.17.4 makes it through this. So either this is a regression or something else has changed that reveals the error.

If I understand correctly, this bug means we're trying to register more than one substitution for a variable, which doesn't make sense because normally once you've registered a substitution that variable is gone. I think this means that we're basically just failing to propagate substitutions somewhere...

This makes me want a better abstraction over unification.

Changed 5 years ago by kowey

Cool! This may not be a unification bug after all, but a repeated adjunction. Why are we getting this?

Changed 5 years ago by kowey

  • status changed from assigned to closed
  • resolution set to fixed

Resolved by: Fri Sep 25 17:16:00 CEST 2009 Eric Kow <E.Y.Kow@…>

  • Fix #31 - unification bug cause by failure to propagate.

We do top and bottom unification after adjunction; however, the nodes that we were doing unification on did not have the latest substitutions from the adjunction test applied to them.

I'm still not sure why this is a regression from GenI 0.17, but that's a future question to research.

Note also that this bug would not have been caught without the pattern-matching style allowed by languages such as Haskell or one of the MLs. We simply would have silently accepted the anomalous situation and the user would have been none the wiser. I consider this a succesful application of the "Dead Programs Don't Lie" principle. So yay Haskell!

Note: See TracTickets for help on using tickets.