Fix distances reader

[reds-heig]

Dear Ulrich,

Playing with ripser using datasets where data was pruned using in my case collapser, I encountered an unexpected behaviour when reading distance matrices where inf values are present in the input file. std::istream or std::istringstream returns 0 instead of inf if they encounter INF, Inf, etc. in an input file when you try to directly assign the stream into a float or double variable.

Why are inf values in this distances matrices ? Because, when pruning data from the original distances matrices, I replace a pruned data by inf.

In attachment you'll find a distance matrix not pruned dense.txt. Its pruned version dense_pruned.txt and the lower and upper part of the dense_pruned.txt to test the lower and upper reader.

Command to test the different datasets:

./ripser --format distance --dim 2 dense.txt
./ripser --format distance --dim 2 dense_pruned.txt
./ripser --format lower --dim 2 lower_pruned.txt
./ripser --format upper --dim 2 upper_pruned.txt

The expected results is:

persistence intervals in dim 0:
 [0,0.8924)
 [0,0.9461)
 [0,0.9973)
 [0,1.0168)
 [0,1.0494)
 [0,1.0708)
 [0,1.0775)
 [0,1.0779)
 [0,1.1533)
 [0,1.2462)
 [0,1.2797)
 [0,1.2953)
 [0,1.3245)
 [0,1.3601)
 [0,1.3732)
 [0,1.3759)
 [0,1.3804)
 [0,1.3805)
 [0,1.3957)
 [0, )
persistence intervals in dim 1:
 [1.5254,1.5512)
 [1.5123,1.5498)
 [1.465,1.5809)
 [1.4599,1.4958)
 [1.4489,1.4493)
 [1.4368,1.5328)
 [1.4097,1.4682)
persistence intervals in dim 2:
 [1.6036,1.608)

Please, feel free to suggest any modifications or if you have any remarks.

Best,
Julián

[MonkeyBreaker]

dense.txt
dense_pruned.txt
lower_pruned.txt
upper_pruned.txt

Sorry forgot the files ...

[MonkeyBreaker]

commit 57fb1e0 fixes an issue I could not observe on my GCC version (7.5.0), but a colleague observed with his more recent GCC version (9.3.0).

In colleague case, the behavior observed was to loop indefinitely inside readers for distance type inputs.

The culprit found was -Ofast enables -ffast-math flag that disable standard behavior when using nan values and other expected behavior too, see gcc doc.

I updated to not rely on this kind of results and now the next_value_stream function returns true if it was able to read a value, false otherwise.