A gravação IEEE 754-1985 é dupla como ASCII em uma sequência limitada de 16 bytes
Este é um acompanhamento para o meupostagem original. Mas vou repetir para maior clareza:
Conforme o padrão DICOM, um tipo de ponto flutuante pode ser armazenado usando uma Representação de Valor da Sequência Decimal. VejoTabela 6.2-1. Representações de valor DICOM:
Sequência decimal: uma sequência de caracteres que representa um número de ponto fixo ou um número de ponto flutuante. Um número de ponto fixo deve conter apenas os caracteres de 0 a 9 com um "+" ou "-" inicial opcional e um "" opcional. para marcar o ponto decimal. Um número de ponto flutuante deve ser transmitido conforme definido na ANSI X3.9, com um "E" ou "e" para indicar o início do expoente. As cadeias decimais podem ser preenchidas com espaços à esquerda ou à direita. Espaços incorporados não são permitidos.
"0" - "9", "+", "-", "E", "e", "." e o caractere ESPAÇO do repertório de caracteres padrão. Máximo de 16 bytes
O padrão está dizendo quea representação textual é ponto fixo vs. ponto flutuante. O padrão refere-se apenas a como os valores são representados no próprio conjunto de dados DICOM. Como tal, não é necessário carregar uma representação textual de ponto fixo em uma variável de ponto fixo.
Então agora que está claro que o padrão DICOM recomenda implicitamentedouble
(IEEE 754-1985) por representar umValue Representation
do tipoDecimal String
(máximo de 16 dígitos significativos). Minha pergunta é como uso a biblioteca de E / S C padrão para converter novamente essa representação binária da memória em ASCII para essa seqüência de tamanho limitado?
De fontes aleatórias na internet, isso não é trivial, mas geralmentesolução aceita é também:
printf("%1.16e\n", d); // Round-trippable double, always with an exponent
ou
printf("%.17g\n", d); // Round-trippable double, shortest possible
É claro que ambas as expressões são inválidas no meu caso, pois podem produzir resultados muito mais longos do que o meu limite máximo de16 bytes. Então, qual é a solução paraminimizando a perda de precisão ao escrever um valor duplo arbitrário em uma seqüência limitada de 16 bytes?
Editar: se isso não estiver claro, sou obrigado a seguir o padrão. Não consigo usar a codificação hex / uuencode.
Editar 2: Estou executando a comparação usando travis-ci, veja:aqui
Até agora, os códigos sugeridos são:
Serge BallestachuxMark DickinsonchuxOs resultados que vejo aqui são:
compute1.c
leva a um erro de soma total de:0.0095729050923877828
compute2.c
leva a um erro de soma total de:0.21764383725715469
compute3.c
leva a um erro de soma total de:4.050031792674619
compute4.c
leva a um erro de soma total de:0.001287056579548422
assimcompute4.c
leva à melhor precisão possível (0,001287056579548422 <4.050031792674619), mas triplica (x3) o tempo de execução geral (testado apenas no modo de depuração usandotime
comando).