Closed mlesnick closed 7 years ago
Yes, looks like there are assumptions that the matrix contains at least 1 row and 1 column:
frame #9: 0x000000010018b8d9 rivet_console`MultiBetti::compute(this=0x00007fff5fbfc2b0, hom_dims=0x0000000100b03440, progress=0x00007fff5fbfd700) at multi_betti.cpp:105
102 MapMatrix* bdry2m = new MapMatrix(bdry2->height(), bdry2->width()); //partially-reduced copy of bdry2, to be "spliced" with merge matrix later
103
104 //reduce bdry2 at (0,0) and record rank
-> 105 reduce(bdry2, 0, ind2->get(0, 0), lows_bdry2, nonzero_cols_b2_y0);
106 nonzero_cols_bdry2 = nonzero_cols_b2_y0;
107 xi[0][0][1] += nonzero_cols_bdry2; //adding rank(bdry2_D)
108 hom_dims[0][0] -= nonzero_cols_bdry2; //subtracting rank(bdry2) at (0,0)
For the incomparable one, the probem is different:
frame #8: 0x000000010019dae7 rivet_console`SimplexTree::write_boundary_column(this=0x0000000100b03d30, mat=0x0000000100b04130, sim=0x0000000100b03af0, col=0, offset=0) at simplex_tree.cpp:384
381 //look up dimension index of the facet
382 STNode* facet_node = find_simplex(facet);
383 if (facet_node == NULL)
-> 384 throw std::runtime_error("SimplexTree::write_boundary_column(): Facet simplex not found.");
385 int facet_di = facet_node->dim_index();
386
387 //for this boundary simplex, enter "1" in the appropriate cell in the matrix
For x or y, one edge:
frame #10: 0x000000010019db6e rivet_console`SimplexTree::write_boundary_column(this=0x0000000100c01610, mat=0x0000000100c02490, sim=0x0000000100c01670, col=0, offset=0) at simplex_tree.cpp:388
385 int facet_di = facet_node->dim_index();
386
387 //for this boundary simplex, enter "1" in the appropriate cell in the matrix
-> 388 mat->set(facet_di + offset, col);
389 }
390 } //end write_col();
391
For the x axis one:
frame #6: 0x000000010018d1b6 rivet_console`MultiBetti::compute(this=0x00007fff5fbfc2a0, hom_dims=0x0000000100d02420, progress=0x00007fff5fbfd6f0) at multi_betti.cpp:215
212 //reduce bdry2 and split at (0,0) and record dimension of U
213 reduce_spliced(bdry2s, split, ind2s, ind1, zero_list_bdry1, 0, 0, lows_b2split, nonzero_cols_b2split);
214 if (num_x_grades > 1) {
-> 215 xi[1][1][1] -= nonzero_cols_b2split; //subtracting dim(U)
216 }
217
218 //CALCULATIONS AT GRADES (0,y) FOR y > 0
Thanks, Bryn, for helping to narrow these down. It looks like these are cases where RIVET is failing to handle degenerate data, similar to the previous issue Mike mentioned. I am happy to fix these bugs (unless you are already working on them, Bryn). It seems that these bugs are in code that I wrote.
Hi Matthew, I made some simple fixes in pull request #91 but the issue with the incomparable one and the ones with x|y one edge seem a little trickier. If you could assist with that part (you can just add additional commits to #91 if you like - it's the "issue-90" branch in my fork), that would be a big help.
Thanks, Bryn. I'll work on this.
I just edited SimplexTree to prevent the crashes that were occurring in _bifiltration_two_vertices_incomparable_oneedge.txt and _bifiltration_two_vertices_xaxis.txt. The SimplexTree was expecting the vertices of the bifiltration to be indexed by consecutive integers starting from 0, though this was not intentional (and not in the documentation). The SimplexTree should now work properly when vertex indexes don't start from 0 or are not consecutive.
I pushed the fix described above to pull request #91.
I haven't yet determined what is causing the errors that occur from the "one edge" data sets, but I'll keep working on it.
I just fixed the remaining crash identified in this issue; the fix appears in commit 18df6ec6e3a2406af99a39e388ba34eb926782ea to pull request #91.
I think that RIVET is now computing the augmented arrangement correctly for all five data files that Mike created. However, I now notice that the RIVET visualizer isn't drawing the infinite bars correctly on the examples that have only one grade in the x- or y-direction. This should be an easy fix, and I would like to fix it before merging this pull request.
I fixed the infinite bar display error in commit 7e2fc7f42d7f42c237e9c1bdc1e5c3f055d7c474. I think pull request #91 can be merged now.
I tested all of the files with this fix, via the visualizer. The computations all completed. There is still some buggy behavior in the visualizer for these kinds of examples (and this has been recorded in issue #89). But the core issues with the back end seem to have been resolved.
RIVET crashes on ALL of the attached bifiltrations (H0), which have at most two vertices. Recently, Bryn fixed a bug where RIVET didn't handle single x-coordinates. I wonder if this is related/similar to that earlier bug.
bifiltration_empty.txt bifiltration_two_vertices_incomparable_one_edge.txt bifiltration_two_vertices_one_edge_x_axis.txt bifiltration_two_vertices_one_edge_y_axis.txt bifiltration_two_vertices_x_axis.txt