Debian build (test) failure on i386 about ensmallen HOT 7 CLOSED

This is probably due to randomness in the tests. Might be sufficient to fix this by simply increasing the margin from 0.1 to 0.11 or even 0.15. In other words, try changing
REQUIRE( coordinates(1) == Approx(2.0).margin(0.1) )
to
REQUIRE( coordinates(1) == Approx(2.0).margin(0.15) )

PS. isn't the i386 architecture a museum piece by now? I'm surprised that anybody doing numeric linear algebra would be using something which is quite slow and inefficient. Ensmallen by default uses 64 bit floats (double precision), so an old 32 bit architecture is never going to be optimal.

from ensmallen.

The exact same thing happened with 2.19.0: test failed exactly the same way in i386 and succeeded on everything else. Anyway, I'll increase the margin.

Regarding whether i386 is obsolete: it's about the same efficiency as amd64 for floating point, after all it's the same CPU using the same FPUs. The main difference is 32-bit vs 64-bit pointers, and obviously you're better off with 32-bit pointers if you're not using enough memory to overflow their address range. On the other hand, there are fewer registers, which is yucky. So there's a sort of hybrid thing called x32, which basically uses the amd64 instructions but only 32-bit pointers, and runs on the same CPUs, and has GCC (gcc -mx32) and Linux kernel (/sys/module/syscall/parameters/x32) support.

In any case, Debian wants to autobuild on all its architectures. You can disable some for a package, but it's considered bad form unless you have a good reason.

from ensmallen.

By default the random seed is "hardcoded" randomly during compilation by virtue of the random seed never being set for the tests. So I have seen situations before where this 'hardcoded' random seed is unlucky and there is a test failure, but also different versions of the ensmallen code still happen to produce the same random seed (and thus the same failure is observed). I've even seen that across different minor (and major!) versions of compilers. So, my guess is that's what's going on here. Increasing the margin is probably the right call, but when I have a chance I'll run some tests with different random seeds to see what the failure rate is---if I can't reproduce the failure on x86_64 at all even with many different random seeds, I'll start wondering if there is some deeper bug...

from ensmallen.

@rcurtin Looking at the tests, this looks possibly problematic:

It's not immediately clear what is the seed value provided by Catch2 when there is nothing specified on the command line. Perhaps the default seed varies by the architecture (eg. 32 bit vs 64 bit) ?

I suggest to add the following to tests/main.cpp, so we're not in the dark:
std::cout << "RNG seed value: " << seed << std::endl;

from ensmallen.

The default seed is probably whatever the memory happens to be initialized to at runtime. Anyway, I added the output like you suggested, and adjusted the test tolerances in #360, so for 2.19.2 @barak shouldn't see this issue anymore. 👍

from ensmallen.

@barak PR #360 with increased tolerances was merged. This will eventually become part of the 2.19.2 release.

If you'd prefer to have this fixed before the 2.19.2 release, I suggest to apply the same changes to the debian package.

from ensmallen.

No worries; I loosened the tolerance in a patch uploaded last Tuesday.

from ensmallen.