Defactoring algorithms: Difference between revisions

Line 801:

===Null-space'n'back defactoring===

It's fairly self-explanatory: '''Null-space'n'back defactoring''' is a defactoring algorithm that works by finding a basis for the null-space of a mapping, and then finding a basis for the anti-null-space of that result, which brings one back to a mapping. ~~Unfortunately this does not~~ work ~~all of the time~~<ref>~~Although it~~ is ~~supposedly~~ proven ~~otherwise~~ in this other paper by Pernet, where the terms "right kernel basis" and "left kernel basis" are used instead: https://hal.archives-ouvertes.fr/hal-01829139 ~~This may be due~~ to ~~implementation details~~ of Wolfram Language, ~~or some~~ other ~~constraint~~ that ~~we do~~ not ~~yet understand~~. Pernet has yet to weigh in but has been contacted about this by email.</ref>. For example, {{ket|{{map|7 11 16}} {{map|22 35 51}}}} has a null-space basis of {{bra|{{vector|1 -5 3}}}}, and when we take the anti-null-space of that, we get {{ket|{{map|3 0 -1}} {{map|0 3 5}}}} which is a classic case of hidden enfactoring as described above.

It's fairly self-explanatory: '''Null-space'n'back defactoring''' is a defactoring algorithm that works by finding a basis for the null-space of a mapping, and then finding a basis for the anti-null-space of that result, which brings one back to a mapping. Depending on the implementation of your math library, null-space'n'back defactoring ''may'' work<ref>It is proven to work in this other paper by Pernet, where the terms "right kernel basis" and "left kernel basis" are used instead: https://hal.archives-ouvertes.fr/hal-01829139, however, no one involved in the xenharmonic project as of yet has invested the time and effort necessary to understand and confirm this proof. Pernet uses (and indeed has contributed in major part to) the Sage math library, where null-space'n'back ''does'' work, but it seems likely to work only because their code explicitly defactors matrices whenever taking the (anti-)null-space, per our appraisal of their source code! Wolfram Language, on the other hand, which our RTT library uses, does not do this. Sintel has recommended that it does not make sense to return enfactored null-space or anti-null-space bases and that this therefore constitutes a bug in Wolfram Language; they have been subsequently contacted about the issue. Pernet himself has yet to weigh in but has been contacted about this by email.</ref>. For example, {{ket|{{map|7 11 16}} {{map|22 35 51}}}} has a null-space basis of {{bra|{{vector|1 -5 3}}}}, and when we take the anti-null-space of that with Wolfram Language, we get {{ket|{{map|3 0 -1}} {{map|0 3 5}}}} which is a classic case of hidden enfactoring as described above, so it does not work in this case.

===Sum-and-difference defactoring===

@@ Line 801: / Line 801: @@
 ===Null-space'n'back defactoring===
-It's fairly self-explanatory: '''Null-space'n'back defactoring''' is a defactoring algorithm that works by finding a basis for the null-space of a mapping, and then finding a basis for the anti-null-space of that result, which brings one back to a mapping. Unfortunately this does not work all of the time<ref>Although it is supposedly proven otherwise in this other paper by Pernet, where the terms "right kernel basis" and "left kernel basis" are used instead: https://hal.archives-ouvertes.fr/hal-01829139 This may be due to implementation details of Wolfram Language, or some other constraint that we do not yet understand. Pernet has yet to weigh in but has been contacted about this by email.</ref>. For example, {{ket|{{map|7 11 16}} {{map|22 35 51}}}} has a null-space basis of {{bra|{{vector|1 -5 3}}}}, and when we take the anti-null-space of that, we get {{ket|{{map|3 0 -1}} {{map|0 3 5}}}} which is a classic case of hidden enfactoring as described above.
+It's fairly self-explanatory: '''Null-space'n'back defactoring''' is a defactoring algorithm that works by finding a basis for the null-space of a mapping, and then finding a basis for the anti-null-space of that result, which brings one back to a mapping. Depending on the implementation of your math library, null-space'n'back defactoring ''may'' work<ref>It is proven to work in this other paper by Pernet, where the terms "right kernel basis" and "left kernel basis" are used instead: https://hal.archives-ouvertes.fr/hal-01829139, however, no one involved in the xenharmonic project as of yet has invested the time and effort necessary to understand and confirm this proof. Pernet uses (and indeed has contributed in major part to) the Sage math library, where null-space'n'back ''does'' work, but it seems likely to work only because their code explicitly defactors matrices whenever taking the (anti-)null-space, per our appraisal of their source code! Wolfram Language, on the other hand, which our RTT library uses, does not do this. Sintel has recommended that it does not make sense to return enfactored null-space or anti-null-space bases and that this therefore constitutes a bug in Wolfram Language; they have been subsequently contacted about the issue. Pernet himself has yet to weigh in but has been contacted about this by email.</ref>. For example, {{ket|{{map|7 11 16}} {{map|22 35 51}}}} has a null-space basis of {{bra|{{vector|1 -5 3}}}}, and when we take the anti-null-space of that with Wolfram Language, we get {{ket|{{map|3 0 -1}} {{map|0 3 5}}}} which is a classic case of hidden enfactoring as described above, so it does not work in this case.
 ===Sum-and-difference defactoring===