on goto
in [General Programming]
|
From: Seebs on 10 May 2010 20:55 On 2010-05-11, Keith Thompson <kst-u(a)mib.org> wrote: > "Daniel T." <daniel_t(a)earthlink.net> writes: >> Seebs <usenet-nospam(a)seebs.net> wrote: >>> I'm working on a roguelike game. I have a dungeon, which consists of >>> levels, and the levels are not necessarily all the same size. Each >>> level is itself a 2D grid of points. It is quite conceivable to want >>> to ask the question "is there any point in the dungeon which contains >>> a foo". At this point, the obvious thing to do is >>> for each level >>> for each row >>> for each column >>> is there a foo? >> I disagree. The obvious thing is to go through your list of MOB's and >> see if any of them are foos. Your list of MOB's will likely be a 1D >> vector or linked list. At most you have a list of MOB's per level and >> even there, each level will be encapsulated. Essentially a recursive >> algorithm. > What's a MOB? In many computer games, creatures are called "mobs" (short for mobiles, because they can move). It's probably incorrect to turn it into block caps, since the word did not originate as an initialism, but I could make sense of it in context. (It's definitely incorrect to put an apostrophe on the plural, though.) -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 10 May 2010 23:39 Seebs <usenet-nospam(a)seebs.net> wrote: > On 2010-05-10, Daniel T. <daniel_t(a)earthlink.net> wrote: > > > Because there's nothing saying they are... > > > There is nothing saying anything at all. > > Good reason not to start adding unsupported assumptions, then. > > You should not assume that they are contiguous, or that they aren't; > you should write code that will work either way unless you have information > saying otherwise. The code I wrote made no more assumptions than the original example did, it was more abstract and actually made fewer assumptions than the original. > > The obvious thing is to go through your list of MOB's and > > see if any of them are foos. Your list of MOB's will likely be a 1D > > vector or linked list. At most you have a list of MOB's per level and > > even there, each level will be encapsulated. Essentially a recursive > > algorithm. > > What if "foo" isn't a "MOB"? What if "foo" is a kind of a thing of which > there is no master list, just a list associated with each location? Someone else is already beating you up on this one, so I'll just say this... "What if the situation is exactly such that the best solution is nested for loops and an early return?" To that I answer, then use nested for loops and an early return. What is your point? > > ... what is your goal in continuing this thread? What is it you are > > trying to get me to admit to that I haven't already admitted? > > I guess I'm just pointing out that all of the "simplifications" I've > seen have been simplifications which relied on massive and unsupported > assumptions, and more importantly, assumptions which are wrong often > enough for it to be a serious problem. Well, I have to agree with you about the "massive unsupported assumptions," after all every possible assumption you can make about the code is unsupported because the code exists in a vacuum. Without a problem to solve, any claim that this particular solution (or any other solution) is best is ridiculous. My observation is that people often get caught up working at much too low a level than they should, and depending on what problem is being solved, code like the nested for loop example we have been discussing is indicative of that sort of thinking.
From: Daniel T. on 10 May 2010 23:42 In article <MPG.26523d13dae704169896ed(a)news.eternal-september.org>, Dann Corbit <dcorbit(a)connx.com> wrote: > In article <daniel_t-BE382C.19303110052010(a)70-3-168- > 216.pools.spcsdns.net>, daniel_t(a)earthlink.net says... > > > > Seebs <usenet-nospam(a)seebs.net> wrote: > > > On 2010-05-10, Daniel T. <daniel_t(a)earthlink.net> wrote: > > > > > > > Why shouldn't I assume that the data are contiguous? > > > > > > Because there's nothing saying they are... > > > > There is nothing saying anything at all. > > > > > > In what context is a short-circuit linear search appropriate through > > > > a 3-D ragged arrayed container? Just because that's the way you want > > > > it so that you can stand on your soapbox and say, "see I told you > > > > so"? > > > > > > Okay, here's a nice concrete case from code I've actually written once > > > upon a time, or something much like it. > > > > > > I'm working on a roguelike game. I have a dungeon, which consists of > > > levels, and the levels are not necessarily all the same size. Each > > > level is itself a 2D grid of points. It is quite conceivable to want > > > to ask the question "is there any point in the dungeon which contains > > > a foo". At this point, the obvious thing to do is > > > for each level > > > for each row > > > for each column > > > is there a foo? > > > > I disagree. The obvious thing is to go through your list of MOB's and > > see if any of them are foos. Your list of MOB's will likely be a 1D > > vector or linked list. At most you have a list of MOB's per level and > > even there, each level will be encapsulated. Essentially a recursive > > algorithm. > > > > for each level > > is there a foo? > > > > I ask again, what is your goal in continuing this thread? What is it you > > are trying to get me to admit to that I haven't already admitted? > > Are you really unable to conceive of a data structure with more than one > dimention? I'm quite able to conceive of such structures. I do depth first and breadth first searches all the time, nested loops are rarely the answer to them though.
From: Richard Heathfield on 11 May 2010 01:26 Willem wrote: > Let's take your example to make my point: > > > Richard Heathfield wrote: > ) found = 0; > ) for(x = 0; !found && x < xlim; x++) > ) { > ) for(y = 0; !found && y < ylim; y++) > ) { > ) for(z = 0; !found && z < zlim; z++) > ) { > ) if(haystack[x][y][z] == needle) > ) { > ) point_assign(p, x, y, z); > ) found = 1; > ) } > ) } > ) } > ) } > ) return found; > > The benefit of your code, you say, is that you only need to look at the > conditional in the for statement, to see when the loop will end, right ? No, the benefit of SESE is that you know that every loop has a single entry point and a single exit point. The advantage gained by having this knowledge is considerably less when the loop is trivially small, as in this case. It's a bit like driving on the left (or, in some countries, the right!) - it offers almost no safety edge at night on empty roads, but it's still a good habit to cultivate. <snip> > PS: I saw that you acknowledged not having refuted any arguments, so > feel free to ignore this as well. I plan to. > PPS: Yes, that 'PS' is baiting you. Bait away. My preference for SESE is rooted in some truly appalling SEME code that I've had to maintain in the past. It may well be that you've been much luckier than me - perhaps you haven't been exposed to some of the horrors that SEME can let loose on the maintenance programmer. I'm not about to start convoluting my control flow for your satisfaction, and you're not about to start convoluting your loop conditions for mine... > I very much dislike it when people > stop arguing their side with a notion of "we're not going to agree", > while there are sound, factual arguments on the table. ....so we're already at the point in the argument that you very much dislike, bait or no bait. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Phil Carmody on 11 May 2010 01:42
Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-05-10, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> for(x = 0; !found && x < xlim; x++) > for (x = 0; x < xlim; ++x) { > Because the test conditions aren't part of the standard "loop over array" > idiom, I have to track both parts of the test condition separately, and doing > that for three layers of looping chews up six short-term memory slots, and > the index variables use up three more, leaving me solidly past my short-term > memory budget without even looking at the inner loop. For the form using > the pure idiom, I'm only using three slots -- I have x, y, and z as "the > current indexes in the loop". There's a 4th slot in use. It's three trivial loops and one trivial special case versus three non-trivial loops I agree that I view the former as simpler, (but am more likely to be a break-user than a return-user). Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1 |