Talk:Find first and last set bit of a long integer: Difference between revisions

 

: The problem comes when comparing, say, calculations of the bits for an 8-bit number with those for a 64-bit number. The only non-crazy interpretation of <code>upb</code> and <code>lwb</code> involves giving the same values for “65” however many bits are used to represent it. This in turn enables arbitrary-precision integer arithmetic (because you can ignore the actual representation width — a good thing because it may be variable in the implementation). OTOH, it also means that you probably lose the duality between bit arrays and numbers as with numbers you enumerate the bits in ''logical'' order, whereas with bit arrays you enumerate in physical order; there's no reason to assume the two are identical (nor is it possible to know the physical order of bits in a byte with modern hardware, though it probably follows the byte order in order to keep circuitry smaller in ALUs). The long and short of it is this: the task asked about integers so the results ''must'' be sane for them even if that leads to odd results for bit strings. (I prefer the convention of using <tt>-1</tt> for bit positions of <tt>0</tt>, as that at least is a position that is always not in the bit sequence at all; this might be in part implied by the fact that the Tcl solution is always using arbitrary-precision math; that's how Tcl's math works.) –[[User:Dkf|Donal Fellows]] 14:51, 8 December 2011 (UTC)