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 Dickinsonchux

Os resultados que vejo aqui são:

compute1.c leva a um erro de soma total de:0.0095729050923877828compute2.c leva a um erro de soma total de:0.21764383725715469compute3.c leva a um erro de soma total de:4.050031792674619compute4.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).