Various fixes related to the variable free wikitables world #1917
Conversation
| # (batch_size, num_entities, num_neighbors) or None | ||
| neighbor_indices = self._get_neighbor_indices(world, num_entities, encoded_table) | ||
|
|
||
| if neighbor_indices is not None: |
There was a problem hiding this comment.
This part is new. It's possible that none of the instances in a given batch have entities with neighbors, because of the way the knowledge graph is defined.
|
@matt-gardner Based on our offline conversation about separating research code into a separate repo, I'm removed several changes from this PR to the other repo. I kept all the changes I made to the files already in the |
| # specified. We want to do this only when the table has a date column. This is because | ||
| # the knowledge graph is also constructed in such a way that -1 is an entity with date | ||
| # columns as the neighbors only if any date columns exist in the table. | ||
| self._map_name(f"num:-1", keep_mapping=True) |
There was a problem hiding this comment.
I think we may want to handle the -1 in dates separately from the typical "number" entity mechanism here - maybe have it be a global action, not a linked action at all. But we can worry about that later.
78b64dd to
c430f4f
Compare
@matt-gardner This is now ready to review. Other than adding a dataset reader, and (mostly) copying the original MML model to make a variable free variant, the changes are:
filter_date_greaterare not valid).MultiMatchNamedBasicTypewithin aComplexTypeto get productions that lead to it, only those that are in the table are allowed (For example, productions likes -> [<r,<g,s>> r, f]are not allowed if the table does not have number columns (f)).TableQuestionContextto return aKnowledgeGraph.