iterator_test.cpp fails

[jmeintrup]

iterator_test.cpp:44: FailureExpected equality of these values:
  count
    Which is: 1639
  setSize
    Which is: 5000

I have been getting that error from the iterator_test.
Did this test pass the travis build test?

[andrej-sajenko]

Yes the test passes on the travis build.

[andrej-sajenko]

Have you solved this issue?

[jmeintrup]

Yes, it seems to. It just worked after i tried it two more times.
The test uses some random generation, maybe that is the problem - even though it uses a fixed seed.

[shsr04]

Now also fails for me. #36

[dppl]

I'm going to look into it, however I'm not able to reproduce this behaviour locally.

Now also fails for me. #36

Does it make a difference if you comment out line 28 in choicedictionaryiterator_test.cpp?

[shsr04]

Does it make a difference if you comment out line 28 in choicedictionaryiterator_test.cpp?

Yes it does, but the test still fails. Now the actual value is 1624 instead of 3260.

Let's see if Travis accepts it.

[dppl]

@andrej-sajenko Should we maybe disable the test for the choice dictionary iterator, so that unrelated pull requests get accepted?
I'm going to look further into it to find the problem, as it doesn't seem to be related to shuffling the test set.

@shsr04 Does the test also fail locally?

[shsr04]

Yes, it's the same as the Travis build.

[shsr04]

Maybe the -O3 compiler flag introduced one month ago breaks the GCC built-in __builtin_clzl used in the iterator:

sea/src/choicedictionaryiterator.cpp

Line 38 in f4747b3

unsigned long int nextIndex = (unsigned long int)__builtin_clzl(primaryWord);

sea/src/choicedictionaryiterator.cpp

Line 61 in f4747b3

unsigned long int primaryInnerIndex = (unsigned long int)__builtin_clzl(secondaryWord);

[shsr04]

@dappels I have made several tries now. Whatever my approach for the CD iterator test is, it fails on Travis (but works locally)... Could this be a bug in the iterator itself? (some portability issue?)

[dppl]

I don't really know what causes the issue for you. As discussed previously it is not possible for me to reproduce that issue locally.
Is there any sign of the iterator returning incorrect values when you run it locally? Be it in an implementation that relies on it or the unit test?

[shsr04]

The Travis build on #68 failed when I uncommented the test. (Locally, everything works.)
I also made a few different random tests (e.g. 641c791, e8ddd2e) to see if Travis accepts those. (Again, every one of those works locally.)

What's really interesting is that the experimental test e8ddd2e does not even use random number generation. The build status can be found here: https://travis-ci.org/thm-mni-ii/sea/builds/455994593

I don't know if this helps, but that's all the information I have.