-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/03/2010 09:03 PM, Jeffrey Lee Hellrung, Jr. wrote:
You seem to really want some kind of one-to-one identification between integers and xint::integer objects,
Well, yes -- the xint::integer objects represent integers, after all. ;-)
Yes, and IEEE floats represent (limited precision and limited range) dyadic rationals. My point is, it can be practical and efficient to have 2 different underlying representations for the same abstract instance. You're already carrying around a sign bit + mantissa to represent an integer, so it seems to me unnatural to bend over backwards (exaggeration) to keep that sign bit unset when the mantissa drops to 0, if you really don't have to.
I have to call that cleanup function anyway, to skip past any leading zeros left over from whatever operation is being done.
have yet to see where this makes a difference in the core interface or complicates the internal implementation.
It would a bit, because there may be code in there that assumes that if the negative Boolean is true, the value is less than zero.
Isn't the sign just (mantissa == 0 ? 0 : sign_bit ? -1 : 1) ?
That's essentially the definition of the sign function. But before I discovered n1692 and its specification of that function, I just had an is_negative function in there. There may still be code that relies on the current behavior. Most likely if there is, I'll be able to find it quickly, but it's something I'll have to keep in mind if I do that.
Perhaps I should've been clearer: I have yet to see where this makes the internal implementation more complicated than assuming a unique zero representation, and it appears like it would simplify implementation as you avoid "cleaning up" a -0. However, the one thing I haven't done is actually *look* at the current implementation, and I was hoping your familiarity would be able to pinpoint some precise issue.
Other than the potential problem mentioned above, there should be no issues with implementing it -- *if* I stick with the rules I mentioned, so that every operation that results in a zero gets a positive zero, and negative zero is only provided when someone explicitly asks for it.
I don't know what you mean here. Isn't the arithmetic involving zeros fairly straightforward, signed or not?
If the zeros aren't signed, yes. If they are, and the library is supposed to honor the signs, things could get hairy. But it appears that I misunderstood your intentions... if a negative zero is still treated as zero, then all the math works out.
For reference, wikipedia outlines the arithmetic rules specific to signed zeros in their "signed zeros" article:
Noted for possible future reference, but as mentioned, I'd rather not deal with that stuff right now. Once the library is fully functional, I could add it, if there's any call for it.
What I would like to happen is, for example, the "natural" implementation of addition, where you don't specifically consider the rules for adding signed zeros, automatically works anyway for signed zeros. I might have to delve into the code to actually see what would happen...
I don't know off the top of my head either. They could work as written (once the sign function is modified to check for zero before negative), or they could get it completely wrong, I'd have to examine the code for each function to find out.
You've convinced me not to dismiss the idea out of hand. I'm still not sure that it's worthwhile, but I'll probably add it, with the understanding that any calculations done with it (except a unary minus) will come out with a positive-zero result. If someone needs a negative zero, they'll have to explicitly request it via the unary minus.
Well, hopefully whatever zero (whether it's +0 or -0) "falls out" of an operation will suffice. I don't think you want to guarantee every result equal to either +0 and -0 (save a unary minus) will be fixed to +0. That defeats the whole point of my proposal.
I thought the whole point of your proposal was to make it easier for people writing code on top of XInt? If the point is just to save the one or two clock cycles that are used for flipping the sign, it's hardly worth the effort. - -- 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/ iEYEARECAAYFAku39DYACgkQp9x9jeZ9/wSFEwCg3ZaMR1SStcmgEHU9Uvb7sw1P dnoAn2a/55B6O4pYCHW+NCO8lj2oEKr0 =Fedg -----END PGP SIGNATURE-----