Menu

PICTURE clause: Exponent symbol not supported?

2024-08-05
2024-08-05
  • Chibamu Niusrec

    Chibamu Niusrec - 2024-08-05

    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:

           identification division.
           program-id. sample.
           data division.
           working-storage section.
           01 n float-long.
           01 numeric-edited-1 pic -9(15).9(15) .
        *>    01 numeric-edited-2 pic -9(1).9(15)E-99.
           procedure division.
           100-main.
               move 3.4587124e-60 to n
               display "Very small `n`: " n
               move n to numeric-edited-1
               display "Truncated result: " numeric-edited-1
    
               stop run.
    

    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
    • Ralph Linkletter

      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
    • Arnold Trembley

      Arnold Trembley - 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.

       
      👍
      1
  • Chibamu Niusrec

    Chibamu Niusrec - 2024-08-05

    I understand. Thank you both for the input.

     
  • Simon Sobisch

    Simon Sobisch - 2024-08-05

    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).

     

    Related

    Wish List: #199

Anonymous
Anonymous

Add attachments
Cancel