Prev: Data Representation in COBOL
Next: xml acucobol
From: Peter Lacey on 10 Jan 2006 22:05 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 11 Jan 2006 02:22 "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 11 Jan 2006 05:05 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 11 Jan 2006 07:37 "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 11 Jan 2006 10:33
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. |