Re: [boost] [dynamic_bitset] Comparison operators without assertions

Subject: Re: [boost] [dynamic_bitset] Comparison operators without assertions
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-05-17 00:39:08

On 5/16/2017 7:33 PM, Gavin Lambert via Boost wrote:
> On 17/05/2017 05:01, Edward Diener wrote:
>> There is no other way to do it. BTW ulong is 64-bits on any 64-bit OS.
> 
> "unsigned long" is 32-bits on Windows, even in 64 bit.
> 
>> Feel free to suggest an algorithm which works doing bit-by-bit
>> comparisons when the number of bits are different.
> 
> What's wrong with comparing bit-by-bit up to the common length, then if 
> still equal, whichever is longer is greater?

It depends on what you consider the bits comprising the common length ? 
I am assuming you are considering the bits comprising the common length 
as the lower order bits comprising the common length. So that with

1010001 and 111

the bits comprising the common length are 001 and 111. Because if you 
mean the high order bits comprising the common length, so that the bits 
comprising the common length are 101 and 111, that makes absolutely no 
sense to me, since by that 1010001 < 111. However even if you mean the 
low order bits comprising the common length then by your suggestion 
1010001 is still < 111, which again makes no sense. I think whatever the 
algorithm the greater value has to be greater than the lesser value

An alternative algorithm I have been considering is when the bit sizes 
are unequal is:

a) The bits comprising the common length are the low order bits.
b) If the bitset with the larger bit size has any 1 bit outside the bits 
comprising the common length, the smaller bit size is always < the 
larger bit size.
c) Else do a bit-by-bit comparison for the bits comprising the common 
length going from the higher order bit to the lower order bit of just 
those bits.

This algorithm would guarantee that the greater value is always > the 
lesser value without the to_ulong limitation of the number of bits in an 
unsigned long.

> 
> Sure, that doesn't necessarily produce the same answer as an integral 
> comparison, but that's not a useful comparison for a bitset anyway.

I disagree. As far as ordering I think it is the only always reliable 
comparison.