Dies ist ein Follow-up zu meinemoriginal post. Aber ich werde es aus Gründen der Klarheit wiederholen:

Gemäß DICOM-Standard kann ein Gleitkommatyp unter Verwendung einer Wertdarstellung der Dezimalzeichenfolge gespeichert werden. SehenTabelle 6.2-1. DICOM-Wertdarstellungen:

Decimal String: Eine Zeichenfolge, die entweder eine Festkomma- oder eine Gleitkommazahl darstellt. Eine Festkommazahl darf nur die Zeichen 0-9 mit einem optionalen vorangestellten "+" oder "-" und einem optionalen "" enthalten. um den Dezimalpunkt zu markieren. Eine Gleitkommazahl muss gemäß der Definition in ANSI X3.9 mit einem "E" oder "e" übertragen werden, um den Beginn des Exponenten anzuzeigen. Dezimalzeichenfolgen können mit führenden oder nachfolgenden Leerzeichen aufgefüllt werden. Eingebettete Leerzeichen sind nicht zulässig.

0 - 9, +, -, E, e,. und das Leerzeichen des Standardzeichenrepertoires. Maximal 16 Bytes

Der Standard sagt, dassdie Textdarstellung ist Festkomma vs. Gleitkomma. Der Standard bezieht sich nur darauf, wie die Werte im DICOM-Datensatz selbst dargestellt werden. Daher ist es nicht erforderlich, eine Festkomma-Textdarstellung in eine Festkommavariable zu laden.

So jetzt, da dies klar ist, dass DICOM-Standard implizit empfehlendouble (IEEE 754-1985) für die Darstellung einesValue Representation vom TypDecimal String (maximal 16 signifikante Stellen). Meine Frage ist, wie ich die Standard-E / A-Bibliothek verwende, um diese Binärdarstellung aus dem Speicher in ASCII auf diese Zeichenfolge mit begrenzter Größe zurück zu konvertiere

Aus zufälligen Quellen im Internet ist dies nicht trivial, aber im Allgemeinenakzeptierte Lösung entweder

printf("%1.16e\n", d); // Round-trippable double, always with an exponent

ode

printf("%.17g\n", d); // Round-trippable double, shortest possible

Natürlich sind beide Ausdrücke in meinem Fall ungültig, da sie viel länger als mein begrenztes Maximum von @ ausgeben könne 16 bytes. Also, was ist die Lösung für Minimierung des Präzisionsverlustes wenn ein beliebiger doppelter Wert in eine begrenzte 16-Byte-Zeichenfolge geschrieben wird?

Bearbeite: Wenn dies nicht klar ist, muss ich den Standard befolgen. Ich kann keine Hex / Uuencode-Codierung verwenden.

Edit 2: Ich führe den Vergleich mit travis-ci aus. Siehe:Hie

So weit die vorgeschlagenen Codes sind:

Serge Ballesta chux Mark Dickinson chux

Ergebnisse, die ich hier sehe, sind:

compute1.c führt zu einem Summenfehler von:0.0095729050923877828compute2.c führt zu einem Summenfehler von:0.21764383725715469compute3.c führt zu einem Summenfehler von:4.050031792674619compute4.c führt zu einem Summenfehler von:0.001287056579548422

Socompute4.c führt zu bestmöglicher Präzision (0.001287056579548422 <4.050031792674619), verdreifacht jedoch (x3) die Gesamtausführungszeit (nur im Debug-Modus mit @ getestetime Befehl)