-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/30/2010 07:42 PM, Peter Dimov wrote:
Where am I explaining things wrong, that everyone seems to think that any function can randomly return a NaN, and is complaining about it on the basis of that misconception?
You stopped reading too soon. In my the next sentence, I said (quoting from memory):
"I don't see how checking the result of every operator/ for NaN is better, more readable or more expressive than checking the denominator for being zero beforehand"
Ah, I see... you had abbreviated operator/ to op/, and I misread it for a typo of "operation". Sorry.
which, as you can see, acknowledges both the rarity of functions returning NaN and the fact that they do so under circumstances that are well defined and easily checked for.
But not quite accurately, because operator/ throws an xint::divide_by_zero under those circumstances, unless you're deliberately blocking exceptions.
Besides, the problem introduced by the NaN, that every function taking a xint must be prepared to receive it, is not affected by the number of functions that produce NaNs.
Why is that a problem? It's only library functions that need to be prepared to receive a NaN, functions built on top of XInt can ignore them and let the library catch them. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuyltAACgkQp9x9jeZ9/wQuLACcDwv6i++eGuPfRTpJIgdFX3D/ ZssAoKuiT/Fp8jEEgJtuox5KcZOw+D4v =zH04 -----END PGP SIGNATURE-----