Output of irPassDimensionalMatrixKernelPrinter since 4c25ee031ed43b96b4dfe64a42544c3692e0c401

[phillipstanleymarbell]

Describe the bug
The outputs of the irPassDimensionalMatrixKernelPrinter no longer make sense since the batch of commits between fc642c8 and 4c25ee0.

To Reproduce
Steps to reproduce the behavior, follow any of the following links which are to the CGI version that incorporates the recent changes (Newton version 0.2-alpha-679 (cb48118) (build 01-02-2019-14:[email protected]_64)):

• ActivityClassifier.nt

• Beam-pigroups.nt

• BeamAlternative-pigroups.nt

• BuckinghamExampleOne-pigroups.nt

• CableHydrodynamicDragForce-pigroups.nt

Expected behavior
Since the current CGI version activates the following passes

	irPassDimensionalMatrixAnnotation(newtonCgiState);
	irPassDimensionalMatrixPiGroups(newtonCgiState);
	irPassDimensionalMatrixKernelRowCanonicalization(newtonCgiState);
	irPassDimensionalMatrixPiGroupSorted(newtonCgiState);
	irPassDimensionalMatrixPiGroupsWeedOutDuplicates(newtonCgiState);
	irPassDimensionalMatrixConvertToList(newtonCgiState);
	irPassDimensionalMatrixPrinter(newtonCgiState);
	irPassDimensionalMatrixKernelPrinter(newtonCgiState);

the expected behavior is a canonical form of Pis (i.e., either 'a/b' or 'b/a', but not both).

Screenshots
For ActivityClassifier.nt:

Desktop (please complete the following information):
N/A.

Smartphone (please complete the following information):
N/A.

Additional context
N/A.

[Siegfriedchao]

Root cause: the printer IRs have not yet been updated to reflect the changes of the reordered kernels. Will update the newton-irPass-dimensionalMatrixPiGroupWeedOut to restore the nullspaces for printer IRs to use.

Quote from the Slack channel discussion: Youchao: Currently saving nullSpace, nullSpaceRowReordered, nullSpaceCanonicallyReordered and nullSpaceWithouDuplicates, so that they might be of use in the future. Phillip: The print routines should take the null space as a parameter, then can reuse

[Siegfriedchao]

This is solved in #388 bundle updates.

[phillipstanleymarbell]

Moving this to verify as the comments above imply this is fixed in #388.