-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/2010 03:43 PM, Jeffrey Lee Hellrung, Jr. wrote:
Don't forget (assuming a single unsigned 0):
x / 0 => NaN
Eh? I thought we'd decided that anything divided by zero, other than zero itself, was infinity (or negative infinity, if x is negative)?
Of course you can define whatever arithmetic you like, but I think it makes more sense for products and quotients of like signs being positive, of opposite signs being negative, and anything involving (unsigned) zero giving either (unsigned) zero or NaN.
You've completely lost me. Zero doesn't have a sign, so anything divided by zero would have to take its sign from 'x'.
What are the arguments against a signed zero?
That there's no need for it in an integer library. [...] As such, there's no real need for it in XInt.
I was looking more for objections based purely on logical inconsistencies. Can you think of any?
Several. To begin with, would there be different values for positive zero, negative zero, and "true" zero? If not, zero would have to be assumed to be positive zero, and that's a slight logical inconsistency right there. And if all two or three zero types evaluated the same, how would you detect a positive zero or a negative zero? The sign() function wouldn't do it; it's spec'd to return zero for zeros, and it would break a lot of things in the code if that were changed. Comparison functions would see them as the same too. You'd have to add a special function just to detect the sign on a zero. To make a sensible signed-zero value work, I'd have to make up portions of the math, or adopt them from floating-point stuff even though that doesn't make sense here. It gets very messy and arbitrary, and I'd rather avoid it.
Is it possible to simply be agnostic to the sign bit when the mantissa is 0?
Isn't that the same as saying that -0 is identical to +0?
If you don't have any infinities or NaNs to worry about, yes! For this case, I'm just suggesting you may not have to normalize zeros if -0 behaves exactly the same as +0. But it still may be useful to distinguish between them for libraries built on top of the core implementation. An arbitrary-precision floating point type may make a distinction between +0 and -0, and it would be convenient if the underlying integer core allowed this distinction naturally. [...]
That's about the only argument that had any chance of swaying me. :-)
What do you think?
That I still don't see any way to cleanly and logically implement it. The aforementioned arbitrary-precision floating point package will just have to handle that itself, maybe by making an extremely small but non-zero value and calling it negative zero. - -- 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/ iEYEARECAAYFAku2knYACgkQp9x9jeZ9/wRpYgCfU7212WL2DPOBjqYVZfieb408 +eUAnjs9uxudwZEBHeufFwfNn7qxN5xD =hHEW -----END PGP SIGNATURE-----