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

m
→‎task requirements: added a new talk section. -- ~~~~
m (→‎task requirements: added a new talk section. -- ~~~~)
 
(4 intermediate revisions by 3 users not shown)
Line 38:
:: It's not valid to say that "the bits of the integer are just the bits of the characters that are used to describe (hold) the value of the integer". Proof: Change the leading bit from a 1 to a 0. The result is not a valid integer. --[[User:Rdm|Rdm]] 17:52, 8 May 2012 (UTC)
 
::: But it is valid to say that for the REXX language (that the bits of the integer are just the bits of the characters ...) because that's the way REXX stores "integers" (well, for that matter, the way REXX stores everything). Just because the leading bit is changed from "1" to a "0" (and thereby changing a leading bit in the character which is representing a numeric digit), doesn't make it a proof that the character that represented the digit wasn't valid in the first place. If the character (say) was a 7 (if using ASCII), now it's a '17'x. If it were on an EBCDIC system, the new character would be a lowercase "w". Of course, the leading character in the number could've been a blank. -- [[User:Gerard Schildberger|Gerard Schildberger]] 19:04, 8 May 2012 (UTC)
:::: I think that that's like saying that it's reasonable to pull a bit from a stack frame because the stack frame is being used to represent the number. --[[User:Rdm|Rdm]] 18:59, 9 May 2012 (UTC)
 
::::: [I hope I understand your wording, but instead:] ... ''because the stack frame is being used to'' '''STORE''' ''the number''.
 
===Clarification===
Line 139 ⟶ 143:
: This kind of things happen to people who love to overload operators. What many fail to realize is that seemingly innocuous expressions <code>a & b == 1</code> could do a lot of harm if one insists on using overloaded operators to force a uniform appearance on tasks that are only superficially similar. --[[User:Ledrug|Ledrug]] 19:44, 9 December 2011 (UTC)
:: Ya, I was beginning to think about that. I personally like polymorphism in operators and functions as a first cut. But I also like to have the ability to step out and get deep into the weeds if something demands it. Problem is that a lot of people seem to be in one camp or the other exclusively. :( --[[User:Dgamey|Dgamey]] 23:12, 9 December 2011 (UTC)
::: Actually, efficient MP engines only keep enough words around to represent the largest <code>1</code> bit needed to represent the number (they also do special tricks to handle negative numbers); they also keep around a count of how many words they are using (well duh!). That means that finding the “largest bit” (assuming positive) is possible in constant time. I don't know whether anyone really bothers with it though; the binary logarithm is not an operation that's needed very often given that the storage size is already known. (Finding the decimal logarithm though, that's tremendously valuable and also horribly expensive.) –[[User:Dkf|Donal Fellows]] 10:18, 12 June 2012 (UTC)
 
== task requirements ==
Four (or two, depending on you count them) of the task's requirements are:
 
::::* Define routines (or operators) '''lwb''' and '''upb''' that find the ···
::::* Also: Define the reverse routines (or operators) '''rlwb''' and '''rupb''' that find ···
(The added bold highlighting are mine, as well as the trimming.)
 
It appears that a vast majority of solutions (examples) haven't implemented the (above) four routines. &nbsp; Are these ''strict'' requirements, or are people (or programmers <big><big>☺</big></big>) &nbsp; allowed to ignore them completely or in part?
 
As for me, I ignored the first pair of requirements (for the REXX solution) as there didn't seem to be a need for REXX programmers to find the first bit of a number (a number that isn't even stored in binary in the first place), but I could write a pair of REXX subroutines to return a value that satisfies that requirement '''as if''' the number was stored in binary. &nbsp; One thing about REXX is that it can be made to pretend about almost anything. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 22:39, 1 February 2014 (UTC)