# What other languages, beside Transact SQL, state that 22/7 is equal to 3? [closed]

I was using Microsoft SQL Query Analyzer the other day and wrote a very simple select statement:

``````SELECT 22/7 as [PI Equiv]
``````

I was suprized that the result was 3, when I was expecting to see 3.1428571. Even if you declare the output to be `Numeric(18,7)`, you still get 3.0000000.

``````DECLARE @Answer Numeric(18,7)
SET @Answer = 22/7
SELECT @Answer as [PI Equiv]

RESULT = 3.0000000
``````

What other languages return integer values when the dividend and divisor are both integers?

-

## closed as too broad by MichaelT, GlenH7, DougM, Ampt, gnatJul 31 '14 at 14:56

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

Weird... what happens if you try `SELECT 22.0/7.0 as [PI Equiv]` ? –  FrustratedWithFormsDesigner Sep 13 '11 at 18:47
When you divide 22/7.0 Transact SQL returns 3.142857. This could be a pitfall if you didn't know about it. –  Michael Riley - AKA Gunny Sep 13 '11 at 18:52
almost all languages return int when both are int, except those who have different operators for division (ex. pascal: 22/7=3.1428571 and 22 div 7=3) –  e-MEE Sep 13 '11 at 18:53
Okay. My point still stands. What you do with the result of the equation (in this case putting it in a type that allows decimals) has no bearing on the way the formula is calculated. 22/7 is being calculated as 3 and then 3 is being cast into the appropriate data type implicitly. You aren't "declaring the output" in your example. You have to change your inputs to 22.0/7.0 to achieve what you are trying to do. –  JohnFx Sep 13 '11 at 19:06
22.0 is an integer. An "integer" is a whole number, a number that is not a fraction. It may not be an "int" or a "smallint" as TSQL defines those types, but it's definitely an integer. –  David Schwartz Sep 13 '11 at 19:43

## 4 Answers

Most languages that supports integer arithmetic will give you 3 from the calculation `22/7`. This includes, C, C++, C#, Ada, Java, etc. The exceptions appear to be Pascal, VB and Lisp that do floating point arithmetic by default.

Languages where you have implicit typing may give you a floating point result instead, though I would check it first.

However, it's bad programming practice and if you mean floating point division you should make at least one of the values explicitly floating point:

``````pi = 22.0 / 7;
``````
-
Almost, but not quite, true. Pascal (for one example) does support integer arithmetic, but `/` always does floating point division; to get integer division you use `div`. Many versions of Lisp do roughly the same as well. –  Jerry Coffin Sep 13 '11 at 19:11
@Jerry - thanks for the extra info. It's been 30 years since I did Pascal ;) –  ChrisF Sep 13 '11 at 19:15
VB would also give you a fraction, to get integer division it would be `22 \ 7`. –  Anthony Pegram Sep 13 '11 at 19:16
If anyone else has any exceptions please feel free to edit them in –  ChrisF Sep 13 '11 at 19:20
@Chris - I started with Pascal and it has always been there. I knew about the div for integer division. It's only recently reared it's head because I ran into a situation where I was building complicated calculations based on interim calculation results and the answers were skewed. –  Michael Riley - AKA Gunny Sep 13 '11 at 19:49

You didn't specifically ask, but I thought I'd add that if you don't want an integer result you do this:

``````SELECT 22/7.0 as [PI Equiv]
``````

or

``````SELECT 22/cast(7 as numeric (18.2)) as [PI Equiv]
``````

Casting an output variable did nothing because the calculation is done before the variable value is set. Division in SQL should explicitly specify that one of the elements is a decimal if you want a decimal result. You also should almost never do a division without a case statement to make sure that the divide by 0 possibility will be handled unless the divisor is a hardcoded value such as the 7 in your calculation.

``````declare @somenumber numeric(18,2)
set @somenumber = 0
SELECT CASE where  @somenumber = 0 then null else 22/@somenumber end as [PI Equiv]
``````
-

In integer arithmetic, the remainder is ignored. This is standard behaviour in most modern languages, initially included in programming languages due to hardware limitations and performance constraints.

For historic and performance reasons, this behaviour is present in most modern languages/platforms; you'll have to go out of your way to find a language which doesn't behave in this manner (examples of exceptions include some experiments with Smalltalk and related).

-
Well, and also done because it makes sense. Most of the time, you want the quotient and not the remainder, and having a basic division operation the returned two values would make the syntax overly complex. –  David Schwartz Sep 13 '11 at 19:23

Python 2.x (without the `-Q new` option or `from __future__ import division`)

``````>>> 22/7
3
``````

bash

``````\$ expr 22 / 7
3
``````

Java

``````class Div{
public static void main( String[] args ) {
int x = 22/7;
System.out.println( "22/7=" + x );
}
}

\$ java Div
22/7=3
``````
-
`s/Python/Python 2.x/` - in Python 3, `/` is always "full" division though - `//` is used for truncating division. –  delnan Sep 13 '11 at 19:00
@delnan: since the question is so bad; we can easily assume that `22//7` is the Python equivalent to the TSQL expression is in the question –  S.Lott Sep 13 '11 at 19:02
@S.Lott - What makes it a bad question? –  Michael Riley - AKA Gunny Sep 13 '11 at 19:04
@Cape Cod Gunny: the use of integer math (`22/7`) leading to an integer result shouldn't lead to an open-ended question like this. It seems like such a simple fact about programming languages. –  S.Lott Sep 13 '11 at 19:06