Mobile version of this page
Previous:
Overcomplicated password requirements on Oystercard.com
Next:
Pretty print SQL script
Parrot; CLR for the poor man
PostgreSQL, MySQL or SQLite
Adding a year in PostgreSQL
Creating a user for postgresql
Sorting transform function in PostgreSQL
isInt() JavaScript function
Vista voice recognition and Perl
MOBi phonebook into Excel
ALTER TABLE patch
List of casts in PostgreSQL
Running simple SQL commands on the command line
pg_class to check if table exists
Just Oracle and IBM?
Date formatting in Python or in PostgreSQL (part II)
Combining MOBi and EconoAccount
Date formatting in python or in PostgreSQL
Quick PostgreSQL optimization story
Save this page in del.icio.usOvercomplicated password requirements on Oystercard.com
Next:
Pretty print SQL script
Related blogs
Case study where Python was the final choiceParrot; CLR for the poor man
PostgreSQL, MySQL or SQLite
Adding a year in PostgreSQL
Creating a user for postgresql
Sorting transform function in PostgreSQL
isInt() JavaScript function
Vista voice recognition and Perl
MOBi phonebook into Excel
ALTER TABLE patch
List of casts in PostgreSQL
Running simple SQL commands on the command line
pg_class to check if table exists
Just Oracle and IBM?
Date formatting in Python or in PostgreSQL (part II)
Combining MOBi and EconoAccount
Date formatting in python or in PostgreSQL
Quick PostgreSQL optimization story
Related by category
Integer division in programming languages
integer, division, integer/integer, decimal, perl, excel, postgresql
4th of August 2004
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.3
Perl on the other hand returns a decimal number:
print 3/10; print "\n"; print 3/10.0; ...gives... 0.3 0.3
PostgreSQL is like Python:
database=# SELECT 3/10 AS quotient1, 3/10.0 As quotient2;
quotient1 | quotient2
-----------+------------------------
0 | 0.30000000000000000000
And good old MS Excel gives:
=3/10 <=> 0.3
Why is it so?
Comment
Italo Tasso -
31st May 2006
[«« Reply to this]
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.
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.
Flomana -
13th June 2007
[«« Reply to this]
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/
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/
For 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)