rivettda / rivet Goto Github PK

Originally reported by: M L (GitHub: mlesnick)

xi_0 and x_1 both non-trivial, the pop-ups only give xi_1. They should give both.

Originally reported by: M L (GitHub: mlesnick)

Self explanatory.

Originally reported by: M L (GitHub: mlesnick)

In Roy's new BRips code, the scale parameter is the x-coordinate, but in Matthew's 2-D Rips code (as well as Roy's new version of it) the scale parameter is the y-coordinate. For consistency with the RIVET paper and with Matthew's code, I suggest that in Roy's BRips code, the scale parameter be the y-coordinate.

Originally reported by: M L (GitHub: mlesnick)

Kevin_Recomb.txt
5x5 bins.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Originally reported by: Matthew Wright (GitHub: mlwright84)

Add functionality for computing \xi_2

Originally reported by: M L (GitHub: mlesnick)

When I click close, it warns that all data will be lost.
It should say soemething like "all unsaved data will be lost."

Alternatively, RIVET could automatically write the file after completing, and this dialogue could be eliminated altogether.

Originally reported by: M L (GitHub: mlesnick)

Since getting the Betti number and dimension data is way cheaper than computing the full augmented arrangement, but already very interesting, it'd be nice to have a way of saving just this information, or of asking the software to only give just this info.

Originally reported by: M L (GitHub: mlesnick)

This a very small issue, but one that affects usability of the input dialogue:
When I click on the box to change the number of bins in the input dialogue, the text
"no bins" does not highlight. I have to delete that manually and then enter in the text.

It would be better if, like the address bar of the web browser, the text automatically was highlighted when I clicked on it.

Originally reported by: Matthew Wright (GitHub: mlwright84)

ML 5/25/15 OS X: Strange behavior when size of dot is updated: size doesn't immediately refresh, and old dots do not disappear.

Originally reported by: M L (GitHub: mlesnick)

I am running RIVET with point cloud data in 198 dimensions, with 498 points and 3 digits of precision. Building the distance matrix is noticeably slow.

Perhaps we should be using floating point arithmetic to compute the distance matrix, and then rounding to exact arithmetic after?

Originally reported by: Matthew Wright (GitHub: mlwright84)

Develop a dynamic algorithm that chooses a smart threshold for the expected number of swaps that triggers a "reset" of the boundary matrices instead of doing vineyard updates.

Originally reported by: M L (GitHub: mlesnick)

The error appears at 52:00 in this video:
https://www.youtube.com/watch?v=2eYVPaajzt4

The data set is the 240 points with 30x30 bins. I was not able to replicate this error.

Originally reported by: Matthew Wright (GitHub: mlwright84)

• Implement seeded arrangement search
• Implement log n time arrangement search (or use standard code for this?)

Originally reported by: Matthew Wright (GitHub: mlwright84)

Sometimes progress box doesn't close when computation finishes. MW has investigated this and isn't sure why the close() function doesn't always work.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Implement error-checking of input files so that program fails gracefully, rather than crashes, if an input file is not in the correct format.

Originally reported by: M L (GitHub: mlesnick)

When working with coarse filtrations, dots can be obscenely large for Betti numbers or persistence diagrams, when the multiplicity of a feature is too large.

There should the default size of a dot should be computed as a function of the coarseness of the bins, so that in the case of maximally large dots, overlap of neighboring dots is not too extensive. On the other hand, the minimum size of a dot should also not be too small. Perhaps this latter constraint takes precedence, if both cannot be achieved.

Originally reported by: Matthew Wright (Bitbucket: mlwright84, GitHub: mlwright84)

ML, 5/25/15 OS X, data: Kevin_Recomb, 5x5 bins, 1st homology: Runtime errors: Slice line disappears or is in wrong place, persistence diagram not shown, other bizarre behavior.
Comments (5/26/15): Kevin_Recomb has small distance entries (most between between 10^{-5} and 10^{-3}), and time entries orders of magnitude larger. Rescaling the time entries to be smaller helped correct some of the problems, but not others. Scaling the distance entries to be larger, on the other hand, as in file Kevin_Recom_Times_100, mostly fixed the strange behavior. However I still observe slightly rocky behavior of the updates as I drag the line. For drags which do not change slope, it seems the barcode and persistence diagram are only updated when the cell changes.

• Bitbucket: https://bitbucket.org/mlwright84/persistence-program/issue/1

Originally reported by: M L (GitHub: mlesnick)

Our workflow related to labeling the two axes could probably be better organized.

As of now, the current workflow takes the labels to be arguments to the function for computing augmented arrangements. However, this seems the least optimal time to enter the label information.

It seems there are two times when makes most sense to to specify/change the labels:

1)When I create the RIVET input file:
[By the time I create the RIVET input file, I know what kind of process I used to create the data. Thus, it might be appropriate to include that label data in the file from the start. Having the label might improve readability of the file.]

2)After the augmented arrangement computation is done.
[Perhaps I have misspelled the label, or I might want a clearer/shorter label. I shouldn't have to do the computation again to fix this.]

Right now, we can't specify the label at either of these points, but only at the intermediate step. So here's one proposed solution. Perhaps too complicated, but it's one idea.

1. A label can be specified in the input file to augmented arrangement computation. If so, that label is written to the augmented arrangement file after computation. (If the input file is a 'metric' file, one of the labels is automatically set to "distance.")

2. Labels can also be specified as an argument to the visualization function. These override the labels in the augmented arrangement file, possibly with a warning.

3. I would propose that labels not be allowed as arguments to the function for computing augmented arrangements.

4. We may want to provide some default label behavior (e.g. which no label is provided for a bifiltration, the label is "filter 1."

A simpler option is to ONLY allow labels to be given as input to the visualizer. That seems less convenient but OTH it is simple and easier to explain in documentation.

Originally reported by: M L (GitHub: mlesnick)

We should be able to input optional arguments, either through the command line, or through the GUI, to manually choose the bounds for the viewable region.

the automatic method Matthew has implemented works quite well for single filtrations. However, in some cases, we need to compare results across multiple filtrations, and for this a uniform choice of viewable region is required. The current implementation does not support this.

Originally reported by: Matthew Wright (GitHub: mlwright84)

ML, 6/1/15: I would like to be able to hover over or click on a betti_i dot and get an explicit count of the number of features there. Without that, I find the current scheme a little hard to interpret. Alternatively, maybe part of the visualization could include a legend, which draws sample dots and the size to which they correspond?

Originally reported by: Matthew Wright (GitHub: mlwright84)

• Implement edge-weighting algorithm
• From the minimal spanning tree, choose a path that minimizes backgracking
• Christofides' 3/2 approximation for the path through the dual graph.

Originally reported by: Matthew Wright (GitHub: mlwright84)

ML 5/25/15 OS X: If we select a file, open the select file dialogue box, and hit cancel, the name of the first file selected continues to appear, as it should, but the software crashes upon hitting "compute".

Originally reported by: M L (GitHub: mlesnick)

When slice line is moved, we see remnants of old slice lines.
Doesn't affect usability, just a presentation issue.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Improve the save/load feature so that it can save the arrangement (not just the anchors).

Originally reported by: M L (GitHub: mlesnick)

This may be related to the issue Matthew mentioned with vertical lines, but I note that the behavior is also wrong for diagonal lines in this example, from the avian data:

Note that the interval whose top just touches the horizontal line labelled "20" is not consistent with the Betti numbers shown.

Originally reported by: M L (GitHub: mlesnick)

For every column operation performed on R in the initial computation of the RU-decomposition, the corresponding entry of U should be entered into the matrix constant time.

Is the code in fact doing these constant time updates? Whether the update is in fact being done in constant time depends on the details of how the row additions in the code are being performed.

todo: look into this and make the fix, if necessary.

Originally reported by: M L (GitHub: mlesnick)

The button is still functions, but it looks like it is not.

Originally reported by: Matthew Wright (GitHub: mlwright84)

ML 6/1 OSX: Sometimes when I load a file, the file name doesn't display properly.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Output computation time and other statistics for the user.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Allow user to hide dots within some specified distance of the diagonal.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Improved data structures for Betti number computation -- Matthew has an incomplete optimization from November/December 2014 that is not yet incorporated into RIVET

Originally reported by: M L (GitHub: mlesnick)

Right now, the file name is shown in the persistence diagram window only after the barcode template computation is complete.

I have found this to cause confusion: I sometimes find myself launching multiple RIVET computations at once. The Betti number computations finish quickly and are already informative, but I can't distinguish the two data sets from one another until the whole computation is finished, because the file name is not shown.

This is related to Issue 52.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Input should be less sensitive to line breaks. For example, the "distance matrix" file format should specify the number of points, then not require line breaks so that the distance matrix can be specified as a vector.

Originally reported by: M L (GitHub: mlesnick)

A few months ago, I shared some of Chris Baldassano's neuro data with Matthew, to ask him to do a 0-D persistence computation for me.

Now that I have my new Linux machine, I decided to try the 1-D version of this computation.
It ran quickly (15x15 bins) but did not display properly. Matthew explained that this was because I didn't include labels in my input file. (The old format did not require labels, but we updated the input format in the last few months).

However, now I have fixed that issue with the input, and I am still getting roughly the same problem (now using 25x25 bins). See attached file and screenshot. Note that no upper bound for x coordinate is displayed. I would guess that this is related.

Originally reported by: M L (GitHub: mlesnick)

Right now, RIVET can accept arbitrary one-critical bifiltrations as input.

In the future, it would be good if we could handle:

-Arbitrary FI-reps

-As a special case, arbitrary presentations.

This has been addressed in Roy Zhao's fork of RIVET, but not yet merged into main.

Originally reported by: M L (GitHub: mlesnick)

One could argue that this extra freedom is user friendly. But it is not consistent with the description in the paper, and I find the way the barcode changes to be a little funny, and not consistent with our general visualization approach.

What exactly do we want here?

Should we have the bottom endpoint snap to the origin in this case? This seems more principled, though perhaps slightly more awkward from an interactivity perspective.

Originally reported by: M L (GitHub: mlesnick)

This seems like a useful error check, since apparently RIVET sometimes can run when the axis labels are omitted, giving strange results.

Originally reported by: Matthew Wright (GitHub: mlwright84)

ML 5/26/15 OS X: Sometimes line is not responsive to click and drag (doesn't highlight, doesn't move.)

Originally reported by: M L (GitHub: mlesnick)

This happens when browsing vertical lines, and seems to go hand in hand with the horizontal line reset bug (issue # 4).

Marking as major, since anything involving incorrect output that looks correct is trouble.

Added later: The numbers above the dashed horizontal line (corresponding to bars which live forever) also apparently do not update properly. Namely, a single dot marked with multiplicity 2 is converted to a +1, not +2.

Originally reported by: M L (GitHub: mlesnick)

-When the file selection dialogue box is closed, a blank RIVET window appears.

-When a RIVET computation in progress is stopped before Betti numbers are computed, a blank window remains open.

I suggest that the RIVET window be opened only after the Betti numbers are computed.

Originally reported by: M L (GitHub: mlesnick)

A relatively easy enhancement that will significantly extend the reach of RIVET.

Originally reported by: Matthew Wright (GitHub: mlwright84)

Improve efficiency of barcode recovery from RU decomposition.

Originally reported by: Matthew Wright (GitHub: mlwright84)

• ML 5/26/15 OS X: Can't scroll a vertical (also horizontal?) bar all the way to the last value of parameter. (So for example in a codensity-distance filtration, can't view the ordinary 1-D persistence case where all the points are included, unless I tilt the line slightly).

Originally reported by: M L (GitHub: mlesnick)

For points in the upper strips of the persistence diagram, the multiplicity of an interval is not always properly represented by the size of the dot. Instead, since the dots are translucent, the multiplicity is represented by the shading of the dot. (This is not what we want).

We need to merge dots in the upper strip that correspond to the same coordinate. For a generic query line, all such dots correspond to template points that have the same first coordinate, so this shouldn't be very hard.
Mike

Originally reported by: Matthew Wright (GitHub: mlwright84)

ML 6/1: When the vertical line is pushed all the way to the right, and i drag the top endpoint to the right, the endpoint becomes detatched from the line. In combination with the bug above, this makes it impossible to directly compare RIVET to the 1-D pipeline without showing a bug.

Originally reported by: M L (GitHub: mlesnick)

Originally reported by: M L (GitHub: mlesnick)

When the maximum dimension of a vector space is large, it is impossible to distinguish between what is trivial and what is non-trivial homology.

The proposed solution is to have a minimum darkness for regions of non-zero homology, and then have the darkness scale up linearly from there. That means there will be some maximum value of homology above which everything is maximally dark (black?).

But that is better than not being able to tell the difference between 0 and 1.

Originally reported by: Matthew Wright (GitHub: mlwright84)

ML 6/1 OSX: I am allowed to resize the file load window, but this doesn't do anything except add grey space.

Originally reported by: M L (GitHub: mlesnick)

To change the Betti number tool tip display, one has to click away from the displayed box and then hover over a point again. It'd be better to have a system which doesn't involve any clicking to update the tool tip.