search

rivetTDA / rivet

RIVET is a tool for Topological Data Analysis, in particular two-parameter persistent homology.
GNU General Public License v3.0
73 stars 24 forks source link

Improved handling of Labels #46

Closed mlesnick closed 7 years ago

mlesnick commented 8 years ago

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.

mlesnick commented 8 years ago

Original comment by Matthew Wright (GitHub: mlwright84):

Labels are now specified in the input files, and they may also be changed in the visualizer via the Configure... dialog box.

mlesnick commented 8 years ago

Original comment by Matthew Wright (GitHub: mlwright84):

I am inclined to require that the user specify labels in the input file, and then to allow the user to change the labels in the visualization.

Specifying the labels in the input file seems natural, as Mike pointed out above. Requiring labels in the input file (rather than making them optional) makes it easier to write the input routine, since the input routine doesn't have to detect whether or not the labels are in the file.

Implementing these improvements will involve some changes to the input routines and documentation, but I think now is the right time to make these changes, before the public software release. I would rather not change input file specifications after release, since doing so would make it hard to maintain backward-compatibility with input files that users may have created by that time.