Fractional exponent POWER function error ("An invalid floating point operation occurred.") - sql

sales_3Y
0.521
1.282
0.71
1.513
1.502
2357
1.291
1.393
0
0
2.009
I need to calculate the 1/nth root of the column.
Select POWER(sales_3YR,(1.0/3))
Error - An invalid floating point operation occurred.

This suggests that POWER(x,n) for fractional n is implemented internally as exp(n*log(x)), which would fail for all x<0. You can work around it for the special cases of an odd n-th root with a user-defined function like:
create or alter function dbo.CubeRoot(#x float)
returns float
as
begin
if #x = 0 return 0;
return sign(#x) * exp(log(abs(#x))/3.0)
end
and
select dbo.CubeRoot(-8)
outputs
-2

Related

Error: this expression has type unit but an expression was expected of type int

I am trying to do this simple while loop but it's not working. It is giving me the following error:
this expression has type unit but an expression was expected of type
int
let function () =
let current = ref 0 in
let square = ref !current in
while(((square := !current * !current) mod 1000000) != 269696) do
current := !current +1
done;
!square
;;
First of all, function is a keyword in OCaml, you cannot use it to name your functions.
Also, the condition in the while loop is buggy:
this square := !current * !current is an assignment, which type is unit. It is a type error to use it as an argument of mod which takes two integers as input.
You should probably do the assignment inside the loop and only test !square mod 1000000 <> 269696 in the loop's condition.
Notice that i used the <> structural inequality, instead of the physical one != which by luck does the same thing for integers, but you should not use it unless you know that.

Same query but different result when ran in different database servers

I have a local environment running MariaDB server version 10.2.14 and a production environment running MariaDB server version 10.1.40.
When running a calculation based on the haversine formula to calculate distance between 2 geolocations, my local environment returns 0 as the result, but the prod environment returns null.
A sample query is below:
select (acos(cos(radians((41.480473))) * cos(radians(41.480473)) *
cos(radians((-81.630990)) - radians(-81.630990)) +
sin(radians((41.480473))) * sin(radians(41.480473))) * 3958.755
) as distance
The result should be zero because it is essentially trying to get the distance between 2 locations with the same geolocation info.
Can anyone shed some light why my prod environment is giving me a null value when running the above sample instead of zero?
The difference comes from rounding errors for the outmost acos-function. The other system may give you exactly 1 while the other system may give you bit over 1 due to rounding errors. Valid parameters for acos are from 1 is 0 and acos value > 1 is NULL.
You can use ROUND before the outmost acos and make the calculation a function for easier use:
create function f_distance_in_miles(
in_lat1 decimal(9,7),
in_long1 decimal(9,7),
in_lat2 decimal(9,7),
in_long2 decimal(9,7)
)
returns float
deterministic
begin
declare v_i real;
set v_i = cos(radians(in_lat1)) * cos(radians(in_lat2)) * cos(radians(in_long1)
- radians(in_long2))
+ sin(radians(in_lat1)) * sin(radians(in_lat2));
if (v_i<-1) then
set v_i = -1;
elseif (v_i>1) then
set v_i = 1;
end if;
return acos(v_i)*3958.755;
end
And then use it like:
select f_distance_in_miles(41.480473, -81.630990, 41.480473, -81.630990)

Invalid floating point operation with CTE

I'm getting An invalid floating point operation occurred error with this code.
It's telling me that the problem is on line where the CTE starts.
If I don't have the SQRT function, then everything work fine, but as soon as I add the SQRT I get the error.
What I'm trying to do is to get rid of the negative by squaring the number.
declare #start_date date, #end_date date
set #start_date = '2012/01/01'
set #end_date = '2012/12/31';
with tbl1
as
(
select
strata,
entranceID,
sum(count)/count(*) as AverageCount
from
train
where
surveydate between '2012/01/01' and '2012/12/31'
group by
strata,
entranceID
)
select
a.jobnumber,
a.strata,
a.EntranceID,
Count,
b.AverageCount,
count - AverageCount
, CASE WHEN AverageCount = 0 then 0
ELSE SQRT(count - AverageCount)
END as A
In the expression:
SQRT(count - AverageCount)
The value of count has to be >= AverageCount.
This may not be true for your test data.
Consider using :
SQRT (ABS(count - AverageCount))
Instead, If that makes sense in your case.

Arithmetic overflow error converting expression to data type float

Working on an analysis of bonds. I have attempted to make a payment function that replicates the PMT function of excel. For the bonds, the "Cusip" is their identifier, their "PASS THRU RATE" is their annual interest rate, the "ORIGINAL WA MATURITY" is the total number of periods, and the "ORIGINAL BALANCE" is the original face value of the bond.
The equation for calculating a monthly payment by paper is:
M=[OF(i(1+i)^n)]/[(1+i)^(n-1)]
M=Monthly payment
OF=Original Face
i=annual interest rate/12
n=number of periods
I have a table with all the columns needed for this function, as well as different tables for different months that I will try and use this for. This is what I have so far, creating the function and trying to fix for data types:
if object_id('dbo.PMT') > 0
drop function dbo.PMT
go
create function dbo.PMT(#rate numeric(15,9), #periods smallint, #principal numeric(20,2) )
returns numeric (38,9)
as
begin
declare #pmt numeric (38,9)
select #pmt = #principal
/ (power(1+#rate,#periods)-1)
* (#rate*power(1+#rate,#periods))
return #pmt
end
go
drop function dbo.PMT
go
create function dbo.PMT
(
#rate float,
#periods smallint,
#principal numeric(20,2)
)
returns numeric (38,9)
as
begin
declare #pmt numeric (38,9)
declare #WK_periods float,
#WK_principal float,
#wk_One float,
#WK_power float
select #WK_periods = #periods,
#WK_principal = #principal,
#WK_One = 1
select #pmt =
round(
( #WK_principal * (#rate*power(#WK_One+#rate,#WK_periods)))
/ (power(#WK_One+#rate,#WK_periods)-#WK_One)
,9)
return #pmt
end
go
select ALL [CUSIP NUMBER]
,[PASS THRU RATE]
,[ORIGINAL WA MATURITY]
,[ORIGINAL BALANCE],
dbo.pmt((mbs012013.[PASS THRU RATE]),mbs012013.[ORIGINAL WA MATURITY],mbs012013.[ORIGINAL BALANCE])
FROM
[MBS_STATS].[dbo].[mbs012013]
However, I receive
(502882 row(s) affected)
Msg 8115, Level 16, State 2, Line 2
Arithmetic overflow error converting expression to data type float.
when I attempt to execute it. I cannot figure out what is causing this. Any help would be great!
In the line below, you have #WK_principal as a FLOAT, and you're assigning the value of #principal which is a NUMERIC(20,2).
#WK_principal = #principal,
That seems to be the most likely culprit. We'd need to be able to see your data to help otherwise. Also, I'm not clear on why you're creating the function one way, then dropping it and recreating it differently. Or are you just showing two different attempts?

Error converting data type varchar to numeric CAST not working

I know this has been beaten like a dead horse. However no matter how I slice it, cast it or convert it I have the same issue.
Error converting data type varchar to numeric.
SELECT property_id, property_case_number, property_address, property_city,
property_state, property_zip, property_lon, property_lat
FROM property
WHERE (property_active = 1)
AND
(property_county = (SELECT property_county FROM property AS property_1
WHERE (property_id = 9165)))
AND
(property_id <> 9165)
AND
property_lon IS NOT Null
AND
property_lat IS NOT Null
AND
dbo.LatLonRadiusDistance(
CONVERT(DECIMAL(15,12),(select property_lat from property where property_id = 9165)),
CONVERT(DECIMAL(15,12),(select property_lon from property where property_id = 9165)),
property_lat,property_lon) <= '5'
I run into this issue as soon as I add dbo.LatLonRadiusDistance at the end.
dbo.LatLonRadiusDistance compares lat & lon distance in miles.
FUNCTION [dbo].[LatLonRadiusDistance]
(
#lat1Degrees decimal(15,12),
#lon1Degrees decimal(15,12),
#lat2Degrees decimal(15,12),
#lon2Degrees decimal(15,12)
)
RETURNS decimal(9,4)
AS
BEGIN
DECLARE #earthSphereRadiusKilometers as decimal(10,6)
DECLARE #kilometerConversionToMilesFactor as decimal(7,6)
SELECT #earthSphereRadiusKilometers = 6366.707019
SELECT #kilometerConversionToMilesFactor = .621371
-- convert degrees to radians
DECLARE #lat1Radians decimal(15,12)
DECLARE #lon1Radians decimal(15,12)
DECLARE #lat2Radians decimal(15,12)
DECLARE #lon2Radians decimal(15,12)
SELECT #lat1Radians = (#lat1Degrees / 180) * PI()
SELECT #lon1Radians = (#lon1Degrees / 180) * PI()
SELECT #lat2Radians = (#lat2Degrees / 180) * PI()
SELECT #lon2Radians = (#lon2Degrees / 180) * PI()
-- formula for distance from [lat1,lon1] to [lat2,lon2]
RETURN ROUND(2 * ASIN(SQRT(POWER(SIN((#lat1Radians - #lat2Radians) / 2) ,2)
+ COS(#lat1Radians) * COS(#lat2Radians) * POWER(SIN((#lon1Radians - #lon2Radians) / 2), 2)))
* (#earthSphereRadiusKilometers * #kilometerConversionToMilesFactor), 4)
END
I'm sure it's something to do with
(select property_lat from property where property_id = 9165)
But no matter how I cast or convert it doesn't change things.
And if I run the function by itself it doesn't give an error.
Anyone have any insights?
here is a sample row
8462 023-125514 15886 W MOHAVE ST GOODYEAR AZ 85338-0000 -112.400297000000 33.429041000000
property_lat & property_lon are varchar(50)
Most likely you are expecting boolean short circuit to rescue the order of evaluating your WHERE clause. This is a known fallacy: boolean operator short circuit is not guaranteed in SQL. See On SQL Server boolean operator short-circuit for a discussion and proof that boolean short circuit can be skipped by query optimizer. Similar topic is T-SQL functions do no imply a certain order of execution. The gist of it is that SQL is a declarative language, not an imperative one.
In your case probably your cast and converts will be called for properties with IDs different from property_id = 9165 and property_active=1 and may attempt to cast string values that are not numerics to a numeric, hence the exception you see. Is difficult to give a precise diagnosis since so much information is missing from your problem description (like the exact definition of all object involved, including all tables, indexes, column types etc).
Your best avenue is to upgrade to SQL Server 2008 and use the built in geography type which has built-in support for STDistance:
This is a close approximate to the geodesic distance. The deviation of
STDistance() on common earth models from the exact geodesic distance
is no more than .25%.
After playing with the query I got it working.
SELECT [property_id], [property_case_number], [property_address], [property_city],
[property_state], [property_zip], [property_lon],
[property_lat]
FROM property
WHERE ([property_active] = 1)
AND
([property_county] = (SELECT b.property_county FROM property b WHERE (b.property_id = #prop_id)))
AND
([property_id] <> #prop_id)
AND
[property_lon] IS NOT Null
AND
[property_lat] IS NOT Null
AND
dbo.LatLonRadiusDistance(
(SELECT c.property_lat FROM property c WHERE (c.property_id = #prop_id)),
(SELECT d.property_lon FROM property d WHERE (d.property_id = #prop_id)),
CAST([property_lat] as FLOAT),
CAST([property_lon] as FLOAT)) <= 5
adding the [] seems to have skirted the issue I was having.