2013-08-30 2 views
0

Я просто написал SQL функции, как показано нижеSQL UDF: Плавающий ошибка точки

Create Function LAeq(@Frequency Decimal(18,2), @Sound Decimal(18,2)) 
RETURNS DECIMAL(18,2) 
AS 
BEGIN 
declare @T1 Decimal (28, 10) 
DECLARE @T2 Decimal (28, 10) 
DECLARE @T3 Decimal (28, 10) 
DECLARE @T4 Decimal (28, 10) 
DECLARE @T5 Decimal (28, 10) 
DECLARE @T6 Decimal (28, 10) 
DECLARE @T7 Decimal (28, 10) 

SET @T1 = POWER(12200.0,2) * POWER(@Frequency, 4) 
SET @T2 = POWER (@Frequency, 2) + POWER(20.6,2) 
SET @T3 = POWER (@Frequency, 2) + POWER(107.7,2) 
SET @T4 = POWER (@Frequency, 2) + POWER(737.9,2) 
SET @T5 = POWER (@Frequency, 2) + POWER(12200.0,2) 
SET @T6 = SQRT(@T3 *@T4) * @T5 * @T2 
SET @T7 = @T1/ @T6 
SET @T7 = @Sound + (2.0 + (20.0 * LOG10(@T7))) 
RETURN @T7 
END 

Эта функция работает, если я прохожу значение 0,8, 26. Однако это терпит неудачу, когда у меня есть значение как 20000, 80. моя функция должна работайте по частоте как максимум 20K, а звук может быть меньше 100 в качестве максимальных значений. Я пытаюсь изменить T1, T7 с десятичной (28,10) до 30, 15 или 18,2, но ничего не работает для меня. Я не хочу, чтобы определить ограничение на тип данных, когда я написал SQL заявление с той же формуле, как

Select 26 + (2 + (20 * LOG10((POWER(12200,2) * POWER(0.8, 4))/ (SQRT((POWER (0.8, 2) + POWER(107.7,2)) * (POWER (0.8, 2) + POWER(737.9,2))) * (POWER (0.8, 2) + POWER(12200,2)) * (POWER (0.8, 2) + POWER(20.6,2)))))) 

ИЛИ

Select 80 + (2 + (20 * LOG10((POWER(12200,2) * POWER(20000.00, 4))/ (SQRT((POWER (20000.00, 2) + POWER(107.7,2)) * (POWER (20000.00, 2) + POWER(737.9,2))) * (POWER (20000.00, 2) + POWER(12200,2)) * (POWER (20000.00, 2) + POWER(20.6,2)))))) 

он работает довольно хорошо, и более точной, чем моя функция. можно ли исключить необходимость использования типа данных в функции? Если нет, то как можно обеспечить максимальную точность?

Спасибо.

ответ

1

Я использовал бы float вместо decimal как тип данных для входных параметров и локальных переменных, это не должно вызывать переполнение для разумных входных значений.

+0

, хотя он делает мой крайний случай работы, но он по-прежнему не очень точен в сравнении с прямым методом SELECT. но я думаю, что сейчас смогу жить с ним. –