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

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-04 23:50:43

On 05/04/2010 05:17 PM, Chad Nelson wrote:
> On 05/04/2010 02:23 PM, Stewart, Robert 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 ;)

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.

Hardly the tallest nail, though ;)

[...]
>> Nevertheless, this is another case of only having to worry about the
>> implementation of a core set of functions and leave the others in
>> terms of those.
>
> bool operator==(const integer&num1, const integer&num2) {
>      return compare(num1, num2)==0; }
> bool operator!=(const integer&  num1, const integer&  num2) {
>      return compare(num1, num2)!=0; }
> bool operator<(const integer&  num1, const integer&  num2) {
>      return compare(num1, num2)<0; }
> bool operator>(const integer&  num1, const integer&  num2) {
>      return compare(num1, num2)>0; }
> bool operator<=(const integer&  num1, const integer&  num2) {
>      return compare(num1, num2)<=0; }
> 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.  In the end, the order you compare the chunks 
in operator==/operator!= probably doesn't make a difference.

- Jeff