on goto
in [ASM]
|
From: Robert Redelmeier on 8 May 2010 23:53 In alt.lang.asm [FUp set] Sjouke Burry <burrynulnulfour(a)ppllaanneett.nnll> wrote in part: > Nick Keighley wrote: >> lost me. So far as I remember FORTRAN didn't have recursion. Am I >> wrong? Or are you saying even modern Fortran doesn't have recursion? > > If recursion does not exist, I will have to ditch quite > a couple of fortran programs. There is only 1 hitch, you > have to write a 3 line dummy routine, to do the calling, > so a calls b , b calls a. fortran MS 5.1 and later. > Also Fortran77 for Riscos (arc 320 computer) For what problems do you find recursion to be the fastest [CPU runtime] solution method? -- Robert
From: Sjouke Burry on 9 May 2010 00:46 Robert Redelmeier wrote: > In alt.lang.asm [FUp set] Sjouke Burry <burrynulnulfour(a)ppllaanneett.nnll> wrote in part: >> Nick Keighley wrote: >>> lost me. So far as I remember FORTRAN didn't have recursion. Am I >>> wrong? Or are you saying even modern Fortran doesn't have recursion? >> If recursion does not exist, I will have to ditch quite >> a couple of fortran programs. There is only 1 hitch, you >> have to write a 3 line dummy routine, to do the calling, >> so a calls b , b calls a. fortran MS 5.1 and later. >> Also Fortran77 for Riscos (arc 320 computer) > > > For what problems do you find recursion to be the fastest > [CPU runtime] solution method? > > -- Robert > I use it where it makes most sense, for example fractals. Speed is of no concern for me but ease of algorithm expression is.
From: Dave Harris on 9 May 2010 11:34 nathancbaker(a)gmail.com (Nathan) wrote (abridged): > > � while ( data[xInd][yInd][zInd] != value && result != 0) > > � { > > � � � if {++zInd == data[xInd][yInd].size()) { > > � � � � � zInd = 0; > > � � � � � if (++yInd == data[xInd].size()) { > > � � � � � � � yInd = 0; > > � � � � � � � if (++xInd == data.size()) > > � � � � � � � � � result = 0; > > � � � � � } > > � � � } > > � ... > > > > Isn't <something>.size() a method or function call? We'd also want > to eliminate that needless activity from the loop by defining "zMax = > data[xInd][yInd].size()", and etc., before the loop. That would introduce another bug. We're not told that all the arrays are the same size, so for example data[0][0].size() might be different to data[0][0].size(). We could cache the result of size(), but we'd then have to update it when the corresponding index changed. That's easy enough in the original nested-loop code, but gets quite complicated in the single-loop version. (I was going to post some example code, but it was frankly too long and ugly.) This thread has been cross-posted to a lot of groups, and some people seem to be commenting without knowing C++ or knowing what an expression like data[xInd][yInd].size() probably means. The data structure might be declared like: typedef std::vector<int> z_vec; typedef std::vector<z_vec> y_vec; typedef std::vector<y_vec> x_vec; x_vec data; The memory is unlikely to be contiguous. -- Dave Harris, Nottingham, UK.
From: Daniel T. on 9 May 2010 12:44 brangdon(a)cix.co.uk (Dave Harris) wrote: > daniel_t(a)earthlink.net (Daniel T.) wrote (abridged): > > > > > I considered submitting a single loop solution as a joke. It > > > never crossed my mind someone would seriusly propose it! > > > > I seriously proposed it. I think it is the best solution for the > > job (not your code specifically of course, but the idea of a single > > loop traversing a single container.) > > Yes. It led to simple code, but that was partly because all the > complexity was hidden behind an iterator. Nathan Baker's version exposes > some of that complexity, and I think illustrates how hard it is to get it > right. > > For example, you can't just initialise the iterator's members to 0,0,0 > because data.size() might be 0 and data[0][0][0] may not exist. So you > need a loop inside the iterator's constructor to find the first iterator > value that can be dereferenced, and another loop inside the iterator's > increment operator to find the next one. > > I think. If someone posted actual, correct code, I missed it. Did you try > implementing the iterator you suggested? Did it still have 3 loops > really? I didn't post anymore than I did because there isn't enough context to tell what the best solution is. Even though .size() is checked at each level, there may still be an invariant such that all the sizes are the same. People often advocate using nested vectors to implement multi-dimensional arrays, even when they are not ragged arrays, and the OP may have been expressing that sort of code. In a situation where ragged arrays are necessary, it is highly unlikely that they will be treated as a contiguous unit as the OP's code does. But in any case, no more can be said unless a real use-case is presented. All I'm saying is that the assumption that three loops are necessary to express an O(n) algorithm is inappropriate.
From: Nathan Baker on 10 May 2010 00:13
"Dave Harris" <brangdon(a)cix.co.uk> wrote in message news:memo.20100509163449.5892C(a)brangdon.cix.compulink.co.uk... > > Yes. It led to simple code, but that was partly because all the > complexity was hidden behind an iterator. Nathan Baker's version exposes > some of that complexity, and I think illustrates how hard it is to get it > right. > Perhaps the words "simple" and "complexity" have different meanings to different people because of their different training and the goals they've been conditioned to target?? Juha's code uses 3 loop constructs, 4 conditionals, and 2 exit points. Mine uses 1 loop construct, 2 conditionals, and 1 exit point. Nathan. |