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 22:39, 1 February 2014
, 10 years ago→task requirements: added a new talk section. -- ~~~~
m (→task requirements: added a new talk section. -- ~~~~) |
|||
| (6 intermediate revisions by 3 users not shown) | |||
Line 33:
Except, this task is asking for the first and last set bit of the integer, not of the characters which you use to represent that integer. But that's just the title, and I agree that the task itself is not very clear about the relevance of the representation. Integers represented using floating point notation have a similar issue here. Ultimately, the task is not asking for the bits -- that part is trivial -- what the task is asking for is where these bits would be placed in the integer. And the task is also foggy about "integers" -- integers can be negative... --[[User:Rdm|Rdm]] 13:01, 8 May 2012 (UTC)
Yes, I read the task's description. Integers are stored as characters in REXX. So the bits of the integer are just the bits of the characters that are used to describe (hold) the value of the integer. Negative integers normally (but not always) start with the character '-' (the minus sign). Integers can also have any number of leading (and/or trailing and/or imbedded in some cases) blanks, but that's another complication. Integers also can have a leading plus (+) sign. It appears to me that most everyone is making the assumption that integers are stored in binary, and that's not necessary true for all languages. A few tasks seem to be "C"-centric. It would make more sense (to me) not to assume how integers are stored, but word the task something like: find the first and last set bit of an integer when (or if) stored in a binary form --- and even that can be misinterpreted --- but it would preclude some languages, however. I would hope that these tasks wouldn't be worded to do such things (preclusions or exclusions). When using the word LONG, a (huge?) assumption is already being made. REXX has no such thing as short, long, longlong, etc. And, as it was said, it's a bit foggy (about integers). The REXX language doesn't have, in the true sense (whatever that means), integers. It has character strings, and some character strings are numbers. And some numbers are whole numbers (I guess you could call them integers), and some whole numbers look a lot like integers. Hold on, this train has a caboose. A whole number (in REXX) is a number that has no fractional part when expressed within the current NUMERIC DIGITS (that's the size or width, if you will, of the largest "mantissa" of a number --- the default is 9). So "1.5e5" is a whole number, so would be "7.9999999999999999", and " + 5 " (I know the latter looks like more of an expression than how an integer would be stored internally). -- [[User:Gerard Schildberger|Gerard Schildberger]] 17:28, 8 May 2012 (UTC)
:: 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 134 ⟶ 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. Are these ''strict'' requirements, or are people (or programmers <big><big>☺</big></big>) 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. 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)
| |||