free implementation? factorial?
in [Cobol]
|
Prev: Data Representation in COBOL
Next: xml acucobol
From: William M. Klein on 11 Jan 2006 16:56 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 End-Compute Else Display "Unable to determine FACTORIAL for non-numeric input" End-If > Stop Run. -- Bill Klein wmklein <at> ix.netcom.com "Nicolas Neuss" <firstname.lastname(a)iwr.uni-heidelberg.de> wrote in message news:87d5izqdto.fsf(a)ortler.iwr.uni-heidelberg.de... > 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: Rick Smith on 11 Jan 2006 21:39 "William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message news:9afxf.261259$z82.168398(a)fe12.news.easynews.com... > So (based on your version) what about: [snip] > Compute Result = Function Factorial (Num) [snip] The availability of FUNCTION FACTORIAL was acknowledged in the first post. The request was for code that does not use the function. -----quote 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 12 Jan 2006 09:24 In article <r09as156h8spvqs06mqabbq43j0hla17cv(a)4ax.com>, Howard Brazee <howard(a)brazee.net> 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 algorithm. -- Michael Wojcik michael.wojcik(a)microfocus.com The invigilator is not authorised to give any assistance. -- Peter Howard, "Rubric"
From: Michael Wojcik on 12 Jan 2006 09:16 In article <43C47616.CA7B78FE(a)mts.net>, Peter Lacey <lacey(a)mts.net> 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)microfocus.com 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 13 Jan 2006 00:11
In article <43C3E71D.1476BDC7(a)mts.net>, Peter Lacey <lacey(a)mts.net> wrote: > 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 recursion. Can you think of a better (e.g. easier to understand) example to introduce the concept? |