Cobol - big numbers

Author

big numbers

Ladislau Balazsi

2005-08-16, 4:59 pm

Maybe I'm stupid but I ask...

how to work with big numbers in COBOL

n1=0.12* 10**23
n2=0.1234*10**44
n3=n1*n2

DISPLAY ACCEPT THEN SHOW RESULT...

how to declare and work with them...???

thx 4 help...

LACI

Rick Smith

2005-08-16, 5:00 pm

"Ladislau Balazsi" <lacilaci@zappmobile.ro> wrote in message
news:43024772$0$18643$14726298@news.sunsite.dk...
> Maybe I'm stupid but I ask...
>
> how to work with big numbers in COBOL
>
> n1=0.12* 10**23
> n2=0.1234*10**44
> n3=n1*n2
>
> DISPLAY ACCEPT THEN SHOW RESULT...
>
> how to declare and work with them...???

One way to work with such numbers is to use floating-point.
Floating-point did not become part of standard COBOL
until 2002; so, unless you have a 2002 conforming compiler,
you will need to use whatever extensions are available with
the compiler you are using. Since you did not identify that
compiler, the following may not work for you.

An example using Micro Focus COBOL 3.2.
-----
program-id. fp.
data division.
working-storage section.
01 n1-display pic +9.999999E+99.
01 n2-display pic +9.999999E+99.
01 n3-display pic +9.999999E+99.
01 n1 comp-2.
01 n2 comp-2.
01 n3 comp-2.
procedure division.
begin.
display "n1: " with no advancing
accept n1
move n1 to n1-display
display "n2: " with no advancing
accept n2
move n2 to n2-display
compute n3 = n1 * n2
move n3 to n3-display
display "n1 = " n1-display
display "n2 = " n2-display
display "n2 = " n2-display
stop run.
end program fp.
-----

Edited screen activity
-----
n1: 0.12e23
n2: 0.1234e44
n1 = +1.200000E+22
n2 = +1.234000E+43
n2 = +1.234000E+43
-----

Rick Smith

2005-08-16, 5:00 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11g4l6i8haeuh4b@corp.supernews.com...
[snip]

My mistake (an error caused by lack of attention).

> An example using Micro Focus COBOL 3.2.

Should be:
-----
program-id. fp.
data division.
working-storage section.
01 n1-display pic +9.999999E+99.
01 n2-display pic +9.999999E+99.
01 n3-display pic +9.999999E+99.
01 n1 comp-2.
01 n2 comp-2.
01 n3 comp-2.
procedure division.
begin.
display "n1: " with no advancing
accept n1
move n1 to n1-display
display "n2: " with no advancing
accept n2
move n2 to n2-display
compute n3 = n1 * n2
move n3 to n3-display
display "n1 = " n1-display
display "n2 = " n2-display
display "n3 = " n3-display
stop run.
end program fp.
-----

Edited screen activity
-----
n1: 0.12e23
n2: 0.1234e44
n1 = +1.200000E+22
n2 = +1.234000E+43
n3 = +1.480800E+65
-----

Chuck Stevens

2005-08-16, 9:59 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11g4l6i8haeuh4b@corp.supernews.com...

> One way to work with such numbers is to use floating-point.
> Floating-point did not become part of standard COBOL
> until 2002; so, unless you have a 2002 conforming compiler,
> you will need to use whatever extensions are available with
> the compiler you are using.

Correct. 2002 COBOL does include the USAGEs FLOAT-SHORT, FLOAT-LONG and
FLOAT-EXTENDED as well as the ability to construct floating-point literals,
and it also includes extensions to the PICTURE clause that allow for
floating-point edited-numeric items. But the format of these USAGEs are
implementor-defined, as are the capacity, arithmetic, and conversion rules
for them.

Note also that many implementations have some forms of floating-point USAGEs
prior to the introduction of ISO/IEC 1989:2002; Unisys MCP systems use REAL
and DOUBLE for COBOL74 and COBOL85 single- and double-precision
respectively, and used COMP-4 and COMP-5 correspondingly in COBOL(68). IBM
S/370 DOS COBOL-68 seems to have used COMP-1 and COMP-2 similarly. The
Unisys MCP implementations allow floating-point literals but not
floating-point edited-numeric PICTUREs; I can't speak to others.

The current Working Draft for the next COBOL standard includes provision for
the declaration of data items in a decimal-oriented floating-point format,
together with arithmetic rules appropriate to that format, both of which are
language-independent and implementation-independent and for which both the
format and the associated rounding, arithmetic, format conversion and
exception-handling rules are specified insofar as possible by an
international standard currently under development (an updated version of
IEEE 754, which will presumably be adopted at some point as ISO/IEC 60559).
I happen to think that's a Neat Thing, but then I'm prejudiced on the
subject.

-Chuck Stevens

William M. Klein

2005-08-17, 3:59 am

It is also worth noting that the '02 Standard increased the number of digits
required to be supported by a conforming compiler from 18 to 31. This allows
for larger NON-floating-point numbers - but certainly not "super-large".

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:ddto9i$2f3t$1@si05.rsvl.unisys.com...
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:11g4l6i8haeuh4b@corp.supernews.com...
>
>
> Correct. 2002 COBOL does include the USAGEs FLOAT-SHORT, FLOAT-LONG and
> FLOAT-EXTENDED as well as the ability to construct floating-point literals,
> and it also includes extensions to the PICTURE clause that allow for
> floating-point edited-numeric items. But the format of these USAGEs are
> implementor-defined, as are the capacity, arithmetic, and conversion rules
> for them.
>
> Note also that many implementations have some forms of floating-point USAGEs
> prior to the introduction of ISO/IEC 1989:2002; Unisys MCP systems use REAL
> and DOUBLE for COBOL74 and COBOL85 single- and double-precision
> respectively, and used COMP-4 and COMP-5 correspondingly in COBOL(68). IBM
> S/370 DOS COBOL-68 seems to have used COMP-1 and COMP-2 similarly. The
> Unisys MCP implementations allow floating-point literals but not
> floating-point edited-numeric PICTUREs; I can't speak to others.
>
> The current Working Draft for the next COBOL standard includes provision for
> the declaration of data items in a decimal-oriented floating-point format,
> together with arithmetic rules appropriate to that format, both of which are
> language-independent and implementation-independent and for which both the
> format and the associated rounding, arithmetic, format conversion and
> exception-handling rules are specified insofar as possible by an
> international standard currently under development (an updated version of
> IEEE 754, which will presumably be adopted at some point as ISO/IEC 60559).
> I happen to think that's a Neat Thing, but then I'm prejudiced on the
> subject.
>
> -Chuck Stevens
>
>

Sponsored Links