Início / dba / Perguntas / 209556
Accepted
Elaskanator
Asked: 2018-06-14 06:37:47 +0800 CST

SQL Server - Erro de precisão de máquina oculto e inconsistente ao truncar o resultado de LOG para inteiro

  • 772

Percebi um comportamento estranho de arredondamento no SQL Server (pelo menos 2008R2) ao converter a base de log 10 de 1000 para um inteiro. A resposta é claramente o valor exato 3, mas deve haver alguns decimais que o SQL Server está ocultando da saída:

SELECT LOG(1000, 10)--returns 3 with no visible decimals
SELECT CONVERT(INT, LOG(1000, 10))--returns 2

Eu fiz engenharia reversa do epsilon mínimo para obter o valor correto quando adicionado ao resultado de LOGantes da conversão como aproximadamente:

SELECT CONVERT(INT, LOG(1000, 10)+0.0000000000000002220446049250313)
SELECT CONVERT(INT, LOG(1000, 10)+0.0000000000000002220446049250312)

insira a descrição da imagem aqui

Parece que eu poderia ficar o dia todo tornando esse valor mais preciso.

Isso só parece ser necessário para o caso de 1000, pois obtenho os valores inteiros adequados para 1, 10, 100 e 10000 e maiores sem usar nenhum termo épsilon.

O termo de erro parece ser a cauda da série Taylor expandida em 16 termos (conforme esta página ), mas por que o SQL Server está se comportando repentinamente como esperado (sem erro de precisão de máquina oculto) quando tento isso para o caso de 10000 e maiores ?

Por que o SQL Server está demonstrando inconsistentemente um erro de precisão da máquina?

Obrigado.

sql-server

2 respostas

  1. Best Answer

    O problema é mais simples do que isso. LOG gera um número de ponto flutuante e você deve sempre ROUND ao converter de um valor de ponto flutuante para um int em vez de truncar.

    O que você está fazendo é semelhante a:

    select cast(0.99999999999999999999999999999999999 as int)

    O resultado de LOG(1000,10) não é 3, que você pode ver

    select convert(varchar(200),LOG(1000, 10), 3)

    está mais próximo de

       2.9999999999999996e+000

    (embora internamente o significando seja armazenado em base-2).

    Não há nada de inconsistente nesse comportamento. LOG é uma estimativa baseada em uma expansão em série que converge para o logaritmo, e o resultado é retornado com uma quantidade limitada de precisão.

    A função LOG foi projetada para retornar um resultado com precisão de 15 dígitos decimal, mas dependendo dos argumentos, o resultado pode ser um pouco maior ou um pouco menor que a resposta correta.

    • 6

  2. Por que isso pode ser um " comportamento consistente " para o MSSQL, eu chamaria isso de contra-intuitivo.
    Eu não posso acreditar que estou dizendo isso, mas parece que o SQL Server lida com Float como um Decimal de Maior Precisão, até o momento em que você termina seus Computations, então ele converte como Float para sua Variable (ou seu Select) .

    MSDN diz que Log()retorna um Float.
    O que observei é que os floats estão sendo tratados como valores decimais de maior precisão:

    --Proof:
SELECT CAST(2.99999999999999950000 as Int  )--2
SELECT CAST(2.99999999999999950000 as Float)--3
--Order of Operations Is Observed: Number is Truncated to Int first, then Cast as Decimal.
SELECT CAST(CAST(2.99999999999999950000 as Int  ) as Decimal(30,20))--2.00000000000000000000
--Order of Operations Not-Observed: Number is Never Cast to a Float first before Decimal.
SELECT CAST(CAST(2.99999999999999950000 as Float) as Decimal(30,20))--2.99999999999999950000

--This is the actual value returned.  It has up to 16 Precision,
--   even though a Double-Precision Float has a Max-Precision of 15.
SELECT CAST(LOG(1000, 10) as DECIMAL(30,20))--2.99999999999999950000
--Note: I think the more-accurate answer probably ends in 6, instead of 5.

--To properly Round your value for Integer Expression, I'd use Decimal(10) instead of Int.
SELECT CAST(LOG(1000, 10) as DECIMAL(10))--3
    • 1

relate perguntas