From: Peter Lacey on
Alain Reymond wrote:
>
> Peter Lacey a écrit :
> > 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 should have added a smile!
>
> the fact is that factorial is usualy the first approach to recursion
> when teached to students.

If you say so.

> As the other solution is quite easy, the aim was to show that an elegant
> (I hope so!) solution also exists in Cobol using the same concepts as in
> C or Pascal or java which probably are more teached to students than Cobol.
>
> Regards.
>
> Alain

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
From: Karl Kiesel on
"Chuck Stevens" <charles.stevens(a)unisys.com> schrieb im Newsbeitrag
news:dq0q64$2hee$1(a)si05.rsvl.unisys.com...
>...
> Again, I know full well that mucking with control flow during execution of
> a PERFORM is frowned upon as Bad Practice, but I still haven't seen
> anything that leads me to believe *any* COBOL standard expressly forbids
> it.

what about STD 1985, PERFORM general rule (14) (page VI-120)?

This rule does not distinguish between various types (directly, indirectly,
same, different,...) of PERFORM statements; thus it also applys to the case
where 'an active PERFORM statement' and 'another active PERFORM statement'
are the *same* statment! It also does not talk of passing *thru* an exit but
of 'allow control to pass *to* the exit of the other statement' and
explicitly states that 'two or more such active PERFORM statements may not
have *a common exit*'
For me this looks definitely as if overlapping (especially recursive)
PERFORM statements were not conforming to the standard. But since various
implementations have lifted these restrictions on perform statements, this
seems to have resulted in entry 37) of the undefined language element list
of STD 2002.

K. Kiesel


From: Nicolas Neuss on
Peter Lacey <lacey(a)mts.net> 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: Karl Kiesel on

"Nicolas Neuss" <firstname.lastname(a)iwr.uni-heidelberg.de> schrieb im
Newsbeitrag news:87d5izqdto.fsf(a)ortler.iwr.uni-heidelberg.de...

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

well, following the rule of thumb, that 10% of a COBOL programs is the
algorithm and 90% are data validation, error recognition and recovery, at
least the overflow of the result could be trapped with an on size error
phrase since the program gives wrong results for any numbers > 11

K. Kiesel


From: Howard Brazee on
On Wed, 11 Jan 2006 13:37:58 +0100, "Karl Kiesel"
<Karl.Kiesel(a)fujitsu-siemens.com> wrote:

>> This version works for my implementation, and is acceptable for Cobol
>> programmers, I hope. But I am open to further improvements...
>
>well, following the rule of thumb, that 10% of a COBOL programs is the
>algorithm and 90% are data validation, error recognition and recovery, at
>least the overflow of the result could be trapped with an on size error
>phrase since the program gives wrong results for any numbers > 11

I second this motion. CoBOL isn't about algorithms. Professional
programming isn't about algorithms.

If you want to show the differences between the languages, make sure
you show the very different ways they have of handling errors. Which
means you need to also include the environment - so that an OO program
tosses a handleable error, or a CoBOL in a batch job displays an error
message and passes a return code.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: Data Representation in COBOL
Next: xml acucobol