[hash] Expected behaviour of hashing quiet NaN?
Currently "functional/hash - hash_float_test" fails on Tru64/CXX6.5 (See http://tinyurl.com/8opfo) The reason of the failure is that QNaN and 0 give the same hash code on this platform. I was wondering what the expected hash of QNAN actually should be. Is it some platform dependent value? I put some traces in hash_detail::float_hash_value(), and the cause for the same hash value for 0 and QNAN seems to be that static_cast<int>(QNAN) gives 0 which then results in a call of hash_combine(0, 0) for both 0 and QNAN. Does anybody know what the expected result of static_cast<int>(QNAN) is? My guess is that either I should get a floating point exception for this expression or that the return value is unspecified and errno is set to [EDOM], but this is pure speculation on my side. Markus
At Monday 2005-04-18 03:52, you wrote:
Currently "functional/hash - hash_float_test" fails on Tru64/CXX6.5 (See http://tinyurl.com/8opfo)
The reason of the failure is that QNaN and 0 give the same hash code on this platform. I was wondering what the expected hash of QNAN actually should be. Is it some platform dependent value?
Am I missing something here? Since it is obvious that one canNOT generate a unique hash for all possible inputs, why should there necessarily be a difference between any 2?
I put some traces in hash_detail::float_hash_value(), and the cause for the same hash value for 0 and QNAN seems to be that static_cast<int>(QNAN) gives 0 which then results in a call of hash_combine(0, 0) for both 0 and QNAN.
Does anybody know what the expected result of static_cast<int>(QNAN) is? My guess is that either I should get a floating point exception for this expression or that the return value is unspecified and errno is set to [EDOM], but this is pure speculation on my side.
Markus
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At Monday 2005-04-18 03:52, you wrote:
Currently "functional/hash - hash_float_test" fails on Tru64/CXX6.5 (See http://tinyurl.com/8opfo)
The reason of the failure is that QNaN and 0 give the same hash code on this platform. I was wondering what the expected hash of QNAN actually should be. Is it some platform dependent value?
Am I missing something here? Since it is obvious that one canNOT generate a unique hash for all possible inputs, why should there necessarily be a difference between any 2?
You're probably right. Maybe the author of the test could perhaps clarify the motivation for this test, then. Markus
Markus Schöpflin wrote:
Victor A. Wagner Jr. wrote:
At Monday 2005-04-18 03:52, you wrote:
Currently "functional/hash - hash_float_test" fails on Tru64/CXX6.5 (See http://tinyurl.com/8opfo)
The reason of the failure is that QNaN and 0 give the same hash code on this platform. I was wondering what the expected hash of QNAN actually should be. Is it some platform dependent value?
Blimey, I'm suprised anyone is paying that much attention.
Am I missing something here? Since it is obvious that one canNOT generate a unique hash for all possible inputs, why should there necessarily be a difference between any 2?
You're probably right. Maybe the author of the test could perhaps clarify the motivation for this test, then.
It's perfectly okay for the compiler to fail the test. I've been meaning to change the test to reflect this, but haven't got around to it (I've been working on fixing the genuine failures). If you look through the hash tests you'll find lots of tests like this, it's an easy way to test that the hash function is taking into account all the data involved. To tell if they are really a failure or not requires some interpretation. If you look at the failures on gcc on SunOS, they indicate a real problem. The tests don't supply a general purpose hash testing suite, but one that tests whether the hash functions are doing what I expect. Daniel
Daniel James wrote:
It's perfectly okay for the compiler to fail the test. I've been meaning to change the test to reflect this, but haven't got around to it (I've been working on fixing the genuine failures).
If you look through the hash tests you'll find lots of tests like this, it's an easy way to test that the hash function is taking into account all the data involved. To tell if they are really a failure or not requires some interpretation. If you look at the failures on gcc on SunOS, they indicate a real problem.
I have to admit, following Victor's argumentation, I don't see the fundamental difference between the failures on SunOS and on Tru64.
The tests don't supply a general purpose hash testing suite, but one that tests whether the hash functions are doing what I expect.
I don't get you there. The tests are supposed to tell whether the hash library works ok or not on some particular compiler/platform. If some of the tests fail, I have to assume (from a user's point of view) that the library will not work reliably for me. (Especially as these are not compilation failures but runtime failures.) Maybe you could change the tests to just print the hash values on stdout? Markus
Markus Schöpflin <markus.schoepflin <at> comsoft.de> writes:
I have to admit, following Victor's argumentation, I don't see the fundamental difference between the failures on SunOS and on Tru64.
On SunOS gcc the hash function is giving the same result for std::numeric_limits<long double>::max(), std::numeric_limits<long double> ::max()/2 and std::numeric_limits<long double>::max()/4. This indicates that the function for getting its exponent is probably treating the value as a double. If you're using a long double you want to take advantage of its increased accuracy and range but the hash function is loosing that information and so could give bad results under certain circumstances.
The tests don't supply a general purpose hash testing suite, but one that tests whether the hash functions are doing what I expect.
I don't get you there. The tests are supposed to tell whether the hash library works ok or not on some particular compiler/platform. If some of the tests fail, I have to assume (from a user's point of view) that the library will not work reliably for me. (Especially as these are not compilation failures but runtime failures.)
This isn't released code, I wouldn't assume that it would work reliably at all. It might not even be fully included in the next release. When we reach the code freeze I'll add annotations to the tests to explain what's going on. I might also make some changes so that only real failures show up - but taking this too far would make the tests essentially useless. (An early version didn't take into account a float's sign, it met the hash specifications, but I'd consider that a bug).
Maybe you could change the tests to just print the hash values on stdout?
But then the results won't show up on the summary. At the moment it's more useful that the test summary shows me useful information. Daniel
Daniel James wrote:
Markus Schöpflin <markus.schoepflin <at> comsoft.de> writes:
I have to admit, following Victor's argumentation, I don't see the fundamental difference between the failures on SunOS and on Tru64.
On SunOS gcc the hash function is giving the same result for std::numeric_limits<long double>::max(), std::numeric_limits<long double> ::max()/2 and std::numeric_limits<long double>::max()/4. This indicates that the function for getting its exponent is probably treating the value as a double. If you're using a long double you want to take advantage of its increased accuracy and range but the hash function is loosing that information and so could give bad results under certain circumstances.
Thanks for the explanation.
The tests don't supply a general purpose hash testing suite, but one that tests whether the hash functions are doing what I expect.
I don't get you there. The tests are supposed to tell whether the hash library works ok or not on some particular compiler/platform. If some of the tests fail, I have to assume (from a user's point of view) that the library will not work reliably for me. (Especially as these are not compilation failures but runtime failures.)
This isn't released code, I wouldn't assume that it would work reliably at all. It might not even be fully included in the next release. When we reach the code freeze I'll add annotations to the tests to explain what's going on. I might also make some changes so that only real failures show up - but taking this too far would make the tests essentially useless. (An early version didn't take into account a float's sign, it met the hash specifications, but I'd consider that a bug).
I was under the impression that hash functions would be part of the upcoming release. Just to clarify, my intention was not to complain about a not working hash library but to understand/clarify _why_ the regression reports showed a failure for this platform.
Maybe you could change the tests to just print the hash values on stdout?
But then the results won't show up on the summary. At the moment it's more useful that the test summary shows me useful information.
Do you know about "always_show_run_output"? You just have to add "<test-info>always_show_run_output" to your hash-test rule to always see the output of the test runs. Markus
Markus Schöpflin <markus.schoepflin <at> comsoft.de> writes:
I was under the impression that hash functions would be part of the upcoming release.
They almost certainly will be. But they're still not quite finished - the extra week before the freeze is very useful.
Maybe you could change the tests to just print the hash values on stdout?
But then the results won't show up on the summary. At the moment it's more useful that the test summary shows me useful information.
Do you know about "always_show_run_output"? You just have to add "<test-info>always_show_run_output" to your hash-test rule to always see the output of the test runs.
No, I didnt know about it. Thanks. Daniel
participants (3)
-
Daniel James -
Markus Schöpflin -
Victor A. Wagner Jr.