on goto
in [General Programming]
|
From: Leif Roar Moldskred on 8 May 2010 17:31 In comp.programming Richard Heathfield <rjh(a)see.sig.invalid> wrote: > > If N is the number of 3D points, you're right. If N is the size of one > dimension (which is how I was thinking of it), it's O(LMN). If L == M > and L == N, that makes it O(N^3). The point is that it doesn't matter whether you structure your search as one single, overarching loop or three nested loops. In either case it's a bog standard linear search, where each element is visited no more than once. If we set N to be the size of the search space then _both_ ways to do it is O( N ) and if we set N to be the length of one edge of a cubic search space then _both_ ways are O( N^3 ). -- Leif Roar Moldskred
From: Seebs on 8 May 2010 17:37 On 2010-05-08, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > Seebs wrote: >> On 2010-05-02, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> Because, in some cases, the checks against a[i] make it harder to follow >> the code. > In my experience, it is generally easier to follow the code if it has a > clear structure. I would agree that it is *GENERALLY* easier. But in some cases it's not. The vanilla loop idiom ("for (i = 0; i < N; ++i)") has a HUGE weight of idiomatic clarity -- it does not require noticable attention to model it, and that clarity is lost as soon as you change the loop condition. In short: for (i = 0; i < N; ++i) if (foo(i)) return i; return -1; is nearly always much easier for a programmer to grok in fullness than for (i = 0; i < N && !foo(i); ++i) ; if (i != N) return i; else return -1; > The example posted upthread isn't actually terribly > hard to follow, but I've seen (and had to maintain) some ghastly messes > in my time, where returns and breaks seemed to be inserted into the code > almost at random, and figuring out what the code was supposed to *do* > was way harder than it should have been. Agreed. But going from "in general, it is better to have the full loop condition stated, but there may be exceptions where the clarity of an idiom trumps this" to "it is absolutely in every case without any possible exceptions no matter what worse to use any kind of break or return from within a loop" is unsupportable. > That's an interesting take on it, but I would read my version of the > loop control as "look through every element of the array in order until > you've either found what you're looking for or discovered that it's not > there". Agreed -- and that's a much more complicated condition. Simple rules with exceptions are easier for humans to process than complex rules. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Daniel T. on 8 May 2010 20:58 Seebs <usenet-nospam(a)seebs.net> wrote: > On 2010-05-08, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > > Seebs wrote: > >> On 2010-05-02, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > >> Because, in some cases, the checks against a[i] make it harder to follow > >> the code. > > > In my experience, it is generally easier to follow the code if it has a > > clear structure. > > I would agree that it is *GENERALLY* easier. > > But in some cases it's not. > > The vanilla loop idiom ("for (i = 0; i < N; ++i)") has a HUGE weight of > idiomatic clarity -- it does not require noticable attention to model it, > and that clarity is lost as soon as you change the loop condition. > > In short: > for (i = 0; i < N; ++i) > if (foo(i)) > return i; > return -1; > > is nearly always much easier for a programmer to grok in fullness than > for (i = 0; i < N && !foo(i); ++i) > ; > if (i != N) > return i; > else > return -1; While both of the above are much worse than: int i = 0; while (i < N && !foo(i)) ++i; return i; The above is a standard idiom in C++.
From: Nick Keighley on 8 May 2010 21:01 On 8 May, 17:46, Tim Streater <timstrea...(a)waitrose.com> wrote: > In article > <5dd9bdc8-4dc4-4537-84a0-885c4c92f...(a)l28g2000yqd.googlegroups.com>, > Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote: > > On 8 May, 01:41, Lie Ryan <lie.1...(a)gmail.com> wrote: > > > > I've never heard of any programming languages that doesn't support > > > > recursion. [...] > > FORTRAN (in its original form), Coral-66 you had to use a special > > keyword to indicate a function was recursive. Some BASICs probably > > didn't alow recursion. But these all qualify as "ancient" (and maybe > > jocular!) > > What FORTRAN are you referring to. I never saw it in any FORTRAN up to > 1978 (the last time I used FORTRAN). 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?
From: Sjouke Burry on 8 May 2010 23:04
Nick Keighley wrote: > On 8 May, 17:46, Tim Streater <timstrea...(a)waitrose.com> wrote: >> In article >> <5dd9bdc8-4dc4-4537-84a0-885c4c92f...(a)l28g2000yqd.googlegroups.com>, >> Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote: >>> On 8 May, 01:41, Lie Ryan <lie.1...(a)gmail.com> wrote: > > >>>>> I've never heard of any programming languages that doesn't support >>>>> recursion. > [...] >>> FORTRAN (in its original form), Coral-66 you had to use a special >>> keyword to indicate a function was recursive. Some BASICs probably >>> didn't alow recursion. But these all qualify as "ancient" (and maybe >>> jocular!) >> What FORTRAN are you referring to. I never saw it in any FORTRAN up to >> 1978 (the last time I used FORTRAN). > > 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) |