Anonymous user
Talk:Find first and last set bit of a long integer: Difference between revisions
Talk:Find first and last set bit of a long integer (view source)
Revision as of 04:22, 8 December 2011
, 12 years ago→Initial C code specimen requires a long int algorithm
m (→Clarification) |
|||
Line 55:
NJoy [[User:NevilleDNZ|NevilleDNZ]] 03:17, 8 December 2011 (UTC)
: From a practical point of view (C is not likely your go-to language for proof of concept stuff), anything longer than the longest native type doesn't need its individual method, because it has to be in a struct or array, and there's no atomic bit operations anyway -- we are worried about efficiency (are we?), so a generic "any length bit operation" is out of question. Just scan whatever struct or array from one side to the other and deal with the first non-zero item. You can hardly do better than that without special hardware. Unless we are talking about say, OpenCL, where it's a whole different matter.
: For the first/last nomenclature, an integer type has well defined least/most signicant bit concept, while first/last/left/right all depends on endianness. If the bits are transmitted on a wire, we also need to know the bit ordering in a byte, so these are hazy at best. The 32-bit number 257 can be stored in memory as either "01 01 00 00" or "00 00 01 01", so what's the "last" set bit? Or the "left most" one? Are we going to consider 32 bit as smallest unit, or 8 bit? Unless you have a spec about using these bits, lsb/msb is a better way to refer to them.
: As to the hex vs binary output, I personally find reading 8 hex digit is less stressful than reading 32 1s and 0s. I did provide the positions of the related bits, though. --[[User:Ledrug|Ledrug]] 04:22, 8 December 2011 (UTC)
| |||