I would like to solve following equation:
x^2-bitxor(2,x)=0
Is it possible ?
bitxor(2,x) wil either add 2 or subtract 2 to/from x, so you have to solve both:
x^2 - x + 2 = 0
and:
x^2 - x - 2 = 0
and then test to see if the any of the solutions work in the original expression.
In the first case the roots are complex, in the second case the roots are -1 and +2.
Substituting back into the original equation:
x = -1 => (-1^2) - bitxor(2, -1) = 1 - (-3) = 4
x = 2 => (2^2) - bitxor(2, 2) = 4 - 0 = 4
So apparently there is no real integer solution.
There are solutions in modular arithmetic, which is precisely the arithmetic that most computers use for unsigned integers. For example, consider the case of modulo 256 arithmetic. In C and C++, this is the arithmetic of unsigned char. Here we have two solutions, 91 and 166. (See http://www.wolframalpha.com/input/?i=x%5E2+mod+256+%3D+x+-+2%2C+x+%3E+0%2C+x%3C+256 ).
In fact, for any modulo 2^N system, there will be two solutions that sum to 1 (modulo 2^N).
Related
N is random number,
I am confused with bound.
Any help is appreciated.
Well, for a random number n, there exists a, b such that 2^a <= n <= 2^b or just a k such that 2^(k-1) <= n <= 2^k - 1 (1). We know that for any number less than 2^n, we need log(2^n) = n * log(2) = n bits to represent it (2). For example:
5: 4 < 5 < 8; we need 3 bits for 4, 5 bits for 8 => we need 4 bits for 5
23: 16 = 2^4 < 23 < 32 = 2^5; so we need 5 bits to represent 23
In conclusion, for an exact number of bits b for a random number n, we can use the formula:
b = floor(log(n)) + 1
So, the big-O notation that we are gonna use is O(floor(log(n)) + 1) = O(logn).
Extra info:
SO Answer
Article
1) I supposed it is a random, integer, positive number (although it's easy to generalize for negative numbers too) which I suppose it is your problem case; for fractional numbers is's a bit harder to generalize this formulae
2) The log notation refers to logarithm in base 2
I just read a post from Quora:
http://www.quora.com/Is-Julia-ready-for-production-use
At the bottom, there's an answer said:
2 ^ 3 ^ 4 = 0
I tried it myself:
julia> 2 ^ 3 ^ 4
0
Personally I don't consider this a bug in the language. We can add parenthesis for clarity, both for Julia and for our human beings:
julia> (2 ^ 3) ^ 4
4096
So far so good; however, this doesn't work:
julia> 2 ^ (3 ^ 4)
0
Since I'm learning, I'd like to know, how Julia evaluate this expression to 0? What's the evaluation precedent?
julia> typeof(2 ^ 3 ^ 4)
Int64
I'm surprised I couldn't find a duplicate question about this on SO yet. I figure I'll answer this slightly differently than the FAQ in the manual since it's a common first question. Oops, I somehow missed: Factorial function works in Python, returns 0 for Julia
Imagine you've been taught addition and multiplication, but never learned any numbers higher than 99. As far as you're concerned, numbers bigger than that simply don't exist. So you learned to carry ones into the tens column, but you don't even know what you'd call the column you'd carry tens into. So you just drop them. As long as your numbers never get bigger than 99, everything will be just fine. Once you go over 99, you wrap back down to 0. So 99+3 ≡ 2 (mod 100). And 52*9 ≡ 68 (mod 100). Any time you do a multiplication with more than two factors of 10, your answer will be zero: 25*32 ≡ 0 (mod 100). Now, after you do each computation, someone could ask you "did you go over 99?" But that takes time to answer… time that could be spent computing your next math problem!
This is effectively how computers natively do arithmetic, except they do it in binary with 64 bits. You can see the individual bits with the bits function:
julia> bits(45)
"0000000000000000000000000000000000000000000000000000000000101101"
As we multiply it by 2, 101101 will shift to the left (just like multiplying by 10 in decimal):
julia> bits(45 * 2)
"0000000000000000000000000000000000000000000000000000000001011010"
julia> bits(45 * 2 * 2)
"0000000000000000000000000000000000000000000000000000000010110100"
julia> bits(45 * 2^58)
"1011010000000000000000000000000000000000000000000000000000000000"
julia> bits(45 * 2^60)
"1101000000000000000000000000000000000000000000000000000000000000"
… until it starts falling off the end. If you multiply more than 64 twos together, the answer will always zero (just like multiplying more than two tens together in the example above). We can ask the computer if it overflowed, but doing so by default for every single computation has some serious performance implications. So in Julia you have to be explicit. You can either ask Julia to check after a specific multiplication:
julia> Base.checked_mul(45, 2^60) # or checked_add for addition
ERROR: OverflowError()
in checked_mul at int.jl:514
Or you can promote one of the arguments to a BigInt:
julia> bin(big(45) * 2^60)
"101101000000000000000000000000000000000000000000000000000000000000"
In your example, you can see that the answer is 1 followed by 81 zeros when you use big integer arithmetic:
julia> bin(big(2) ^ 3 ^ 4)
"1000000000000000000000000000000000000000000000000000000000000000000000000000000000"
For more details, see the FAQ: why does julia use native machine integer arithmetic?
I was wondering if there is any formula or way to find out much maximum bits will be required if two n bits binary number are multiplied.
I searched a lot for this but was unable to find its answer anywhere.
Number of digits in base B required for representing a number N is floor(log_B(N)+1). Logarithm has this nice property that log(X*Y)=log(X)+log(Y), which hints that the number of digits for X*Y is roughly the sum of the number of digits representing X and Y.
It can be simply concluded using examples:
11*11(since 11 is the maximum 2 bit number)=1001(4 bit)
111*111=110001(6 bit)
1111*1111=11100001(8 bit)
11111*11111=1111000001(10 bit)
and so from above we can see your answer is 2*n
The easiest way to think about this is to consider the maximum of the product, which is attained when we use the maximum of the two multiplicands.
If value x is an n-bit number, it is at most 2^n - 1. Think about this, that 2^n requires a one followed by n zeroes.
Thus the largest possible product of two n-bit numbers will be:
(2^n - 1)^2 = 2^(2n) - 2^(n+1) + 1
Now n=1 is something of a special case, since 1*1 = 1 is again a one-bit number. But in general we see that the maximum product is a 2n-bit number, whenever n > 1. E.g. if n=3, the maximum multiplicand is x=7 and the square 49 is a six-bit number.
It's worth noting that the base of the positional system doesn't matter. Whatever formula you come up with for the decimal multiplication will work for the binary multiplication.
Let's apply a bit of deduction and multiply two numbers that have relatively prime numbers of digits: 2 and 3 digits, respectively.
Smallest possible numbers:
10 * 100 = 1000 has 4 digits
Largest possible numbers:
99 * 999 = 98901 has 5 digits
So, for a multiplication of n-digit by m-digit number, we deduce that the upper and lower limits are n+m and n+m-1 digits, respectively. Let's make sure it holds for binary as well:
10 * 100 = 1000 has 4 digits
11 * 111 = 10101 has 5 digits
So, it does hold for binary, and we can expect it to hold for any base.
x has n binary digits means that 2^(n-1) <= x < 2^n, also assume that y has m binary digits. That means:
2^(m+n-2)<=x*y<2^(m+n)
So x*y can have m+n-1 or m+n digits. It easy to construct examples where both cases are possible:
m+n-1: 2*2 has 3 binary digits (m = n = 2)
m+n: 7*7=49=(binary)110001 has 6 binary digits and m = n = 3
The 2's complement of a number which is represented by N bits is 2^N-number.
For example: if number is 7 (0111) and i'm representing it using 4 bits then, 2's complement of it would be (2^N-number) i.e. (2^4 -7)=9(1001)
7==> 0111
1's compliment of 7==> 1000
1000
+ 1
-------------
1001 =====> (9)
While calculating 2's complement of a number, we do following steps:
1. do one's complement of the number
2. Add one to the result of step 1.
I understand that we need to do one's complement of the number because we are doing a negation operation. But why do we add the 1?
This might be a silly question but I'm having a hard time understanding the logic. To explain with above example (for number 7), we do one's complement and get -7 and then add +1, so -7+1=-6, but still we are getting the correct answer i.e. +9
Your error is in "we do one's compliment and get -7". To see why this is wrong, take the one's complement of 7 and add 7 to it. If it's -7, you should get zero because -7 + 7 = 0. You won't.
The one's complement of 7 was 1000. Add 7 to that, and you get 1111. Definitely not zero. You need to add one more to it to get zero!
The negative of a number is the number you need to add to it to get zero.
If you add 1 to ...11111, you get zero. Thus -1 is represented as all 1 bits.
If you add a number, say x, to its 1's complement ~x, you get all 1 bits.
Thus:
~x + x = -1
Add 1 to both sides:
~x + x + 1 = 0
Subtract x from both sides:
~x + 1 = -x
The +1 is added so that the carry over in the technique is taken care of.
Take the 7 and -7 example.
If you represent 7 as 00000111
In order to find -7:
Invert all bits and add one
11111000 -> 11111001
Now you can add following standard math rules:
00000111
+ 11111001
-----------
00000000
For the computer this operation is relatively easy, as it involves basically comparing bit by bit and carrying one.
If instead you represented -7 as 10000111, this won't make sense:
00000111
+ 10000111
-----------
10001110 (-14)
To add them, you will involve more complex rules like analyzing the first bit, and transforming the values.
A more detailed explanation can be found here.
Short answer: If you don't add 1 then you have two different representations of the number 0.
Longer answer: In one's complement
the values from 0000 to 0111 represent the numbers from 0 to 7
the values from 1111 to 1000 represent the numbers from 0 to -7
since their inverses are 0000 and 0111.
There is the problem, now you have 2 different ways of writing the same number, both 0000 and 1111 represent 0.
If you add 1 to these inverses they become 0001 and 1000 and represent the numbers from -1 to -8 therefore you avoid duplicates.
I'm going to directly answer what the title is asking (sorry the details aren't as general to everyone as understanding where flipping bits + adding one comes from).
First let motivate two's complement by recalling the fact that we can carry out standard (elementary school) arithmetic with them (i.e. adding the digits and doing the carrying over etc). Easy of computation is what motivates this representation (I assume it means we only 1 piece of hardware to do addition rather than 2 if we implemented subtraction differently than addition, and we do and subtract differently in elementary school addition btw).
Now recall the meaning of each of the digit's in two's complements and some binary numbers in this form as an example (slides borrowed from MIT's 6.004 course):
Now notice that arithmetic works as normal here and the sign is included inside the binary number in two's complement itself. In particular notice that:
1111....1111 + 0000....1 = 000....000
i.e.
-1 + 1 = 0
Using this fact let's try to derive what the two complement representation for -A should be. So the problem to solve is:
Q: Given the two's complement representation for A what is the two's complement's representation for -A?
To do this let's do some algebra using values we know:
A + (-A) = 0 = 1 + (-1) = 11...1 + 00000...1 = 000...0
now let's make -A the subject expressed in terms of numbers expressed in two's complement:
-A = 1 + (-1 - A) = 000.....1 + (111....1 - A)
where A is in two's complements. So what we need to compute is the subtraction of -1 and A in two's complement format. For that we notice how numbers are represented as a linear combination of it's bases (i.e. 2^i):
1*-2^N-1 + 1 * 2^N-1 + ... 1 = -1
a_N * -2^N-1 + a_N-1 * 2^N-1 + ... + a_0 = A
--------------------------------------------- (subtract them)
a_N-1 * -2^N-1 + a_N-1 -1 * 2^N-1 + ... + a_0 -1 = A
which essentially means we subtract each digit for it's corresponding value. This ends up simply flipping bits which results in the following:
-A = 1 + (-1 - A) = 1 + ~ A
where ~ is bit flip. This is why you need to bit flip and add 1.
Remark:
I think a comment that was helpful to me is that complement is similar to inverse but instead of giving 0 it gives 2^N (by definition) e.g. with 3 bits for the number A we want A+~A=2^N so 010 + 110 = 1000 = 8 which is 2^3. At least that clarifies what the word "complement" is suppose to mean here as it't not just the inverting of the meaning of 0 and 1.
If you've forgotten what two's complement is perhaps this will be helpful: What is “2's Complement”?
Cornell's answer that I hope to read at some point: https://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html#whyworks
Using boolean algebra (not a specific language implementation), can we evaluate 1 ^ 1 + 1 (or 1 XOR 1 OR 1) unambiguously?
I can derive two evaluations:
[I]: (1 ^ 1) + 1 = 0 + 1 = 1
[II]: 1 ^ (1 + 1) = 1 ^ 1 = 0
Perhaps there's some stated order of operations, or of a left-to-right evaluation? Or is this not defined in Boolean algebra?
We can use the rules of boolean algebra to attempt to evaluate the expression 1 XOR 1 OR 1.
Now:
XOR is derived from OR such that A XOR B = (¬A AND B) OR (¬B AND A);
Associativity tells us that A OR (B OR C) = (A OR B) OR C;
Associativity also tells us that A AND (B AND C) = (A AND B) AND C
So, taking either of the possible interpretations of evaluation order:
(1 XOR 1) OR 1 1 XOR (1 OR 1)
Even though we have no left-to-right "evaluation order" defined, these rules are all we need to show that the two possible interpretations are not equivalent:
= (¬1 AND 1) OR (¬1 AND 1) OR 1 = (¬1 AND (1 OR 1)) OR (¬(1 OR 1) AND 1)
= (0 AND 1) OR (0 AND 1) OR 1 = (0 AND 1) OR (0 AND 1)
= 0 OR 0 OR 1 = 0 OR 0
= 1 = 0
Unless I'm forgetting some crucially pertinent axiom, I've confirmed that you need more context to evaluate the given expression.
(And, of course, examining the expression A XOR B OR C ∀A,B,C is of course substantially more tricky! But if the expression is ambiguous for just one value of all three inputs, then why bother checking for any others?)
This context is usually provided in language-specific evaluation-order rules. C-type languages give XOR a low precedence (something Richie came to dislike); by contrast, mathematical convention dictates a left-to-right associativity where no other axiom can be applied and an ambiguity is otherwise present.
So, basically, since we're ignoring language-specific rules, you'd probably go with [I].
Most languages would do XOR then OR; experienced coders will put parentheses in anyway just to make the intent clear.
Many more modern languages do what's called fast- or short-circuit- evaluation, so 0 & ? is always 0, so ? will not be evaluated; same with 1 + ?.
I don't think there is a generally agreed upon order of precedence with logical operators. The evaluation would be entirely specific to a language.
In c# for instance, the Operator precedence for bitwise operators is:
AND
XOR
OR
But this might be different for another language. If the precedence is the same, then the operations are executed from left to right. There is no logical XOR operator, but you can use NOT EQUAL (!=) instead.