I have some code that I wrote up that will successfully return me a binary number. For example, running the code below with an input of 101 will return 5. However, the problem arises when I add 0 bits to the left of MSB, thus not changing the value. When I input 0101 into the system, I should expect 5 to be returned again, but it returns 17 instead.
Here is my code:
int dec1 = 0, rem1=0, num1, base1 = 1;
int a = 101;
while (a > 0){
rem1 = a % 10;
dec1 = dec1 + (rem1 * base1);
base1 = base1 * 2;
a = a / 10;
}
cout << dec1 << endl;
The output of this is 5. Correct.
However, when 'a' is changed to 0101, the output becomes 17. I believe my error has to do with a misunderstanding of the modulo operator.
101%10 = 1 right? Does the compiler typically read 0101%10 the same way?
I added a cout statement to my code to see what value is stored in rem1 after the value of 0101%10 is calculated.
int dec1 = 0, rem1=0, num1, base1 = 1;
int a = 101;
while (a > 0){
rem1 = a % 10;
cout << rem1 << endl;
dec1 = dec1 + (rem1 * base1);
base1 = base1 * 2;
a = a / 10;
}
cout << dec1 << endl;
From this, I was able to see that right after 0101%10 is calculated, a value of 5 is stored in rem1, instead of 1.
Does adding this 0 in front of the MSB tell the compiler "hey, this number is in binary?" because if the compiler is reading 5%10 instead of 0101%10, then I guess the error makes sense.
Upon testing my theory, I changed 'a' to 1000 and the output was 8, which is correct.
Changing 'a' to 01000 gives a result of 24. rem1= 01000%10 should be 0, however rem1 is storing 2. 01000 binary = 8 decimal. 8%10=8? not 2?
I'm an unsure of what is going on and any help is appreciated!
101 is parsed as a decimal (base 10) number, so you get your expected output.
0101 is parsed as an octal (base 8) number due to the leading zero. The leading zero here works just like the leading 0x prefix that denotes a hexadecimal (base 16) number, except that without the x it's base 8 instead of base 16.†
1018 = 82 + 80 = 64 + 1 = 65
65 % 10 = 5
65 / 10 = 6
6 % 10 = 7
5 * 2 + 7 = 17
If I were you, I'd add an assert(rem1 == 0 || rem1 == 1) inside your loop right after your assignment to rem1 as a sanity check. If you ever get a remainder larger than one or less than zero then there's obviously something wrong.
As rbaleksandar points out in his comment above, the easiest way to avoid this issue is probably to store your input as a c-string (char[]) rather than using an integer literal. This is also nice because you can just iterate over the characters to compute the value instead of doing % and / operations.
Alternatively, you could use hex literals (e.g., 0x101 or 0x0101) for all of your inputs, and change your math to use base 16 instead of base 10. This has the added advantage that base 10 division and remainder functions can be optimized by the compiler into much cheaper bit-shift and bit-mask operations since 16 is a power of 2. (E.g., 0x101 % 16 ==> 0x101 & 15, and 0x101 / 16 ==> 0x101 >> 4).
† For more info
see http://en.cppreference.com/w/cpp/language/integer_literal
0101 is Octal number, which value is 17.
Input :
cout << (4 % ((10^9)+1) );
Output :
0
Compiler : g++ 4.8.4
I don't know why the compiler printing the value is 0. What i have to do now for expected output?
What is the correct code to print the output?
^ is a bitwise exclusive OR operation, not exponentation. 10 ^ 9 is 3.
So 4 % ((10 ^ 9) + 1) = 4 % (3 + 1) = 4 % 4 = 0. The compiler is correct.
Did you mean std::pow(10L, 9L), taking care not to overflow an integral type? Then the answer would be 4 (although you would have to cast the return of std::pow to an appropriate integral type for the % operator).
((10^9)+1) = 4
4 % 4 = 0
The % operator returns the remainder of the division. Example, 4/3 = 0 and 3 as remainder so it will return 3, but 4/4 = 1 and no remainder, so it returns 0.
The compiler shows the correct answer.
(10^9) = 3
((3) + 1) = 4
4 % (4)= 0
The modulus (%) operator returns the remainder after a divison. See this page for a tutorial on the modulus operator.
Thank you for explaining this logic. I have understood this logic with your help and here is the solution for this logic that i got solved.
cout << (4 % ((10^9)+1) ); ==> cout <<fmod(5, (pow(10,9)+1));
My mistake is used ^ instead of pow() and % instead of fmod().
^ operator is bitwise xor in C++. (Just now realised afer your comments. Thanks for the info guys).
% operator is for integers. So, i have used fmod() function. Because my calculation need more than integer type.
I don't know why the compiler printing the value is 0. What i have to
do now for expected output?
(10^9) == 3
^ operator is bitwise xor in C++. That is, in binary
decimal binary
10 0110
9 0101
0110 ^ 0101 == 0011
and thus:
10^9 == 3
Consequently:
(10^9) + 1 == 4
and
4 % ((10^9) + 1) == 0
I don't want someone to explain how the following code works (it checks whether an int is pandigital) as I should be doing that myself. I just need help understanding line 8 specifically. I don't know what the | is doing.
private bool isPandigital(long n) {
int digits = 0;
int count = 0;
int tmp;
while (n > 0) {
tmp = digits;
digits = digits | 1 << (int)((n % 10) - 1);
if (tmp == digits) {
return false;
}
count++;
n /= 10;
}
return digits == (1 << count) - 1;
}
I know others have already explained that it's a bitwise OR, but I'd like to give my own interpretation.
digits = digits | X will copy all the 1 bits from X into digits.
digits = digits | 1 << Y will "set" a single bit in digits - it will set the Yth bit.
So, each loop sets a bit in digits.
| is bitwise or. But the code checks whether an int of length n has all digits 1..n. This is different from palindrome check. That line sets's (i-1)'th bit of digits to 1 if the last digit of n is i. [BTW, the code is wrong: if n contains a zero-digit, that line will trigger "undefined behavior": shifting an integer by a negative amount gives an undefined result.]
The code uses an integer digits to represent a set of digits. You can learn more about the technique by searching for bit sets.
It appears to be performing a Bitwise Or.
| is a bitwise OR
A bitwise OR takes two bit patterns of equal length and performs the logical inclusive OR operation on each pair of corresponding bits. The result in each position is 1 if the first bit is 1 OR the second bit is 1 OR both bits are 1; otherwise, the result is 0.
Example:
10010000
01010000
--------
11010000
http://en.wikipedia.org/wiki/Bitwise_operation
| is a bitwise or.
So the line is doing digits = digits | (1 << (int)((n % 10) - 1));
The problem is to derive a formula for determining number of digits a given decimal number could have in a given base.
For example: The decimal number 100006 can be represented by 17,11,9,8,7,6,8 digits in bases 2,3,4,5,6,7,8 respectively.
Well the formula I derived so far is like this : (log10(num) /log10(base)) + 1.
in C/C++ I used this formula to compute the above given results.
long long int size = ((double)log10(num) / (double)log10(base)) + 1.0;
But sadly the formula is not giving correct answer is some cases,like these :
Number 8 in base 2 : 1,0,0,0
Number of digits: 4
Formula returned: 3
Number 64 in base 2 : 1,0,0,0,0,0,0
Number of digits: 7
Formula returned: 6
Number 64 in base 4 : 1,0,0,0
Number of digits: 4
Formula returned: 3
Number 125 in base 5 : 1,0,0,0
Number of digits: 4
Formula returned: 3
Number 128 in base 2 : 1,0,0,0,0,0,0,0
Number of digits: 8
Formula returned: 7
Number 216 in base 6 : 1,0,0,0
Number of digits: 4
Formula returned: 3
Number 243 in base 3 : 1,0,0,0,0,0
Number of digits: 6
Formula returned: 5
Number 343 in base 7 : 1,0,0,0
Number of digits: 4
Formula returned: 3
So the error is by 1 digit.I just want somebody to help me to correct the formula so that it work for every possible cases.
Edit : As per the input specification I have to deal with cases like 10000000000, i.e 10^10,I don't think log10() in either C/C++ can handle such cases ? So any other procedure/formula for this problem will be highly appreciated.
There are fast floating operations in your compiler settings. You need precise floation operations. The thing is that log10(8)/log10(2) is always 3 in math. But may be your result is 2.99999, for expample. It is bad. You must add small additive, but not 0.5. It should be about .00001 or something like that.
Almost true formula:
int size = static_cast<int>((log10((double)num) / log10((double)base)) + 1.00000001);
Really true solution
You should check the result of your formula. Compexity is O(log log n) or O(log result)!
int fast_power(int base, int s)
{
int res = 1;
while (s) {
if (s%2) {
res*=base;
s--;
} else {
s/=2;
base*=base;
}
}
return res;
}
int digits_size(int n, int base)
{
int s = int(log10(1.0*n)/log10(1.0*base)) + 1;
return fast_power(base, s) > n ? s : s+1;
}
This check is better than Brute-force test with base multiplications.
Either of the following will work:
>>> from math import *
>>> def digits(n, b=10):
... return int(1 + floor(log(n, b))) if n else 1
...
>>> def digits(n, b=10):
... return int(ceil(log(n + 1, b))) if n else 1
...
The first version is explained at mathpath.org. In the second version the + 1 is necessary to yield the correct answer for any number n that is the smallest number with d digits in base b. That is, those numbers which are written 10...0 in base b. Observe that input 0 must be treated as a special case.
Decimal examples:
>>> digits(1)
1
>>> digits(9)
1
>>> digits(10)
2
>>> digits(99)
2
>>> digits(100)
3
Binary:
>>> digits(1, 2)
1
>>> digits(2, 2)
2
>>> digits(3, 2)
2
>>> digits(4, 2)
3
>>> digits(1027, 2)
11
Edit: The OP states that the log solution may not work for large inputs. I don't know about that, but if so, the following code should not break down, because it uses integer arithmetic only (this time in C):
unsigned int
digits(unsigned long long n, unsigned long long b)
{
unsigned int d = 0;
while (d++, n /= b);
return d;
}
This code will probably be less efficient. And yes, it was written for maximum obscurity points. It simply uses the observation that every number has at least one digit, and that every divison by b which does not yield 0 implies the existence of an additional digit. A more readable version is the following:
unsigned int
digits(unsigned long long n, unsigned long long b)
{
unsigned int d = 1;
while (n /= b) {
d++;
}
return d;
}
Number of digits of a numeral in a given base
Since your formula is correct (I just tried it), I would think that it's a rounding error in your division, causing the number to be just slightly less than the integer value it should be. So when you truncate to an integer, you lose 1. Try adding an additional 0.5 to your final value (so that truncating is actually a round operation).
What you want is ceiling ( = smallest integer not greater than) logb (n+1), rather than what you're calculating right now, floor(1+logb(n)).
You might try:
int digits = (int) ceil( log((double)(n+1)) / log((double)base) );
As others have pointed out, you have rounding error, but the proposed solutions simply move the danger zone or make it smaller, they don't eliminate it. If your numbers are integers then you can verify -- using integer arithmetic -- that one power of the base is less than or equal to your number, and the next is above it (the first power is the number of digits). But if you use floating point arithmetic anywhere in the chain then you will be vulnerable to error (unless your base is a power of two, and maybe even then).
EDIT:
Here is crude but effective solution in integer arithmetic. If your integer classes can hold numbers as big as base*number, this will give the correct answer.
size = 0, k = 1;
while(k<=num)
{
k *= base;
size += 1;
}
Using your formula,
log(8)/log(2) + 1 = 4
the problem is in the precision of the logarithm calculation. Using
ceil(log(n+1)/log(b))
ought to resolve that problem. This isn't quite the same as
ceil(log(n)/log(b))
because this gives the answer 3 for n=8 b=2, nor is it the same as
log(n+1)/log(b) + 1
because this gives the answer 4 for n=7 b=2 (when calculated to full precision).
I actually get some curious resulting implementing and compiling the first form with g++:
double n = double(atoi(argv[1]));
double b = double(atoi(argv[2]));
int i = int(std::log(n)/std::log(b) + 1.0);
fails (IE gives the answer 3), while,
double v = std::log(n)/std::log(b) + 1.0;
int i = int(v);
succeeds (gives the answer 4). Looking at it some more I think a third form
ceil(log(n+0.5)/log(b))
would be more stable, because it avoids the "critical" case when n (or n+1 for the second form) is an integer power of b (for integer values of n).
It may be beneficial to wrap a rounding function (e.g. + 0.5) into your code somewhere: it's quite likely that the division is producing (e.g.) 2.99989787, to which 1.0 is added, giving 3.99989787 and when that's converted to an int, it gives 3.
Looks like the formula is right to me:
Number 8 in base 2 : 1,0,0,0
Number of digits: 4
Formula returned: 3
log10(8) = 0.903089
log10(2) = 0.301029
Division => 3
+1 => 4
So it's definitely just a rounding error.
Floating point rounding issues.
log10(216) / log10(6) = 2.9999999999999996
But you cannot add 0.5 as suggested, because it would not work for the following
log10(1295) = log10(6) = 3.9995691928566091 // 5, 5, 5, 5
log10(1296) = log10(6) = 4.0 // 1, 0, 0, 0, 0
Maybe using the log(value, base) function would avoid these rounding errors.
I think that the only way to get the rounding error eliminated without producing other errors is to use or implement integer logarithms.
Here is a solution in bash:
% digits() { echo $1 $2 opq | dc | sed 's/ .//g;s/.//' | wc -c; }
% digits 10000000000 42
7
static int numInBase(int num, int theBase)
{
if(num == 0) return 0;
if (num == theBase) return 1;
return 1 + numInBase(num/theBase,theBase);
}