Lack of symmetry: Exchanging x and y in bifiltration leads to nonsensical result.
nihell opened this issue · comments
Hi there,
I have experienced this issue some times now, exchanging x and y does not lead to symmetric results.
In particular, --yreverse seems to work fine, whereas --xreverse seems to lead to problems.
Here's a minimal working counterexample.
--datatype bifiltration
--xlabel distance
--ylabel m
--yreverse
3 ; 0 1 3.16228 2
2 ; 0 1 4 2
2 3 ; 4.12311 1 4.12311 2
1 ; 0 1 3 2
1 2 ; 4 1 4.12311 2
1 3 ; 3.16228 1 3.16228 2
0 ; 0 1 3 2
0 1 ; 3 1 3 2
0 2 ; 4 1 4 2
0 3 ; 3.16228 1 4.12311 2
Running rivet_console test_yreverse.txt --betti -H 1 -x 10 -y 2
yields the correct result:
x-grades
0
3
79057/25000
4
412311/100000
y-grades
-2
-1
Dimensions > 0:
(2, 1, 1)
(3, 1, 2)
(4, 0, 3)
(4, 1, 3)
Betti numbers:
xi_0:
(2, 1, 1)
(3, 1, 1)
(4, 0, 3)
xi_1:
(4, 1, 2)
xi_2:
Now with x and y exchanged:
--datatype bifiltration
--ylabel distance
--xlabel m
--xreverse
3 ; 1 0 2 3.16228
2 ; 1 0 2 4
2 3 ; 1 4.12311 2 4.12311
1 ; 1 0 2 3
1 2 ; 1 4 2 4.12311
1 3 ; 1 3.16228 2 3.16228
0 ; 1 0 2 3
0 1 ; 1 3 2 3
0 2 ; 1 4 2 4
0 3 ; 1 3.16228 2 4.12311
Running rivet_console test_xreverse.txt --betti -H 1 -x 2 -y 10
yields the very much wrong result (notice the hilbert function appears to have values > 4 billion)
x-grades
-2
-1
y-grades
0
3
79057/25000
4
412311/100000
Dimensions > 0:
(0, 1, 4294967295)
(0, 2, 4294967294)
(0, 3, 4294967293)
(0, 4, 4294967295)
(1, 2, 1)
(1, 3, 2)
(1, 4, 3)
Betti numbers:
xi_0:
(0, 4, 2)
(1, 1, 1)
(1, 2, 2)
(1, 3, 2)
(1, 4, 1)
xi_1:
(1, 4, 2)
xi_2:
What am I missing here?
Cheers,
Niklas
Hi Niklas,
I have looked into this. Here are some notes on this, both for you and for myself.
This is indeed a bug. In spite of appearances, it has nothing to do with the --xreverse and --yreverse functionality.
Your input file specifies the bifiltration non-minimally; you are allowing a simplex to appear at multiple bigrades, but those bigrades are not always incomparable. According to the documentation, RIVET is supposed to be able to correctly handle such input, but your example shows that it doesn't. One sees the same incorrect behavior if one gets rid of the --xreverse flag and replaces all of the x-coordinates by their negative.
As you say, the behavior of RIVET on such examples is asymmetric with respect to switching the x- and y- coordinates.
Using the -V 10 flag (for verbose console output), I see that in the -xreverse example RIVET is incorrectly computing the column bigrades of the higher boundary matrix. The bigrades it is getting wrong correspond to relations between different births of the same simplex. They are joins of pairs of bigrades. RIVET is miscomputing these joins.
We'll try to fix this soon, but in the meantime, presumably you can work around this by feeding RIVET a minimal bifiltration.
A couple of other remarks:
-The bug aside, whereas the documentation says that RIVET ignores the non-minimal bigrades, it in fact does not (in either the --xreverse or --yreverse instance). Rather it treats each non-minimal bigrade as an extra generator. That is not terrible behavior, but the documentation should be consistent with the code.
-In your example, all the non-minimal bigrades of a simplex share a coordinate with the minimal bigrade. I don't know whether this is related to the bug.
RIVET in fact has some code to remove these kinds of non-minimalities, but it was not being used here. I've fixed this now.
I see. Thanks so much!
I'll close the issue now, but please let us know if there are any issues with the fix.