Fix multiple bin for float binsize bug.

[CWE0]

Assures that each float rng is computed only once and no comparison between two float rng is required.
In addition unused variables i,x are removed.

Addresses issue #46.

[iamlikeme]

The fix introduces a regression - test test_count_cycles_binsize is now failing (see output from Travis or run the tests locally).

Also, in order to merge this PR it must provide a new test case which demonstrates the bug you are fixing, i.e. the test should fail without your fix and should pass after the fix. The example in #46 is a good starting point for the new test.

[CWE0]

My last commit solves the regression and adds the required test case.

[iamlikeme]

I have slightly refactored/simplified the code.
I have also refactored unit tests so that the test case you contributed can be used in more tests.

[CWE0]

By using nmax and setdefault for all rng up to nmax floats have to be compared again.

…

Am 17.11.2020 um 23:09 schrieb Piotr Janiszewski ***@***.***>:  I have slightly refactored/simplified the code. I have also refactored unit tests so that the test case you contributed can be used in more tests. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[iamlikeme]

That is true, but we are talking about extremely cheap operations. Like, nanoseconds cheap. Take setdefault for example:

>>> d = {}
>>> %timeit d.setdefault(5, 0.0)
# 81.6 ns ± 0.362 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

So the performance hit of doing some extra iterations in lines 158-159 is negligible. And it is probably comparable to the cost of doing a set difference (line 157 before the refactor). But by swapping the ibin set to nmax we get simpler and more readable code which accomplishes the exact same thing.

[gsokoll]

There are many micro-optimisations you could do, eg drop the nmax comparison in line 156 (which is done for every point in the entire cycles list) and replace it with a search for max n in counts afterwards.

The benefit is still likely to be small, but since I have used the rainflow routine on many GB of data, all improvements are nice...

[iamlikeme]

Thank you for your contribution @CWE0

[iamlikeme]

@gsokoll, feel free to submit a pull request with performance optimizations.

[iamlikeme]

This PR is included in v3.0.1 on PyPI.