So, suppose I want to save a FLOAT-LONG to a file. Since COBOL does not support moving 64-bit floats to strings directly, I'd need to move them to an edited picture first. However, GNUCobol 3.2.0 does not allow me to use the 'E' character. Consider the sample program below:
According to the FAQ, E should be supported. So, what am I doing wrong? Currently, I have a subroutine which manually generates a mantissa and an exponent as -9.9(13) and -999 numeric-edited fields which are then sent to another variable which concatenates them with "E". I can use this to save all my 64-bits floats to a file, and later manipulate said file in R, Python, whatever. This process is obviously bothersome. Is there anything I can do to alleviate this?
Note: this is for a personal project of mine in Cobol, as I'm still learning the language. I know that the actual applications of the scientific notation-like numeric-edited picture are limited.
Last edit: Chibamu Niusrec 2024-08-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Floating point numbers, except in statistical / scientific applications, are not a common COBOL practice.
With GnuCOBOL I believe you can define a Pic 9 field with 37 base 10 digits.
Using PIC 9(nnn) you can specify whole number values and also specify the number of digits to reserve for the fraction.
PIC 9(7)V999 is a 10 byte field. The 999 to the right of the V is the fraction.
"V" is an assumed decimal point. The "V" will be used as a "virtual" decimal point in any computational expression.
Assignment between floating point and decimal representation is supported.
You should be able to define a large decimal number and move it to and from a floating point number.
Last edit: Ralph Linkletter 2024-08-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Look for gnucobpg and gnucobpr, and you can choose PDF's either in A4 or USA letter size.)
E for exponent can only be used in numeric literals, such as in a VALUE clause or COMPUTE statement. I don't believe it is a valid character within a numeric-edited PICTURE clause.
I have personally never used floating-point numbers in a COBOL program. Perhaps someone can suggest an easier way to create a printable representation of a floating-point number with the exponent displayed in your preferred format.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a regression in GnuCOBOL; the only reason that this COBOL2002 feature (also available on IBM) is not in is because of the seldom use of floating point in COBOL.
For some details see [feature-requests:#199] (yes, that's a2017 one!).
Note that we do support floating-point literals since quite some time.
@chaat Could you have a look to add at least the parsing for GnuCOBOL 3?
When we later add the actual support libcob would need both the editing and de-editing part.
Note: to store floating point you could just save a COMP-2 or FLOAT-DOUBLE directly to disk (as long as it either isn't a line-sequential file or you have the escape char enabled). The issue with that is that the floating-point would not be readable by a common human, not portable to a different environment and - depending on reading it in - not portable to other programming languages (storing it with SYNC may be portable, as long as you stay on the same machine and can memcpy that over to a variable matching C doublespecifics).
So, suppose I want to save a FLOAT-LONG to a file. Since COBOL does not support moving 64-bit floats to strings directly, I'd need to move them to an edited picture first. However, GNUCobol 3.2.0 does not allow me to use the 'E' character. Consider the sample program below:
According to the FAQ,
E
should be supported. So, what am I doing wrong? Currently, I have a subroutine which manually generates a mantissa and an exponent as-9.9(13)
and-999
numeric-edited fields which are then sent to another variable which concatenates them with"E"
. I can use this to save all my 64-bits floats to a file, and later manipulate said file in R, Python, whatever. This process is obviously bothersome. Is there anything I can do to alleviate this?Note: this is for a personal project of mine in Cobol, as I'm still learning the language. I know that the actual applications of the scientific notation-like numeric-edited picture are limited.
Last edit: Chibamu Niusrec 2024-08-05
Floating point numbers, except in statistical / scientific applications, are not a common COBOL practice.
With GnuCOBOL I believe you can define a Pic 9 field with 37 base 10 digits.
Using PIC 9(nnn) you can specify whole number values and also specify the number of digits to reserve for the fraction.
PIC 9(7)V999 is a 10 byte field. The 999 to the right of the V is the fraction.
"V" is an assumed decimal point. The "V" will be used as a "virtual" decimal point in any computational expression.
Assignment between floating point and decimal representation is supported.
You should be able to define a large decimal number and move it to and from a floating point number.
Last edit: Ralph Linkletter 2024-08-05
You should try checking the GnuCOBOL Programmer's Guide and also the Programmer's Reference.
https://sourceforge.net/p/gnucobol/code/HEAD/tree/external-doc/guide/PDFs/
(Look for gnucobpg and gnucobpr, and you can choose PDF's either in A4 or USA letter size.)
E for exponent can only be used in numeric literals, such as in a VALUE clause or COMPUTE statement. I don't believe it is a valid character within a numeric-edited PICTURE clause.
I have personally never used floating-point numbers in a COBOL program. Perhaps someone can suggest an easier way to create a printable representation of a floating-point number with the exponent displayed in your preferred format.
I understand. Thank you both for the input.
This is a regression in GnuCOBOL; the only reason that this COBOL2002 feature (also available on IBM) is not in is because of the seldom use of floating point in COBOL.
For some details see [feature-requests:#199] (yes, that's a2017 one!).
Note that we do support floating-point literals since quite some time.
@chaat Could you have a look to add at least the parsing for GnuCOBOL 3?
When we later add the actual support libcob would need both the editing and de-editing part.
Note: to store floating point you could just save a
COMP-2
orFLOAT-DOUBLE
directly to disk (as long as it either isn't a line-sequential file or you have the escape char enabled). The issue with that is that the floating-point would not be readable by a common human, not portable to a different environment and - depending on reading it in - not portable to other programming languages (storing it withSYNC
may be portable, as long as you stay on the same machine and can memcpy that over to a variable matching Cdouble
specifics).Related
Wish List: #199
IBM manuals do allow "E" in the PIC clause:
https://www.ibm.com/docs/en/cobol-zos/6.3?topic=clause-symbols-used-in-picture
https://www.ibm.com/docs/en/cobol-zos/6.3?topic=clause-data-categories-picture-rules