From: William M. Klein on
So (based on your version) what about:

> identification division.
> program-id. FactorialPgm.
> data division.
> working-storage section.
> 01 Working-Fields
05 result pic 9(8).
> 05 Num pic 9(8). *> Using "N" as a data-name is not
> considered good COBOL.
05 Num-Redefined Redefines Num Pic X(8).
> procedure division.
> main-line.
> display "Enter a positive number: "
with no advancing *> with no advancing MIGHT produce
undesired results
> accept n
If Num-Redefined numeric *> some accept/display may not
prevent bad input for PIC N fields
Compute Result = Function Factorial (Num)
On Size Error
Display "Number larger than 8 digits"
Not On Size Error
> display "Factorial(" Num ")= " result
Display "Unable to determine FACTORIAL for non-numeric
> Stop Run.

Bill Klein
wmklein <at>
"Nicolas Neuss" <firstname.lastname(a)> wrote in message
> Peter Lacey <lacey(a)> writes:
>> Elegance is in the eye of the beholder, to a certain extent. But for
>> the practical programmer/designer, a sort of "Ockham's Razor" approach
>> should be applied: if there is more than one solution/method to solve
>> the problem, then the simplest one is the one to use. As you say, the
>> other solution is quite easy.
>> I stand to be corrected on this, of course, but AFAIK recursion (in the
>> sense of a program or a paragraph calling itself) is rarely necessary.
>> PL
> I do not necessarily want a recursive solution. I want a solution which
> fits the language best. At the moment, combining the suggestions obtained
> here, I favor the following:
> identification division.
> program-id. factorial.
> environment division.
> data division.
> working-storage section.
> 77 result pic 9(8).
> 77 n pic 9(8).
> 77 i pic 9(8).
> procedure division.
> main-line.
> display "Enter a positive number: " with no advancing
> accept n
> move 1 to result.
> perform varying i from 1 by 1 until i>n
> multiply result by i giving result
> end-perform
> display "Factorial(" n ")= " result
> stop run.
> This version works for my implementation, and is acceptable for Cobol
> programmers, I hope. But I am open to further improvements...
> Thank you very much,
> Nicolas.

From: Rick Smith on

"William M. Klein" <wmklein(a)> wrote in message
> So (based on your version) what about:
> Compute Result = Function Factorial (Num)

The availability of FUNCTION FACTORIAL was
acknowledged in the first post. The request was for
code that does not use the function.

Furthermore, as much as I understand the factorial function
is already available in modern COBOL implementations, so it is difficult to
find a suitable program (at least, what I found with Google is either
untested or looks suboptimal). If factorial would not be available, how
would it look like in modern COBOL?
-----end quote

From: Michael Wojcik on

In article <r09as156h8spvqs06mqabbq43j0hla17cv(a)>, Howard Brazee <howard(a)> writes:
> I second this motion. CoBOL isn't about algorithms. Professional
> programming isn't about algorithms.

Sometimes it is. I've watched professional COBOL programmers try
to solve serious performance issues with production applications
that could, and should, be remedied by using a more appropriate

Michael Wojcik michael.wojcik(a)

The invigilator is not authorised to give any assistance.
-- Peter Howard, "Rubric"
From: Michael Wojcik on

In article <43C47616.CA7B78FE(a)>, Peter Lacey <lacey(a)> writes:
> I stand to be corrected on this, of course, but AFAIK recursion (in the
> sense of a program or a paragraph calling itself) is rarely necessary.

Recursion is never "necessary", in the strict sense, for any
algorithm that can be implemented in a deterministic Turing machine.
There are proofs by construction that any such recursive algorithm
can be transformed into an iterative one. One, for example, converts
all recursion to tail recursion with continuation-passing; tail
recursion can be replaced by branching, since it's never necessary to
return to previous invocations.

Recursion isn't important because it's necessary. It's important
because it's used extensively in certain branches of mathematics
which provide important results for computer science, and because
it's a way of thinking that's significantly different from iteration -
and thinking also provides important results for computer science :-).

That said, for a trivial function like factorial, the "best"
implementation depends on the goal. Are we implementing it to learn
how to take a common mathematical definition and realize it in a
computer program? Then recursion is better. Are we implementing it
to learn how to use the tools provided by the language in the
simplest and clearest way possible? Then depending on the COBOL
dialect we're targetting, iteration may well be the better choice.
Are we implementing it because we need to make extensive use of it in
calcuations? Then we should be using the built-in function, if there
is one in our dialect; and if not, we should consider what ranges we
need to satisfy, and how we will avoid overflow, and whether it is
critical to performance; and the best choice might not be at all
obvious (though it's unlikely to be recursive).

Michael Wojcik michael.wojcik(a)

This book uses the modern technology to explain the phenomemon in the world
of Japanese animation. If you love anime so much, you'd better read this.
After you read it, you may agree that is destroying the dream of the child.
Needs Chinese viewing system. -- The Goodboy Scientific
From: Joe Zitzelberger on
In article <43C3E71D.1476BDC7(a)>, Peter Lacey <lacey(a)>

> Alain Reymond wrote:
> >
> > Nicolas,
> >
> > Try to use the recursive posssibilities of modern Cobol. This is good
> > for teaching and showing that Cobol is no more an amount of go to's in
> > spaghetti code (troll)...
> >
> Why teach the more complicated method first? This isn't a case where
> using recursion is preferable. Also (troll-reply) an instructor
> shouldn't get involved in religious wars unless that happens to be the
> course subject.
> PL

I would disagree.

For production code, you would write this as a loop. But this is a
great example to help students understand how recursion actually works.

Simple parameters, easy to grasp output....factorial() is made to teach

Can you think of a better (e.g. easier to understand) example to
introduce the concept?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: Data Representation in COBOL
Next: xml acucobol