[firebase-br] Conversão cast com alteração de valor

[Carlos H. Cantu]

O exemplo dele foi simples: fez um cast de uma string (1485.45) para
um numeric(18,13. A única forma de haver perda de precisão nisso
(usando dialeto 3) é se o número de casas decimais da string for maior
do que a escala definida para o numeric, pois nesse caso haverá
arredondamento, mas não é o caso no exemplo enviado. Se ele obteve
qualquer coisa diferente de 1485.45 como resultado, então
provavelmente a ferramenta usada está com alguma máscara definida para
a apresentação dos resultados, que pode estar gerando arredondamento
na EXIBIÇÃO do mesmo. Por isso eu aconselho sempre usar o isql pra
tirar a prova das coisas.

Numeric e decimal no dialeto 3 são tratados internamente como inteiros
no Firebird, portanto, não se comportam como ponto flutuante. Nunca
haverá perda de precisão no número armazenado x recuperado utilizando
esses dois tipos com dialeto 3.

No entanto, se eles forem utilizados em uma fórmula (que não é o caso
do exemplo), dependendo dos outros argumentos envolvidos e das
operações matemáticas realizadas, o resultado pode sim ter alguma
perda de precisão devido a forma que a Borland implementou os cálculos
intermediários.

PS: A implementação de numeric/decimal no Firebird não segue o padrão
do SQL Standard.

[]s
Carlos H. Cantu
eBook Guia de Migração para o FB 4 - www.firebase.com.br/guiafb4.php
www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

GS> Na realidade a discussão é sobre precisão, o numeric se comporta como um
GS> ponto flutuante com casas fixas, ele não tem precisão, a precisão é a
GS> capacidade do número de se manter íntegro e isso é transparente para nós,
GS> mas bem difícil e consome muitos recursos da CPU, foi uma tese muito longa
GS> que tive no passado e daí minha explicação longa respondendo ao colega
GS> porque isso acontece.
GS> Nem que a vaca touça, misturando tipos numéricos diferentes e usando
GS> numeric(x,y)  irá manter precisão, só irá deformá-lo ainda mais.
GS> Para fins didáticos, mexendo com o numeric tudo que irá obter será um
GS> numero de casas fixas no final da operação, mas se analisar com cuidado as
GS> operações aritméticas acumuladas durante a soma notará imprecisão, algo
GS> desprezível para a maioria de nós, mas intolerado em certas operações.
GS> O colega quer precisão, e não será possível com o cast para string ou mesmo
GS> numeric(x,y) da forma como apontei.
GS> Eu não falei o tipo que ele deveria usar porque espero que ele busque qual
GS> o tipo mais adequado quando é desejável manter precisão numérica.

GS> []´s
GS> ps:  Para você não teve problema com o numeric->cast que apresentou o mesmo
GS> número, mas para ele teve - é exatamente o problema que tentei explicar - a
GS> imprecisão se dá dentro do processador e pode variar conforme o ambiente.
GS> Mas também pode ser o ibexpert, há uma opção nas configurações dele para
GS> mascarar valores e muita gente desconhece o parâmetro e ele mostra zeros
GS> onde não há zeros.


GS> Em sáb., 6 de nov. de 2021 às 06:46, Carlos H. Cantu via lista <
GS> lista em firebase.com.br> escreveu:

>> O cast que ele fez é para numeric, portanto, o resultado não é ponto
>> flutuante e sim ponto fixo. Não há perda de precisão na conversão.
>>
>>