This question already has answers here:
SQL Server Strange Ceiling() behavior
(2 answers)
Closed 8 years ago.
I've found a really weird behavior in SQL Server 2012, the CEILING of 100 gives me 101 and sometimes 100.
I need to get the ceiling of a number considering 2 decimals, that means convert a 0.254 to 0.26
So I tried to run
SELECT CEILING(field * 100.0) / 100.0
FROM Table
This should work, and it does, at least for most of the data.
Any idea on how to solve it?
What you are seeing here is floating point errors. When you store a number in a floating point column, it isn't exact, so the number 1 may actually be 1.0000000000000000000000001. So multiplying it by 100 gives you a number a tiny bit greater than 100, hence CEILING rounds it up to 101.
The solution is to ROUND the number first which will remove the floating point errors. Note I have used 5 as the number of decimal places, you will need to decide on your own value of precision.
SELECT CEILING(ROUND(field,5)*100.0)/100.0 FROM Table
Related
This question already has answers here:
How to get a float result by dividing two integer values using T-SQL?
(10 answers)
Can`t divide two INTEGERS in SQL Server [duplicate]
(2 answers)
SQL Server, division returns zero
(6 answers)
Closed 11 months ago.
Can anyone show how I do something as simple as round to the nearest integer?
select round((24+24+24)/24,0) result: 3
select round((24+24+23)/24,0) result: 2
select round((24+24+25)/24,0) result: 3
Is there something I can do so all three examples will give me the result 3?
Thank you in advance
The problem is integer division. All of the values are integers, so the 2.9whatever is truncated to just 2 before you even start rounding.
This works just fine by including a floating point value with the division operation:
select round((24+24+24)/24.0,0)
select round((24+24+23)/24.0,0)
select round((24+24+25)/24.0,0)
The other option is always just throw in a bonus hour. Then you don't even need to round:
select (24+24+24+1)/24
select (24+24+23+1)/24
select (24+24+25+1)/24
This question already has answers here:
Integer division in sql server
(8 answers)
Closed 1 year ago.
Why do I get 3 when I execute this T-SQL script:
SELECT 10/3;
I have tried :
SELECT CAST((10/3) AS decimal(5,2));
But now I get 3.00 - still not what I expected
If you are using two integers in a division it will do integer division. You need to cast at least one of the integers to float or decimal before the division to get what you are looking for.
{int}/{int}={int}. SQL Server, or any good language fior that matter, won't implicitly change the data type of a expressions results when only 1 data type is involved (in this case int). Thus 10/3 = 3 is correct.
As for the latter, you still have {int}/{int}={int}, but you then convert the result to a decimal. 3 as a decimal is 3.00 so that too is correct.
You need to convert one of values before you divide; changing the data type of either the dividend or the divisor works. For example:
SELECT (10 * 1.) / 3,
10 / CONVERT(decimal(2,0),3);
I have an Ingres table with following columns
from_date ingresdate
to_date ingresdate
model_amt money
The dates can reflect a period of any number of days, and the model_amt is always a weekly figure. I need to work out the the total model_amt for the period
To do this I need to know how many days are covered by the period, and then divide model_amt by 7, and multiply it by the number of days
however, I am getting incorrect results using the code below
select model_amt, date_part('day',b.to_date - b.from_date),
model_amt / 7 * int4( (date_part('day',b.to_date - b.from_date)) )
from table
For example, where model_amt = 88.82 and the period is for 2 weeks, I get the following output
+-------------------------------------------------------+
¦model_amt ¦col2 ¦col3 ¦
+--------------------+-------------+--------------------¦
¦ #88.82¦ 14¦ #177.66¦
+-------------------------------------------------------+
But 88.82 / 7 * 14 = 177.64, not 177.66?
Any ideas what is going on? The same issue happens regardless of whether I include the int4 function around the date_part.
* Update 15:28 *
The solution was to add a float8 function around the model_amt
float8(model_amt)/ 7 * interval('days', to_date - from_date)
Thanks for the responses.
In computers, floating point numbers are notoriously inaccurate. You can multiply do all kinds of basic mathematics calculations on floating point numbers and they'll be off by a few decimals.
Some information can be found here; but its very googleable :). http://effbot.org/pyfaq/why-are-floating-point-calculations-so-inaccurate.htm
Generally to avoid inaccuracies, you need to use a language specific feature (e.g. BigDecimal in Java) to "perfectly" store the decimals. Alternatively, you can represent decimals as separate integers (e.g. main number is one integer and the decimal is another integer) and combine them later.
So, I suspect this is just ingres showing the normal floating point inaccuracies and that there are known workarounds for it in that database.
Update
Here's a support article from Actian specifically about ingres floating point issues which seems useful: https://communities.actian.com/s/article/Floating-Point-Numbers-Causes-of-Imprecision.
I have this formula in SQL server:
((FP.Month1/30) * (30 - DAY(GETDATE()))) + FP.month2 + ((FP.month3/30) * (Day(GETDATE())))
I have been testing out results and they are coming out slightly wrong. So I broke it down to the minimal amount, this:
(FP.Month1/30)
and when I run that, it comes out wrong but the reason this comes out wrong is it is ignoring the decimals. Month1 is 140 so if you divide that by 30, it is supposed to come out as 4.666667 but it is coming out as 4 instead. So that will of course result in the total formula resulting in a wrong result. How do I make sure SQL server uses decimals also.
FYI, I don't know if this effects it but the final result needs to be rounded to a whole number.
SQL server does integer division. So instead of 30, use 30.0:
(FP.Month1 / 30.0)
As a note, 30.4 is a better estimate of the number of days in a month.
This question already has answers here:
Rounding a number to the nearest 5 or 10 or X
(13 answers)
Closed 8 years ago.
I need to round down a number to nearest hundred like these:
For example:
54678 become 54600
54611 become 54600
54699 become 54600
Any idea? thanks!
Here you can find the code basics for the RoundDown command which allows you to round numbers up to a certain number of digits.
What you need to do is basically for example divide your number by 100, then round them and again multiply by 100. It's an easy workaround... but should work!
If you don't want 54699 to become 54700, but just want it to be 54600, there is an easy solution.
If the number is stored as an integer (no decimal point), just divide it by 100, then multiply it by 100 again
If it is not stored as an integer, you will need to divide it by 100, cast it to an integer and then multiply it by 100