Is there a simply way to convert the following Excel formula into TSQL:
ROUNDDOWN((table.OrderQty / table.PacksPerCase),0)
table.OrderQty = 9
table.PacksPerCase = 5
"0" indicate that the result will have zero decimal places
Result = 1.0
table.OrderQty = 9
table.PacksPerCase = 4
"0" indicate that the result will have zero decimal places
Result = 2.0
Try using FLOOR :
The FLOOR function returns the largest integer less than or equal to
the specified numeric expression.
Your expression should be:
FLOOR(table.OrderQty / table.PacksPerCase)
ROUNDDOWN() rounds towards zero for negative numbers.
Since FLOOR rounds towards negative infinity, the closest equivalent in TSQL I can think of is ROUND with function set to 1;
ROUND((table.OrderQty / table.PacksPerCase), 0, 1)
If you're only dealing with positive numbers, of course FLOOR will also work well.
Related
n = 215;
N = 215.01:0.1:250;
p = 0.52;
q = 0.48;
Gamblers = (1 - (q/p)^n)./(1 - (q/p).^N);
plot(Gamblers)
Matlab takes the numerators and denominators as simply 1, filling the array with nothing but that value. How can I correct this?
Your denominator and numerator are very close to 1 but not exactly 1. The plot(Gamblers) confirms this.
By default MATLAB will display numbers with four digits after the decimal place. Your numerator is 0.999999966414861, which with four digits rounds to 1. MATLAB uses double precision numbers so your calculation here is still accurate.
Try double clicking on the Gamblers variable to open the variables window and then double clicking on one of the results. You'll see it change from the default display precision to a much more accurate depiction of your variable.
Can someone please explain how to get the surrounding integers for a given positive number ( for ex. if number is 18.2378 then it should return 18 and 19 )
(I actually need this to determine that the given number is between 0-1 or 2-3 or 4-5 and so on....and if it is in between 0-1 or 2-3 or 4-5 etc then some expression evaluates , else some other expression must evaluate.)
The floor and ceil functions do this:
x = 18.2378;
floor(x); %Returns 18
ceil(x); %Returns 19
floor(18.2378) will return 18 i.e. the previous nearest integer.
ceil(18.2378) will return 19 i.e. the next nearest integer
You can use round or floor or ceil in Matlab to turn decimal numbers into integers. Round will round up or down depending on the decimal value, floor rounds toward minus infinity, and ceil rounds toward positive infinity.
Here is an example of how this could work:
n=18.2378;
F=floor(n);
C=ceil(n);
TF=F<n<C;
F returns 18. C returns 19. TF will return 1 if the number is between the floor and the ceiling--But, if you do it this way the number will always be between its floor and ceiling--and 0 if it is not. You can do this iteratively in a loop as many times as you need.
In this answer gire mentioned to better not use == when comparing doubles.
When creating a increment variable in a for loop using start:step:stop notation, it's type will be of double. If one wants to use this loop variable for indexing and == comparisons, might that cause problems due to floating point precision?!
Should one use integers? If so, is there a way to do so with the s:s:s notation?
Here's an example
a = rand(1, 5);
for ii = length(a):-1:1
if (ii == 1) % Comparing var of type double with ==
b = 0;
else
b = a(ii); % Using double for indexing
end
... % Code
end
Note that the floating point double specification uses 52 bits to store the mantissa (the part after the decimal point) so you can exactly represent any integer in the range
-4503599627370496 <= x <= 4503599627370496
Note that this is larger than the range of an int32, which can only represent
-2147483648 <= x <= 2147483647
If you are just using the double as a loop variable, and only incrementing it in integer steps, and you are not counting above 4,503,599,627,370,496 then you are fine to use a double, and to use == to compare doubles.
One reason people suggest for not using doubles is that you can't represent some common decimals exactly, e.g. 0.1 has no exact representation as a double. Therefore if you are working with monetary values, it may be better to separately store the data as an int and remember a scale factor of 10x or 100x or whatever.
It's sometimes bad to directly compare floating point numbers for equality because rounding issues can cause two floats to be not equal, even though the numbers are mathematically equal. This generally happens when the numbers are not exactly representable as floats, or when there is a significant size difference between the numbers, e.g.
>> 0.3 - 0.2 == 0.1
ans =
0
If you're indexing between integer bounds with integer steps (even though the variable class is actually double), it is ok to use == for comparisons with other integers.
You can cast the indices, if you really want to be safe.
For example:
for ii = int16(length(a):-1:1)
if (ii == 1)
b = 0;
end
end
how to filter out float values with only zeroes beyond decimal & others having some non-zero values beyond decimal too.
for example.
13.000000
13.120001
i want it like this:
13.0
13.120001
If your application stores the floating point values in something like C/C++'s float's or double's, you may have a problem here.
First of all, float/double in the majority of cases represents values using base-2 and when you do something like double x = 0.1;, x in fact will never be equal to 0.1, but it will be very close to 0.1. That is because not every decimal (base-10) fraction can be represented exactly in base-2.
When you print or convert that x to a string using one of the printf-like functions, the resultant string can vary from something like 0.099999999 to 0.1 to 0.10000000000000000555. The result will depend on what's in x and on how you convert it to a string (how many digits you allow for the integer part, fractional part or all).
Generally there's no one-size-fits-all solution here. In one case the exactness and rounding issues can be unimportant, while in another they can be the most important. When performance is more important than the exact representation of decimal fractions, you use base-2 types. Otherwise, for example, when you're counting money, you use special types (and you may first need to construct them) that can represent decimal fractions exactly and then you avoid some of the described issues at a cost of extra computation time and maybe storage.
You may sometimes use fixed-point types and arithmetic. For example, if your numbers should not have more than 3 fractional digits and aren't too big, you can use scaled integers:
long x = 123456; // x represents 123.456
You add, subtract and compare them just as regular integers, but you multiply and divide them differently, for example like this:
long x = 123456; // x represents 123.456
long y = 12345; // y represents 12.345
long p = (long)(((long long)x * y) / 1000); // p=1524064, representing x*y=1524.064
long q = (long)((long long)x * 1000) / y); // q=10000, representing x/y=10.000
And in this case it is relatively easy to figure out the digits of the fractional part, just look at (x%1000)/100, (x%100)/10 and x%10.
split 13.00000 or 13.20001 into 2 values like in 13.0000 as 13 and 0000 ...so compare 2nd value whether it is greater than 0 (ex:13.20001 where 2001>0) if its yes then set same value . else (ex 13.0000 where 0000=0) then set %.2f=> 13.00
Why does the select statement below return two different values ?
declare #tempDec decimal
set #tempDec = 1.0 / (1.0 + 1.0)
select #tempDec, 1.0 / (1.0 + 1.0)
That's fine for literals like 1.0, but if you're pulling the data from table columns, you need to cast/convert the first evaluated number in your equation:
convert(decimal, [col1]) / ([col2] + [col3])
-or-
convert(decimal(15, 2), [col1]) / ([col2] + [col3])
I found out from a coworker just as I posted this.
You need to specify the default precision and scale.
This works in this scenario:
declare #tempDec decimal(3,2)
From MSDN:
decimal[ (p[ , s] )] and numeric[ (p[ , s] )]
Fixed precision and scale numbers. When maximum precision is used, valid values are from - 10^38 +1 through 10^38 - 1. The SQL-92 synonyms for decimal are dec and dec(p, s). numeric is functionally equivalent to decimal.
p (precision)
The maximum total number of decimal digits that can be stored, both to the left and to the right of the decimal point. The precision must be a value from 1 through the maximum precision of 38. The default precision is 18.
s (scale)
The maximum number of decimal digits that can be stored to the right of the decimal point. Scale must be a value from 0 through p. Scale can be specified only if precision is specified. The default scale is 0; therefore, 0 <= s <= p. Maximum storage sizes vary, based on the precision.