This question already has answers here:
Division of integers returns 0
(2 answers)
Closed 10 months ago.
My goal is two divide two integers in Presto 0.212, e. g. 1/2. The naive approach SELECT 1/2 returns 0. Next, I tried SELECT CAST(1/2 AS DOUBLE), but this also returns 0. How to divide 1/2 such that 0.5 is returned?
I'm not familiar with Presto, but my guess is that in the example you've provided 1/2 is being evaluated as an integer then is being cast as a double. Maybe something along the lines of SELECT CAST(1 AS DOUBLE)/CAST(2 AS DOUBLE) or you maybe you could just add .0 to the end of your numbers like SELECT 1.0/2.0. Just a few shots in the dark from me.
Related
In sql server when I do select 1 / 2 it returns 0 in stead of 0.5
Why is that?
Should not all divisions return a decimal value?
Is there a setting I can set to make it divide normal?
I noticed the same in c#
What is the logic behind this?
Integer division
select 1 / 2
-- 0
Float division (at least one argument have to be float/decimal):
select 1 / 2.0
-- 0.5
select 1.0 / 2
-- 0.5
select 1.0 / 2.0
-- 0.5
Divide
If an integer dividend is divided by an integer divisor, the result is
an integer that has any fractional part of the result truncated.
EDIT:
The point is you ask why?
Becasue creator of language decided so, history, convention whatsoever.
I suggest read Is integer division uniquely defined in mathematics?.
Keep in mind that in some languages you have 2 division operators (one for integer division and one for real division).
Division Integer
Dividing integers in a computer program requires special care. Some
programming languages, such as C, treat integer division as in case 5
above, so the answer is an integer. Other languages, such as MATLAB
and every computer algebra system return a rational number as the
answer, as in case 3 above. These languages also provide functions to
get the results of the other cases, either directly or from the result
of case 3.
Names and symbols used for integer division include div, /, \, and %.
Definitions vary regarding integer division when the dividend or the
divisor is negative: rounding may be toward zero (so called
T-division) or toward −∞ (F-division); rarer styles can occur – see
Modulo operation for the details.
For downvoters leave a comment so I can reply/improve my answer.
This question already has answers here:
Why dividing two integers doesn't get a float? [duplicate]
(7 answers)
Closed 9 years ago.
I'm working with an iOS project where I have to do a bit of math. Can anyone explain to me why these two implementations return different results?
float total = 31/30;
NSLog(#"%f", total); // returns 1.00000 in console
float total2 = 31/30.0;
NSLog(#"%f", total2); // returns 1.03333 in console
In the majority of computer languages, division involving two integers will have an integer result, the floor of the real result.
In C division, the type of the result is the type of the most precise number in the calculation. In your first example, both 31 and 30 are integers, and so the result is then the integer 1 which is cast to a float to result in 1.00. In your second example, while 31 is an integer, 30.0 is a literal float, and the calculation has a float result, which is than stored in your variable (1.033333...).
This question already has answers here:
Objective c division of two ints
(4 answers)
Closed 9 years ago.
I tried to calculate 4/3 and store it into a float.
float answer = 4/3;
This only returns 1. Isn't objective-c able to calculate these kinds of fractions or do I have to do it any other way?
If numerator and denominator are both integers, then division will be integer. Use
float answer = 4/(float)3
4 and 3 are integers. So that division is an integer division, which evaluates to 1.
If you want a floating-point division, use (at least one) float literal.
float answer = 4f/3;
Your assignment contains an integer divide, which returns zero if the number you are dividing by is greater. You probably meant to do:
float p1 = (4.0f / 3.0f);
or
float p1 = ((float)4 / 3);
I have a problem when i'm trying to calculate in a view a formula whose result is smaller than 1.
e.g. I have the next formula: Arenda*TotalArea/10000 as TotalArenda
If I have Arenda=10 and TotalArea=10 I get TotalArenda=0,00 when normally should be 0.01
Thanks
Make Arenda = 10.0 and TotalArea = 10.0 instead of 10 and 10. This will force SQL not to use integer math and you will get your needed accuracy.
In fact, the only way I can get 0.0 as the result is if the Arenda is 10 (integer) while at least one of TotalArea or 10000 contain a decimal and a trailing 0, and only if I override order of operations by grouping using parentheses such as
select 10.0* (10/10000) as blah
If all are integers you get 0. If all contain decimals you get 0.01. If I remove the parentheses, I get 0.01 if ANY of them are non-integer types.
If precision is highly important I would recommend you cast to decimals and not floats:
select CONVERT(decimal(10,2), Arenda) * CONVERT(decimal(10,2), TotalArea) / 10000.0
You are using colunns, so changing the type may not be feasible. SQL Server does integer division on integers (other databases behave differently). Try one of these:
cast(Arenda as float)*cast(TotalArea as float)/10000
or:
Arenda*TotalArea/10000.0
I am doing this small exercise.
declare #No decimal(38,5);
set #No=12345678910111213.14151;
select #No*1000/1000,#No/1000*1000,#No;
Results are:
12345678910111213.141510
12345678910111213.141000
12345678910111213.14151
Why are the results of first 2 selects different when mathematically it should be same?
it is not going to do algebra to convert 1000/1000 to 1. it is going to actually follow the order of operations and do each step.
#No*1000/1000
yields: #No*1000 = 12345678910111213141.51000
then /1000= 12345678910111213.141510
and
#No/1000*1000
yields: #No/1000 = 12345678910111.213141
then *1000= 12345678910111213.141000
by dividing first you lose decimal digits.
because of rounding, the second sql first divides by 1000 which is 12345678910111.21314151, but your decimal is only 38,5, so you lose the last three decimal points.
because when you divide first you get:
12345678910111.21314151
then only six decimal digits are left after point:
12345678910111.213141
then *1000
12345678910111213.141
because the intermediary type is the same as the argument's - in this case decimal(38,5). so dividing first gives you a loss of precision that's reflected in the truncated answer. multiplying by 1000 first doesn't give any loss of precision because that doesn't overload 38 digits.
It's probably because you lose part of data making division first. Notice that #No has 5-point decimal precision so when you divide this number by 1000 you suddenly need 8 digits for decimal part:
123.12345 / 1000 = 0.12312345
So the value has to be rounded (0.12312) and then this value is multiply by 1000 -> 123.12 (you lose 0.00345.
I think that's why the result is what it is...
The first does #No*1000 then divides it by 1000. The intermediates values are always able to represent all the decimal places. The second expression first divides by 1000, which throws away the last two decimal places, before multiplying back to the original value.
You can get around the problem by using CONVERT or CAST on the first value in your expression to increase the number of decimal places and avoid a loss of precision.
DECLARE #num decimal(38,5)
SET #num = 12345678910111213.14151
SELECT CAST(#num AS decimal(38,8)) / 1000 * 1000