When an integer is initialized as int a = 010, a is actually set to 8, but for int a = 10, a is set to 10.
Can anyone tell me why a is not set to 10 for int a = 010?
Because it's interpreting 010 as a number in octal format. And in a base-8 system, the number 10 is equal to the number 8 in base-10 (our standard counting system).
More generally, in the world of C++, prefixing an integer literal with 0 specifies an octal literal, so the compiler is behaving exactly as expected.
0 before the number means it's in octal notation. So since octal uses a base of 8, 010 would equal 8.
In the same way 0x is used for hexadecimal notation which uses the base of 16. So 0x10 would equal 16 in decimal.
In C, C++, Objective C and related languages a 0 prefix signifies an octal literal constant, so 010 = 8 in decimal.
Leading 0 in 010 means that this number is in octal form. So 010 means 8 in decimal.
Related
If double can represent value up to 3.4E308 (308 zeros), then why do we say that double stores only 15 digits? What is point of saying "ten power of 308" ?
We don't say that "double stores only 15 digits". We say that "double has 15 digits of precision". It means that the computed value of double, when printed as a base-10 sequence of digits, is accurate only up to those 15 digits.
double can represent 3.4E308. Yes, to print it you need more than 15 digits of precision. Some particular values have those guarantees thanks to floating-point implementation. But, for example, a number 3.4E308 - 1, which is inside of double's range, cannot be represented accurately by a double.
If you want to be sure, just take the first 15 digits of double. Some values can be correctly represented with more than 15 digits, but some cannot. Every value in double's range will be correctly represented up to the 15th digit of its decimal representation.
To help perceive this in simple terms, consider a number type that can represent following numbers:
-100000
-100
-9
-8
-7
-6
-5
-4
-3
-2
-1
0
+1
+2
+3
+4
+5
+6
+7
+8
+9
+100
+100000
The type can represent numbers up to 100000. Does this type have 6 digits of precision, or 1?
this is the function that returns sum of digits of a given no.
ex: 345 gives 12 (3+4+5)
def digit_sum(n):
s=0
while(n>0):
r=n%10
n=n/10
s=s+r
return s
print digit_sum(0123)
output: 11 instead of 6
Prior to Python 3, 0123 is an octal literal as it starts with a leading 0.
(Its decimal value is 83, and those digits sum to 11.)
This question already has answers here:
What is “two's complement”?
(24 answers)
Closed 7 years ago.
I'm trying to understand why INT_MIN is equal to -2^31 - 1 and not just -2^31.
My understanding is that an int is 4 bytes = 32 bits. Of these 32 bits, I assume 1 bit is used for the +/- sign, leaving 31 bits for the actual value. As such, INT_MAX is equal to 2^31-1 = 2147483647. On the other hand, why is INT_MIN equal to -2^31 = -2147483648? Wouldn't this exceed the '4 bytes' allotted for int? Based on my logic, I would have expected INT_MIN to equal -2^31 = -2147483647
Most modern systems use two's complement to represent signed integer data types. In this representation, one state in the positive side is used up to represent zero, hence one positive value lesser than the negatives. In fact this is one of the prime advantage this system has over the sign-magnitude system, where zero has two representations, +0 and -0. Since zero has only one representation in two's complement, the other state, now free, is used to represent one more number.
Let's take a small data type, say 4 bits wide, to understand this better. The number of possible states with this toy integer type would be 2⁴ = 16 states. When using two's complement to represent signed numbers, we would have 8 negative and 7 positive numbers and zero; in sign-magnitude system, we'd get two zeros, 7 positive and 7 negative numbers.
Bin Dec
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = -8
1001 = -7
1010 = -6
1011 = -5
1100 = -4
1101 = -3
1110 = -2
1111 = -1
I think you are confused since you are imagining that sign-magnitude representation is used for signed numbers; although this is also allowed by the language standards, this system is very less likely to be implemented as two's complement system is significantly a better representation.
As of C++20, only two's complement is allowed for signed integers; source.
This question already has answers here:
What does it mean when a numeric constant in C/C++ is prefixed with a 0?
(7 answers)
Closed 7 years ago.
I am unable to understand output of below mentioned program-
#include <stdio.h>
int main()
{
int i, a[8]={000, 001, 010, 011, 100, 101, 110, 111};
for(i=0;i<8;i++)
{
printf("%d\t",a[i]);
}
system("pause");
return 0;
}
OUTPUT -
0 1 8 9 100 101 110 111
Why are the initial four values getting converted here???
Any integer literal that starts with a 0 followed by other digits is octal, just like any integer literal starting with 0x or 0X, followed by digits, is hexadecimal. C++14 will add 0b or 0B as a prefix for binary integer literals.
See more on integer literals in C++ here.
If you start a number with a 0 it gets converted to an octal number
0xNumber is hex
I have a code in C++ which convert 2 digits octal number to binary number. For testing validity of the code I used several online conversion site like
this and
this
When I enter 58 or 59 in as an octal value it says invalid octal values but when I enter 58 in my code it gives binary number as - 101000. Again for testing I enter 101000 as binary number in above website's calculator then they gives me result 50 as octal value.
I need some explanation why this is so.
Here is the C++ code -
#include <iostream.h>
#include <conio.h>
void octobin(int);
void main()
{
clrscr();
int a;
cout << "Enter a 2-digit octal number : ";
cin>>a;
octobin(a);
getch();
}
void octobin(int oct)
{
long bnum=0;
int A[6];
//Each octal digit is converted into 3 bits, 2 octal digits = 6 bits.
int a1,a2,quo,rem;
a2=oct/10;
a1=oct-a2*10;
for(int x=0;x<6;x++)
{
A[x]=0;
}
//Storing the remainders of the one's octal digit in the array.
for (x=0;x<3;x++)
{
quo=a1/2;
rem=a1%2;
A[x]=rem;
a1=quo;
}
//Storing the remainders of the ten's octal digit in the array.
for(x=3;x<6;x++)
{
quo=a2/2;
rem=a2%2;
A[x]=rem;
a2=quo;
}
//Obtaining the binary number from the remainders.
for(x=x-1;x>=0;x--)
{
bnum*=10;
bnum+=A[x];
}
cout << "The binary number for the octal number " << oct << " is " << bnum << "." << endl;
}
Octal numbers have digits that are all in the range [0,7]. Thus, 58 and 59 are not octal numbers, and your method should be expected to give erroneous results.
The reason that 58 evaluates to 101000 is because the first digit of the octal number expands to the first three digits of the binary number. 5 = 101_2. Same story for the second part, but 8 = 1000_2, so you only get the 000 part.
An alternate explanation is that 8 = 0 (mod 8) (I am using the = sign for congruency here), so both 8 and 0 will evaluate to 000 in binary using your code.
The best solution would be to do some input validation. For example, while converting you could check to make sure the digit is in the range [0,7]
You cannot use 58 or 59 as an input value. It's octal, for Christ's sake.
Valid digits are from 0 to 7 inclusive.
If you're encoding a number in base 8, none of the octets can be 8 or greater. If you're going to do the code octet by octet, there needs to be a test to see whether the octet is 8 or 9, and to throw an error. Right now your code isn't checking this so the 8 and 9 are overflowing to 10.
58 and 59 aren't valid octal values indeed ... the maximum digit you can use is yourbase-1 :
decimal => base = 10 => Digits from 0 t 9
hexadécimal => base = 16 => Digits from 0 to 15 (well, 0 to F)
Octal => base = 8 => Digits from 0 to 7