Decimal Strings and ANSI X3.9  DICOM
This is a discussion on Decimal Strings and ANSI X3.9  DICOM ; Hello everybody,
I've got a couple of questions concerning the VR DS ("Decimal String") as
described in PS 3.52008, pp. 2425.:
 Why is the floating point number definition derived from "ANSI X3.9"?
Isn't this the FORTRAN standard, which is ...

Decimal Strings and ANSI X3.9
Hello everybody,
I've got a couple of questions concerning the VR DS ("Decimal String") as
described in PS 3.52008, pp. 2425.:
 Why is the floating point number definition derived from "ANSI X3.9"?
Isn't this the FORTRAN standard, which is available in different versions
(e.g. X3.91966 and X3.91978)? These versions even have differences in
floating point representation, as far as I understand from
http://www.fortran.com/fortran/F77_s...19.html#sh20
 Is "+.9" a valid DS value? I.e., can the predecimal portion of the number
be omitted? X3.91978 specifically addresses this issue: "Both the integer
part and the fractional part are strings of digits; either of these parts may
be omitted but not both" (http://www.fortran.com/F77_std/rjcnf4.html#sh4.4)
but as far as I understand, X3.9 applies to the exponent only?
 Which of these are valid exponents: "5E4", "5E4", "5E+4", "5E 4" or all
of them?
It would be great, if someone could help me!
Thanks a lot in advance and best regards,
Winfried

Re: Decimal Strings and ANSI X3.9
On May 27, 3:05 pm, Winfried Schoech wrote:
> Hello everybody,
>
> I've got a couple of questions concerning the VR DS ("Decimal String") as
> described in PS 3.52008, pp. 2425.:
>
>  Why is the floating point number definition derived from "ANSI X3.9"?
> Isn't this the FORTRAN standard, which is available in different versions
> (e.g. X3.91966 and X3.91978)? These versions even have differences in
> floating point representation, as far as I understand fromhttp://www.fortran.com/fortran/F77_std/rjcnf0100sh19.html#sh20
>
>  Is "+.9" a valid DS value? I.e., can the predecimal portion of the number
> be omitted? X3.91978 specifically addresses this issue: "Both the integer
> part and the fractional part are strings of digits; either of these parts may
> be omitted but not both" (http://www.fortran.com/F77_std/rjcnf4.html#sh4.4)
> but as far as I understand, X3.9 applies to the exponent only?
>
>  Which of these are valid exponents: "5E4", "5E4", "5E+4", "5E 4" or all
> of them?
>
> It would be great, if someone could help me!
> Thanks a lot in advance and best regards,
>
> Winfried
You are talking basically about:
19. Following the E or D in an E or D output field, a + or  is
required immediately prior to the exponent field. This improves
compatibility with American National Standard for the Representation
of Numeric Values in Character Strings for Information Interchange,
ANSI X3.421975. ANSI X3.91966 permitted a blank as a replacement for
+ in the exponent sign.
I would hope noone actually wrote DS value using the ANSI X3.91966
norm (with a space instead of '+' sign), speaking for myself this
would break everywhere (I am internally relying on the Clib sscanf or
C++ equivalent which assume space is a character separator).
HTH
Mathieu

Re: Decimal Strings and ANSI X3.9
Hi
A space is not permitted in a DS as is evident from the fact that
a space is not listed in the "Character Repertoire" of Table 6.21
for the Decimal String VR, and the words "embedded spaces are not
allowed" in the Definition column. The definition reads:
"A string of characters representing either a fixed point number or
a floating point number. A fixed point number shall contain only
the characters 09 with an optional leading "+" or "" and an
optional "." to mark the decimal point. A floating point number
shall be conveyed as defined in ANSI X3.9, with an "E" or "e" to
indicate the start of the exponent. Decimal Strings may be padded
with leading or trailing spaces. Embedded spaces are not allowed."
From ANSI X3.91978, which is the version listed in PS 3.5 Section 2
Normative References:
"4.3.1 Integer Constant.
The form of an integer constant is an optional sign followed by a
nonempty string of digits. The digit string is interpreted as a
decimal number.
4.4.1 Basic Real Constant.
The form of a basic real constant is an optional sign, an integer part,
a decimal point, and a fractional part, in that order. Both the integer
part and the fractional part are strings of digits; either of these parts
may be omitted but not both. A basic real constant may be written with
more digits than a processor will use to approximate the value of the
constant. A basic real constant is interpreted as a decimal number.
4.4.2 Real Exponent.
The form of a real exponent is the letter E followed by an optionally
signed integer constant. A real exponent denotes a power of ten.
4.4.3 Real Constant.
The forms of a real constant are:
1. Basic real constant
2. Basic real constant followed by a real exponent
3. Integer constant followed by a real exponent
The value of a real constant that contains a real exponent is the
product of the constant that precedes the E and the power of ten
indicated by the integer following the E."
The Fortran reference dates back to 1985 in the original ACRNEMA
standard in which the definition of ASCII values (section 4.7.1)
specifically specified floating point numbers to be 'as defined
in ANSI X3.91978" and to use the uppercase E. I have no idea
who chose this or why, or why they did not reference ANSI X3.421975
instead.
I would conclude that these are legal:
"+.9"
"5E4"
"5E4"
"5E+4"
and this is illegal:
"5E 4"
I was gratified to see that my validator reports this as an error:
Error  Value invalid for this VR  (0x0018,0x0081) DS Echo Time DS [0] = <5E 4>  Character invalid for this VR = ' ' (0x20)
David
Mathieu Malaterre wrote:
> On May 27, 3:05 pm, Winfried Schoech wrote:
>> Hello everybody,
>>
>> I've got a couple of questions concerning the VR DS ("Decimal String") as
>> described in PS 3.52008, pp. 2425.:
>>
>>  Why is the floating point number definition derived from "ANSI X3.9"?
>> Isn't this the FORTRAN standard, which is available in different versions
>> (e.g. X3.91966 and X3.91978)? These versions even have differences in
>> floating point representation, as far as I understand fromhttp://www.fortran.com/fortran/F77_std/rjcnf0100sh19.html#sh20
>>
>>  Is "+.9" a valid DS value? I.e., can the predecimal portion of the number
>> be omitted? X3.91978 specifically addresses this issue: "Both the integer
>> part and the fractional part are strings of digits; either of these parts may
>> be omitted but not both" (http://www.fortran.com/F77_std/rjcnf4.html#sh4.4)
>> but as far as I understand, X3.9 applies to the exponent only?
>>
>>  Which of these are valid exponents: "5E4", "5E4", "5E+4", "5E 4" or all
>> of them?
>>
>> It would be great, if someone could help me!
>> Thanks a lot in advance and best regards,
>>
>> Winfried
>
> You are talking basically about:
>
> 19. Following the E or D in an E or D output field, a + or  is
> required immediately prior to the exponent field. This improves
> compatibility with American National Standard for the Representation
> of Numeric Values in Character Strings for Information Interchange,
> ANSI X3.421975. ANSI X3.91966 permitted a blank as a replacement for
> + in the exponent sign.
>
> I would hope noone actually wrote DS value using the ANSI X3.91966
> norm (with a space instead of '+' sign), speaking for myself this
> would break everywhere (I am internally relying on the Clib sscanf or
> C++ equivalent which assume space is a character separator).
>
> HTH
> Mathieu

Re: Decimal Strings and ANSI X3.9
Hello,
thanks for the quick reply!
> From ANSI X3.91978, which is the version listed in PS 3.5 Section 2
> Normative References
Thanks, brilliant hint. I am still learning how to read the DICOM standard
properly... So, X3.91978 it is (a little weird from today's perspective :).
> 4.4.1 Basic Real Constant.
>
> The form of a basic real constant is an optional sign, an integer part,
> a decimal point, and a fractional part, in that order. Both the integer
> part and the fractional part are strings of digits; either of these parts
> may be omitted but not both.
I still think that this description is superior to the "fixed point number"
description in PS 3.5. Maybe one could update the phrases there or "extend"
the X3.9 hint to the fixed point numbers?
For the patient folks I have two more question concerning Decimal Strings:
 As far as I understand from the definition of VR DS, unlimited leading
zeros are permitted? (if the resulting string's length is less than 16 characters)
 The definition in PS 3.5 does not indicate, that the decimal point
position and the presence of "+" signs are significant. I.e., "3.5E1",
"+3.5E1", ".35", ".35E0", ".35E+0", ".35E0" etc. are treated as exactly the
same number. How do you treat this in your software solutions? Do you try to
preserve superfluous elements (signs, leading zeros, E0) and the decimal point
position when editing DS values? Or do you use normalized floating point numbers?
Best regards and have a nice day,
Winfried

Re: Decimal Strings and ANSI X3.9
>  The definition in PS 3.5 does not indicate, that the decimal point
> position and the presence of "+" signs are significant. I.e., "3.5E1",
> "+3.5E1", ".35", ".35E0", ".35E+0", ".35E0" etc. are treated as
> exactly the same number. How do you treat this in your software
> solutions? Do you try to preserve superfluous elements (signs, leading
> zeros, E0) and the decimal point position when editing DS values? Or do
> you use normalized floating point numbers?
Speaking from a toolkit perspective, DCMTK offers two APIs to read and
write DS elements  one API operates on string and the other one on
binary doubleprecision floating point numbers. If you use the string
API you will see the sequence of characters as contained in the dataset
(with the option of having nonsignificant space characters removed automatically),
and if you use the "double" API, the numbers are obviously normalized and can
be compared for equality (as far as this is ever a good idea for floating point
numbers). It is up to the application to choose the API that is best suited
for the particular task in mind. We also have a conversion routine in place
that converts between string and binary represenations and is independent from
the locale setting, which affects for example the character expected and
produced as decimal point when converting.
Regards,
Marco Eichelberg
OFFIS