Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-05-05 09:35:35

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/04/2010 11:50 PM, Jeffrey Lee Hellrung, Jr. wrote:

> [...]
>>> What does sqr() do?
>>
>> sqr's a number, of course. ;-) Anyone familiar with sqrt(double) in the
>> standard library, or sqrt in XInt, should find it to be intuitive
>> naming. I don't expect that it will often need to be used directly
>> anyway.
> 
> FWIW, I prefer "square", but I know of at least one library that chose
> to use sqr (and given my opinions of this library, I wouldn't consider
> that a point in your favor ;)

Oops, I'd better change it then. ;-)

> My rationale:  I've always considered the "r" in "sqrt" to be the "r" in
> "root", which doesn't jive well with the "r" in "sqr".  And "square" is
> still plenty short.

Yes, the need for that 'r' is an annoying inconsistency.

> Hardly the tallest nail, though ;)

True enough.

[...]
>> bool operator>=(const integer&  num1, const integer&  num2) {
>>      return compare(num1, num2)>=0; }
>>
>> I think you can see the appeal of doing it that way. :-) I might be
>> missing a trick there, but I don't think so... compare returns as soon
>> as it can tell what the answer is; it only has to pursue it to the
>> bitter end when the arguments are equal down to the lowest digit_t. I
>> don't think dedicated functions for each operator could be made any more
>> efficient.
> 
> I don't have a problem with this, other than (generally speaking)
> operator==/operator!= often have a more efficient implementation than
> through compare.  For example, if lengths of num1 and num2 are equal, it
> might be better (heuristically) to start comparing from the least
> significant chunk rather than the most significant chunk, since it might
> be expected for less significant chunks to have less correlation than
> more significant chunks. 

Yes, that might be slightly better. Easy enough to add; I've put it on
the to-do list.

> In the end, the order you compare the chunks in operator==/operator!=
> probably doesn't make a difference.

Not by any noticeable amount, but if the cost in programmer-time is
minimal and there's no other reason to avoid it, I'd prefer to take all
the efficiency I can get.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvhdCcACgkQp9x9jeZ9/wTiYwCghvlTJB4rVFqU+G0DaJszBlPT
MR8AnRhAKGLtjB6Fmo3v0GyPLCS3MNH/
=qg/7
-----END PGP SIGNATURE-----