-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test-suite fails #47
Comments
likely https://ghc.haskell.org/trac/ghc/ticket/8195 |
does the problem go away when you build / test after configure with the ghc option -msse2? |
I can't test, the log is from NixOS build bot. |
honestly theres 2-3 things going on
is the offending line in question
|
cc @peti who has Hydra powers if -msse2 is needed for proper function of vector on i686 then perhaps vector should impose the flag by default? |
the problem is more like the test should use some notation of approximate equality rather than exact, though forcing -msse2 for the build would also work |
-msse2 is needed for deterministic floating point arithmetic on 32-bit x86, period, it seems. I'm not against sticking -msse2 on the test suite (or what have you) to force the issue, though (if we determine it's the best course of action). I just want to know that it actually fixes this problem before releasing a new package version. :) |
ermmm, we'd only want to enable that for 32bit intel (if at all). I'd slightly favor pushing for some sort of approximate equality test. a la https://hackage.haskell.org/package/ieee754-0.7.3/docs/src/Data-AEq.html#AEq though because the test suite should be deterministic per se, maybe the -msse2 route is the right solution for nix. |
to repeat/clarify: the only way to get deterministic floating point computations done via an optimizing compiler on x86_32 is to compile all code to use the compiler's equivalent of |
Building the package with |
…x test suite failures haskell/vector#47
I think this is one of few cases where we do want floating point equality. We don't test numerical calculations but rather fact that perform same calculation in the same order. So it does make sense to check that two implementation of same algorithm produce same results. (assuming determinitsic FP arithmetics) AEq type class is in my opinion misguided. There's no such thing as these two floating point numbers are approximately equal. It's always: these numbers are equal in context of given problem. And same pair of numbers could be considered equal or not equal depending on problem. Furthemore there's no single algorithm for comparing two numbers. For example |
True, very true. Otoh, I think solution is basically just that on 32bit x86, the tests will fail if they're not built with -msse2. @dolio I think we can close this ticket, thoughts? |
Yeah. We did same for the math-functions test suite. |
Do we want to ad -msse2 to the test suite so that it can't fail except on systems that don't support it? Also, is it just the test suite that needs to be built with -msse2? Or do both the tests and the main package need it? |
yeah, i think its just the test suite that needs be built that way. (though maybe folks are using vector on realllly old systems, in which case ONLY the test suite should have that flag? I dont know how old the hardware people might have could be!) |
http://hydra.nixos.org/build/15860082/nixlog/1/raw
The x86_64 box seems to have tested it fine.
The text was updated successfully, but these errors were encountered: