I have a degree in mathematics and computer science, but still I don't know why different programming languages evaluate Integer/Integer differently. On any calculator if you divide one integer with another you get a decimal number (of course not if the numerator is a factor of the denominator).
Python for example returns a integer number:
>>> print 3/10
0
>>> print 3/10.0
0.3Perl on the other hand returns a decimal number:
print 3/10; print "\n";
print 3/10.0;
...gives...
0.3
0.3PostgreSQL is like Python:
database=# SELECT 3/10 AS quotient1, 3/10.0 As quotient2;
quotient1 | quotient2
-----------+------------------------
0 | 0.30000000000000000000And good old MS Excel gives:
=3/10 <=> 0.3Why is it so?
Comments
Post your own commentFor Python, the reasons are historical. When it was designed, mathematics and arithmetic were not exactly the focus of attention, and Guido decided to follow how things were done in C when he didn't particularly care one way or the other. That is why division in Python works as in C.
In C, the choice is a more natural one, since it was designed to be a low-level language focused on efficiency. In the early days, this efficiency was achieved largely by providing a close mapping between hardware functionality and language functionality. This meant that you could get good efficiency even with a simple compiler, by leveraging the programmer's intuitions and experience regarding hardware efficiency (with integer arithmetic being much more efficient than floating-point, provided that the latter was supported at all.) Following this principle, the compiler should not automatically slow down things without very good reasons, while automatically moving from fast integers to slow floating-point arithmetic could easily be seen as violating that principle. Also, integer division is sufficient in many cases, especially when used for data organization (subdivision of datasets) rather than mathematics. The creators of C were working on operating systems, compilers, and other kinds of system software were this was true to a large extent. Floating-point arithmetic was included in the language, but in later practice it was often made optional, if at all (especially on small micros and embedded systems.)
For a high-level language focused on ease-of-use for the programmer, automatic conversion between integer and floating-point "where required" makes a lot of sense. So it is not strange that the other languages you mention work that way. Python is going in that direction as well (see e.g. http://python.fyxm.net/peps/pep-0238.html)
Hello Rickard,
This is a great piece of information. I very much liked the way you have explained it.
Thanks for answering a question which was very intriguing for me.
Regards,
Vishruth
Well, there is "real division" and "integer division". They are different.
Calculators do real division. They take a real number, divides it by another real number and return a real number.
In number theory we only work with integers. So we have the integer division. When you divide two numbers, you have the quotient and the remainder.
10 div 3 = 3 (quotient)
10 mod 3 = 1 (remainder)
3 * 3 + 1 = 10
The definition of integer division is: given two numbers a and b, the quotient and remainder or the division of a and b are defined by the formulas:
b*q+r=a
and
0<=r<b
(or 0<=|r|<|b| if dealing with negative numbers)
Perl (as far as I know) does not have a integer division (quotient) operator, but it has a remainder operator. C, Pascal and Python have both operations. But they behave diffent when dealing with negative numbers.
In the definition above, there are two possible values of r, one negative and one positive. In math we always take the positive one, but the languages sometimes take the negative.
C and Pascal (gcc and freepascal to be more specific) truncate the division and then calculate the remainder. Python and Perl, on the other hand, use the floor function instead of truncating. This causes differences in the quotient and remainder when dealing with negative integer division. For example, dividing 3 by (-2):
a = 3, b = -2
b*q+r=a
(-2) * q + r = 3
0<=|r|<2
Two possible solutions:
q=-2
r=-1
(-2) * (-2) + (-1) = 3
or
q=-1
r=1
(-2) * (-1) + (1) = 3
Both are correct. In this case, Perl and Python choose the first one (negative remainder) but Pascal and C choose the second one (positive remainder). On the other hand, if you make a=-3 and b=2, Perl and Python choose the positive r, Pascal and C choose the negative r.
Problem dividing variable of integers numbers in Python, for percentage. Solution: product between one variable by 0,1 :
print(... ), SOLA/SOLB * 100 #being SOLA < SOLB Result: 0 #
Solution
print(... ), int(SOLA/(SOLB*1.0) *100, ("%")
Blog: http://flomana.spaces.live.com/
There are more than just 2 division operators: there's floor, ceil, real and and floating point. Floor and ceil division are both integer valued and differ only for negative results. Unsurprisingly, floor division is equivalent to real division rounded down and ceil to real division rounded up. As Rickard says, which division operator(s) a language supports depends on the language's purpose.
These days (from version 2.2), Python supports both floor division & floating point division with the '//' and '/' operators, respectively. In python 2.X, you have to import the division feature from __future__ to get this behavior.
from __future__ import division
# prints '0.5 0'
print 1/2, 1//2
In Python integer division why does -7/10 == -1 and not 0?
That's a really good question. I honestly don't know the answer.
If you do -7/float(10) what's the answer?
That's very different. That's -7/10.0 which is something else.
For beauty and symmetry. Observe:
>>> [n/10 for n in range(-30, 30)]
[-3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -2, -2, -2, -2, -2, -2, -2, -2, -2, -2, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2]
The operation n/10 results, over the integers, in runs of exactly 10 identical results, followed by the next integer. If -7/10 had the terrible result of 0, then the above sequence would have 20 zeros in a row instead of 10, making that single number an anomaly in what is otherwise a perfectly symmetrical sequence.
That's nice but a strangely beautiful and weird explanation.
In general, when an integer n is divided by an integer d to obtain an integer quotient q and an integer remainder r, the numbers are related as follows: n = dq + r. Python requires the integer remainder of an integer division by a positive integer to be positive, which agrees with the mathematical definition of modulus in number theory. When -7 is divided by 10, the only way to achieve this is for the remainder to be 3 and the quotient to be -1 because -7 = (10)(-1) + 3.
Thank you!
Two integers from "Big Date" produce a rational quotient, but not immediately obvious: 11,427,680,865,484,800/948,109,639,680 where the denominator is the famous Jarvis No. (see: www.afjarvis.staff.shef.ac.uk/sudoku/ed44.html). The answer is 12,053.1216931. Fortran has a remainder out to 12 digits. My 1st thought was the ans. might be irrational (transcendental. that is), but my ancient, 21-year old HP 48GX calculator gave the correct result, confirming rationality. Also, I did find one correct web calculator, but most don't come close. There is a greatest common divisor, namely 5,016,453,120, which reduces the fraction to much lower terms: 2,278,040/189 = 12,053.1216931.
Best regards, Bearcat
Please allow me to clarify what I had to say in my post earlier this morning. In their Mathematics Dictionary, under “IRRATIONAL”, James & James say: “irrational number. A real number not expressible as an integer or quotient of integers; a nonrational number.” I’m sure I learned that somewhere in the past, but when I saw all of Fortran’s spurious digits following the decimal point I got carried away, forgot the fundamentals, and tended to think Fortran was correct. I hope you many programmers, in whatever language, who have had that experience, will give me a nanograin of sympathy for having expressed my earlier post so poorly. Of course I learned (mainly through trial and error) that my real quotient was required to terminate by virtue of its very existence as a "quotient of integers". However, I must confess, I failed to see that initially. Sorry about that. Incidentally, I would be interested to see how other languages, like Python, Perl, etc., would handle this "Big Data" fraction.
Regards, Bearcat
OK, I give up! I finally decided to work that big fraction out by hand (which I should have done in the 1st place ,instead of trying to subject it to some sort of crazy rationality!). The answer appears to be 12,053. [121693][121693][121693]...... with the 6-digit sequence [121693] going on forever (repeating indefinitely). Again I say: "sorry about that!"
Regards,
Bearcat
Hi everyine I am trying to create a pic slideshoe in html5 with javascript. I thought that If I use the modulus and classes form number theory I can create a loop that automaticaly rotates the pics.
Something like that. I have an array of 6 pics for example x = [0 1 2 3 ...6] and a counter i=0; then i++ etc. If the counter goes i = 8 then I want the function to understand that I want to display the pic from the class of 1. 0 1 2 3 4 5 6
7 8 9 10 11 12 13
14.... can be done with javascript?
in c language the division of -3/2 is -2 but compiler is giving -1 why?
Prior to the 1999 version of C, the result of division was considered compiler-dependent. This left the option to the compiler vendor to decide whether its customers would prefer fast division or consistent division. Division by a compile-time-known value of 2 could be done with an arithmetic right shift of one bit. On a 2s-complement machine, this would correspond to floor behavior; on a 1s complement machine it would correspond to truncation toward 0. Such a bit shift was much faster than actual division. If the divisor was not known to be 2 at compile time, the compiler would generate code to perform an actual division; if the divisor happened to be 2 for a particular division, the result would be truncated to 0. Thus, on a 2s-complement machine, one compiler would be allowed for dividing −7 by 2 to return −4 in some cases and −3 in other cases within one program.
Starting with 1999, C required compilers to perform integer division as truncation toward 0 in order to achieve more predictable behavior.
Another issue is that if one writes code with −7/2, it is treated as −(7/2) which would nearly always be evaluated as −3 regardless of compiler and hardware behavior. That is because in C, − is always a unary operator; there is no such thing as negative integer literals in C. People often forget this detail and are surprised.
ahhhhh.............19 yrs old good old days