Anonymous user
Talk:Bitwise operations: Difference between revisions
added clarification (I think) on storage of integers. -- ~~~~
(not a storage issue) |
(added clarification (I think) on storage of integers. -- ~~~~) |
||
Line 1:
Shifts have now been added to the task. Please check your languages to make sure they have shifting properly implemented. --[[User:Mwn3d|Mwn3d]] 17:11, 19 May 2008 (MDT)
== assumption of how integers are stored ==
Since the task is more-or-less bit orientated, the assumption is that integers are stored in binary form (that is, bits).
Line 15:
:There is a one-to-one relationship between any integer in the range 0..((2^n)-1) and a list of true/false values of length n. If the language is capable of representing such lists, it should not be hard to build functions to convert a number between these two forms.
:And, once you have achieved a binary representation. the rest of the problem is trivial. The language does not have to do this for you for it to be possible. --[[User:Rdm|Rdm]] 15:18, 23 March 2012 (UTC)
:: Since the task is BITwise operations, then yes, the assumption ia that the binary representation for integers is meaningful. In fact, the binary representation of a value of 75 in REXX (language) is '011011100110101'b or '3735'x (in hex) [on an ASCII machine]. One can do bitwise operations on that, but it would be more or less meaningless. Note that this is regardless of how a MACHINE stores (some) numbers, twos complement binary or whatnot. The task is to see how a LANGUAGE does bitwise, not the machine that it's running on. So it really does depending on how the numbers are stored. Even though my computer is a "32-bit" machine, the limitation of the REXX language's repesentation is not 2^31 or 2^32 (-1), but a limitation that (most) people relate to: "1" followed by so many zeroes; or mathematically: 10^p where p has to be AT LEAST 999,999,999 --- which is significantly larger than any binary number can be stored, and for the most uses, enough for most needs --- but then there are those Mersenne prime people who will be pushing even that limit ... It should also be noted that the REXX language stores numbers in this manner no matter what the underlying hardware supports (or doesn't support). In fact, REXX does arithmetic much in the same manner that humans do (say, in the way one muliplies 11.2 and -17.9 on paper), and as a consequence, there's no rounding in handling decimal fractions. But that's another matter that COBOL enthusiasts (and PL/I) would love (think PICtures). I didn't mean to delve into how arithmetic is performed. -- [[User:Gerard Schildberger|Gerard Schildberger]] 18:33, 23 March 2012 (UTC)
| |||