I'm facing a problem. when we want to subtract a number from another using 2's complement we can do that. I don't know how to subtract fractional number using 2's complement.
5 is in binary form 101 and 2 is 10. if we want to subtract 2 from 5 we need to find out 2's complement of 2
2's complement of 2-> 11111110
so if we now add with binary of 5 we can get the subtraction result. If I want to get the result of 5.5-2.125. what would be the procedure.
Fixed point numbers can be used and it is still common to find them in embedded code or hardware.
Their use is identical to integers, but you need to specify where your "point" is. For instance, assume that you want 3 bits after after the point and that your data is 8 bits, bits 7..3 are the integer part (left of "point") and bits 2..0 the fractional part. The interpretation of integer part is as usual the binary decomposition of this integer: bits 3 correspond to 20, bits 4 to 21, etc.
For the fractional part, the decomposition is in negative powers or two. bits 2 correspond to 2-1, bits 1 to 2-2 and bit 0 to 2-3.
So for you problem, 5.5=4+1+1/2=22+20+2-1 and its code is 00101(.)100. Similarly 2.125=2+1/8 and its code is 00010(.)001 (note (.) is just an help to understand the coding).
Indeed they are just integers, but you must take into account that all your numbers are multiplied by 2-3. This will have no impact for addition, but results of multiplication and division must be adjusted. Taking into account the position of point and managing over and underflows is the difficulty of arithmetic with fixed point, but it allows to do fractional computations even if your hardware does not provide floating point support (for instance with low end microcontrollers or FPGA systems).
Two complement is similar to integers and its computation is identical. If code of 2.125 is 00010(.)001, than -2.125==11101(.)111. Operations are as usual.
+5 00101(.)100
-2.125 11101(.)111
00011(.)011
and 00011(.)011=2+1+1/4+1/8=3,375
For the record, two complement first use was for fixed point fractional numbers and two complement name comes from that. If a fractional number if represented by, say 0(.)1100000 (0.75), its negative counter part will be 1(.)0100000 (-0.75 or 1.25 if interpreted as unsigned) and we always have x+(unsigned)-x=2. For this coding, the negative value of a fractional number x is the number y that must be added to x to get a 2, hence the name that y is 2's complement of x.
This question already has answers here:
Round up from .5
(7 answers)
Closed 6 years ago.
It seems there is an error in round function. Below I would expect it to return 6, but it returns 5.
round(5.5)
# 5
Other then 5.5, such as 6.5, 4.5 returns 7, 5 as we expect.
Any explanation?
This behaviour is explained in the help file of the ?round function:
Note that for rounding off a 5, the IEC 60559 standard is expected to
be used, ‘go to the even digit’. Therefore round(0.5) is 0 and
round(-1.5) is -2. However, this is dependent on OS services and on
representation error (since e.g. 0.15 is not represented exactly, the
rounding rule applies to the represented number and not to the printed
number, and so round(0.15, 1) could be either 0.1 or 0.2).
round( .5 + 0:10 )
#### [1] 0 2 2 4 4 6 6 8 8 10 10
Another relevant email exchange by Greg Snow: R: round(1.5) = round(2.5) = 2?:
The logic behind the round to even rule is that we are trying to
represent an underlying continuous value and if x comes from a truly
continuous distribution, then the probability that x==2.5 is 0 and the
2.5 was probably already rounded once from any values between 2.45 and 2.54999999999999..., if we use the round up on 0.5 rule that we learned in grade school, then the double rounding means that values
between 2.45 and 2.50 will all round to 3 (having been rounded first
to 2.5). This will tend to bias estimates upwards. To remove the
bias we need to either go back to before the rounding to 2.5 (which is
often impossible to impractical), or just round up half the time and
round down half the time (or better would be to round proportional to
how likely we are to see values below or above 2.5 rounded to 2.5, but
that will be close to 50/50 for most underlying distributions). The
stochastic approach would be to have the round function randomly
choose which way to round, but deterministic types are not
comforatable with that, so "round to even" was chosen (round to odd
should work about the same) as a consistent rule that rounds up and
down about 50/50.
If you are dealing with data where 2.5 is likely to represent an exact
value (money for example), then you may do better by multiplying all
values by 10 or 100 and working in integers, then converting back only
for the final printing. Note that 2.50000001 rounds to 3, so if you
keep more digits of accuracy until the final printing, then rounding
will go in the expected direction, or you can add 0.000000001 (or
other small number) to your values just before rounding, but that can
bias your estimates upwards.
When I was in college, a professor of Numerical Analysis told us that the way you describe for rounding numbers is the correct one. You shouldn't always round up the number (integer).5, because it is equally distant from the (integer) and the (integer + 1). In order to minimize the error of the sum (or the error of the average, or whatever), half of those situations should be rounded up and the other half should be rounded down. The R programmers seem to share the same opinion as my professor of Numerical Analysis...
I need to multiply X with a floating point number in floating point as i don't have floating point operations in my processor. I understand the method but don't know why that method exists?
Suppose we want to multiply 2*4.5 in decimal I do the below:
2 * 4.5 (100.1)
So i multiply 2*1001 = 2*9 = 18 and then right shift by 1.
so 18>>1 = 9
Is it that we represent 2 in fixed point and represent 4.5 in fixed point and as we multiply Q1.1 and Q1.1 format so we get Q2.2 format and we do right shifting causing Q1.1 format result.Is this right?
In decimal, your fixed-point example is actually:
2 * 4.5
2 * 45 (after multiplying by 10) = 90
90 / 10 = 9 (after dividing the 10 back out)
In binary, the same thing is being done, but just with powers of 2 instead of powers of 10 (as the factors / divisors). Fixed point operations occur in purely integral space after appropriate multiplications. And multiplying or dividing by a power of 2 is just a left shift or right shift respectively on the binary number (very fast for the CPU). In fixed-point the number of bits to the left (integer) and right (fractional) of the decimal point are fixed (predetermined), which means that some numbers cannot be represented on the scale without loss of precision.
Floating-point further extends the concept by allowing the number of bits assigned to the left and right of the decimal point to be flexible. In floating point, every number is represented as an integral "significand" (or mantissa) to a specified power (for example, a power of 2). This representation allows the same number of significant digits to be maintained over a greater dynamic range (for very small or very large magnitude numbers). For floating point, most of the bits will be assigned to the significant digits of the mantissa, and fewer of the bits assigned to the digits of the power. Floating-point calculations are more expensive (time-wise) than fixed-point, which is why fixed-point remains popular in microcontrollers and embedded systems.
If I didn't answer your question, please elaborate and I will edit this answer to include the information you desire.
This is more of a maths question than programming but I figure a lot of people here are pretty good at maths! :)
My question is: Given a 9 x 9 grid (81 cells) that must contain the numbers 1 to 9 each exactly 9 times, how many different grids can be produced. The order of the numbers doesn't matter, for example the first row could contain nine 1's etc. This is related to Sudoku and we know the number of valid Sudoku grids is 6.67×10^21, so since my problem isn't constrained like Sudoku by having to have each of the 9 numbers in each row, column and box then the answer should be greater than 6.67×10^21.
My first thought was that the answer is 81! however on further reflection this assumes that the 81 numbers possible for each cell are different, distinct number. They are not, there are 81 possible numbers for each cell but only 9 possible different numbers.
My next thought was then that each of the cells in the first row can be any number between 1 and 9. If by chance the first row happened to be all the same number, say all 1s, then each cell in the second row could only have 8 possibilites, 2-9. If this continued down until the last row then number of different permutations could be calculated by 9^2 * 8^2 * 7^2 ..... * 1^2. However this doesn't work if each row doesn't contain 9 of the same number.
It's been quite a while since I studied this stuff and I can't think of a way to work it out, I'd appreciate any help anyone can offer.
Imagine taking 81 blank slips of paper and writing a number from 1 to 9 on each slip (nine of each number). Shuffle the deck, and start placing the slips on the 9x9 grid.
You'd be able to create 81! different patterns if you considered each slip to be unique.
But instead you want to consider all the 1's to be equivalent.
For any particular configuration, how many times will that configuration be repeated
due to the 1's all being equivalent? The answer is 9!, the number of ways you can permute the nine slips with 1 written on them.
So that cuts the total number of permutations down to 81!/9!. (You divide by the number of indistinguishable permutations. Instead of 9! indistinguishable permutations, imagine there were just 2 indistinguishable permutations. You would divide the count by 2, right? So the rule is, you divide by the number of indistinguishable permutations.)
Ah, but you also want the 2's to be equivalent, and the 3's, and so forth.
By the same reasoning, that cuts down the number of permutations to
81!/(9!)^9
By Stirling's approximation, that is roughly 5.8 * 10^70.
First, let's start with 81 numbers, 1 through 81. The number of permutations for that is 81P81, or 81!. Simple enough.
However, we have nine 1s, which can be arranged in 9! indistinguishable permutations. Same with 2, 3, etc.
So what we have is the total number of board permutations divided by all the indistinguishable permutations of all numbers, or 81! / (9! ** 9).
>>> reduce(operator.mul, range(1,82))/(reduce(operator.mul, range(1, 10))**9)
53130688706387569792052442448845648519471103327391407016237760000000000L
Say we have a set of 3D (integer) coordinates from (0,0,0) to (100,100,100)
We want to visit each possible coordinate (100^3 possible coordinates to visit) without visiting each coordinate more than once.
The sum of the differences between each coordinate in adjacent steps cannot be more than 2 (I don't know if this is possible. If not, then minimized)
for example, the step from (0,2,1) to (2,0,0) has a total difference of 5 because |x1-x2|+|y1-y2|+|z1-z2| = 5
How do we generate such a sequence of coordinates?
for example, to start:
(0,0,0)
(0,0,1)
(0,1,0)
(1,0,0)
(1,0,1)
(0,0,2)
(0,1,1)
(0,2,0)
(1,1,0)
(2,0,0)
(3,0,0)
(2,0,1)
(1,0,2)
(0,0,3)
etc...
Anyone know an algorithm that will generate such a sequence to an arbitrary coordinate (x,y,z) where x=y=z or can prove that it is impossible for such and algorithm to exist? Thanks
Extra credit: Show how to generate such a sequence with x!=y!=z :D
One of the tricks (there are other approaches) is to do it one line [segment] at a time, one plane [square] at a time. Addressing the last part of the question, this approach works, even if the size of the volume visited is not the same in each dimension (ex: a 100 x 6 x 33 block).
In other words:
Start at (0,0,0),
move only on the Z axis till the end of the segment, i.e.
(0,0,1), (0,0,2), (0,0,3), ... (0,0,100),
Then move to the next line, i.e.
(0,1,100)
and come backward on the line, i.e.
(0,1,99), (0,1,98), (0,1,97), ... (0,1,0),
Next to the next line, going "forward"
And repeat till the whole "panel is painted", i.e ending at
... (0,100,99), (0,100,100),
Then move, finally, by 1, on the X axis, i.e.
(1,100,100)
and repeat on the other panel,but on this panel going "upward"
etc.
Essentially, each move is done on a single dimension, by exactly one. It is a bit as if you were "walking" from room to room in a 101 x 101 x 101 building where each room can lead to any room directly next to it on a given axis (i.e. not going joining diagonally).
Implementing this kind of of logic in a programming language is trivial! The only mildly challenging part is to deal with the "back-and-forth", i.e. the fact that sometimes, some of the changes in a given dimension are positive, and sometimes negative).
Edit: (Sid's question about doing the same diagonally):
Yes! that would be quite possible, since the problem states that we can have a [Manhattan] distance of two, which is what is required to go diagonally.
The path would be similar to the one listed above, i.e. doing lines, back-and-forth (only here lines of variable length), then moving to the next "panel", in the third dimension, and repeating, only going "upward" etc.
(0,0,0) (0,0,1)
(0,1,0) first diagonal, only 1 in lengh.
(0,2,0) "turn around"
(0,1,1) (0,0,2) second diagonal: 2 in length
(0,0,3) "turn around"
(0,1,2) (0,2,1) (0,3,0) third diagonal: 3 in length
(0,4,0) turn around
etc.
It is indeed possible to mix-and-match these approaches, both at the level of complete "panel", for example doing one diagonally and the next one horizontally, as well as within a given panel, for example starting diagonally, but when on the top line, proceeding with the horizontal pattern, simply stopping a bit earlier when looping on the "left" side, since part of that side has been handled with the diagonals.
Effectively this allows a rather big (but obviously finite) number of ways to "paint" the whole space. The key thing is to avoid leaving (too many) non painted adjacent area behind, for getting back to them may either bring us to a dead-end or may require a "jump" of more than 2.
Maybe you can generalize Gray Codes, which seem to solve a special case of the problem.
Seems trivial at first but once started, it is tricky! Especially the steps can be 1 or 2.
This is not an answer but more of a demostration of the first 10+ steps for a particular sequence which hopefully can help others to visualise. Sid, please let me know if the following is wrong:
s = No. of steps from the prev corrdinates
c1 = Condition 1 (x = y = z)
c2 = Condition 2 (x!= y!= z)
(x,y,z) s c1 c2
---------------
(0,0,0) * (start)
(0,0,1) 1
(0,1,0) 2
(1,0,0) 2
(1,0,1) 1
(1,1,0) 2
(1,1,1) 1 *
(2,1,1) 1
(2,0,1) 1 *
(2,0,0) 1
(2,1,0) 1 *
(2,2,0) 1
(2,2,1) 1
(2,2,2) 1 *
(2,3,2) 1
(2,3,3) 1
(3,3,3) 1 *
(3,3,1) 2
(3,2,1) 1 *
(3,2,0) 1 *
.
.
.