Re: on goto

Discussion in 'C++' started by Dave Harris, May 10, 2010.

  1. Dave Harris

    Dave Harris Guest

    (Daniel T.) wrote (abridged):
    > > I would be interested in code that solved the same problem that
    > > the original code solved. Or are you agreeing that the original
    > > code was the best, for that problem? Can you only do better if
    > > you change the problem by adding extra invariants?

    >
    > Am I adding extra invariants? I don't know what the invariants are,
    > and I have no reason to believe that the code presented solved any
    > problem at all.
    >
    > That's part of the point I'm trying to make here. We have been
    > handed an incomplete solution to a nonexistent problem and you are
    > asking me if I could write code that "solved the same problem..."
    > Here you go:
    >
    > int main() { }
    >
    > My example above has the benefit of actually being able to compile
    > and run. You can't do that with the original example.


    The original code was:

    Value_t* MyClass::findValue(const Value_t& value)
    {
    for(size_t xInd = 0; xInd < data.size(); ++xInd)
    for(size_t yInd = 0; yInd < data[xInd].size(); ++yInd)
    for(size_t zInd = 0; zInd < data[xInd][yInd].size(); ++zInd)
    {
    if(data[xInd][yInd][zInd] == value)
    return &data[xInd][yInd][zInd];
    }

    return 0;
    }

    If you are truly saying you don't understand what problem this code is
    trying to solve, to the point where you claim "int main() { }" is solving
    the same problem, then I have trouble believing you are debating in good
    faith. How can your code comprehension skills be so poor?

    If it helps, I'll add some code.

    #include <vector>

    using namespace std;
    typedef int Value_t;
    typedef vector<Value_t> z_vec;
    typedef vector<z_vec> y_vec;
    typedef vector<y_vec> x_vec;

    struct MyClass {
    x_vec data;

    void test();
    Value_t *findValue( const Value_t& value);
    };

    int main() {
    MyClass().test();
    }

    void MyClass::test() {
    findValue( 0 );
    }

    Putting this in front of the original code is enough to make it compile.
    Any competent C++ programmer could have come up with it. I'll let you
    write some code to initialise MyClass::data from stdin yourself. If you
    are truly incapable of doing that, then I have to question whether your
    opinions are worth any weight at all. (I don't need to see the code. I
    just want you to stop being obtuse, when you clearly know better.)

    There are other ways to define data etc so that the original code
    compiles. It shouldn't be necessary to assume more about the problem than
    what the original code gave us, which was basically operator[] and size()
    as used. That was enough for the original code. Alternative solutions
    ought to work with any reasonable definitions, including this one.

    You shouldn't assume that the data are contiguous, or that someone else
    will write a convenient magic iterator for you.

    -- Dave Harris, Nottingham, UK.
    Dave Harris, May 10, 2010
    #1
    1. Advertising

  2. Dave Harris

    Seebs Guest

    On 2010-05-10, Daniel T. <> wrote:
    > Why shouldn't I
    > assume that the data are contiguous?


    Because there's nothing saying they are, and making an assumption without
    any support beyond "this would make my code simpler" seems counterproductive.

    > 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?

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 10, 2010
    #2
    1. Advertising

  3. Dave Harris

    Dann Corbit Guest

    In article <daniel_t-BE382C.19303110052010@70-3-168-
    216.pools.spcsdns.net>, says...
    >
    > Seebs <> wrote:
    > > On 2010-05-10, Daniel T. <> 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 suggest that a web search for the terms "octree" and "quadtree" may
    prove interesting to you.

    See, for instance:
    http://en.wikipedia.org/wiki/Octree
    http://en.wikipedia.org/wiki/Quadtree

    I would be very keen to see a data structure that can model weather on
    the surface of the earth and which does not consist of many levels
    (besides spherical coordinates, we have elevation, temperature,
    pressure, humidity, wind direction, wind velocity, etc.)
    See, for instance, NCAR:
    http://ngwww.ucar.edu/
    Dann Corbit, May 11, 2010
    #3
  4. "Daniel T." <> writes:
    > Seebs <> wrote:
    >> On 2010-05-10, Daniel T. <> 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.


    Then why are you assuming anything?

    >> > 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.


    What's a MOB?

    > for each level
    > is there a foo?


    And how do you ask whether there's a foo on a given level?

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 11, 2010
    #4
  5. Dave Harris

    Lew Pitcher Guest

    On May 10, 2010 20:03, in comp.lang.c, wrote:

    > "Daniel T." <> writes:

    [snip]
    >> for each level
    >> is there a foo?

    >
    > And how do you ask whether there's a foo on a given level?


    ...

    struct fooType *thisFoo = fooRoot;

    ...

    while (thisFoo != NULL && thisFoo->level != target_level)
    thisFoo = thisFoo->nextFoo;

    if (thisFoo == NULL)
    return NO_FOO_ON_LEVEL;
    else
    return FOO_FOUND_ON_LEVEL;



    HTH ;-)
    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
    Lew Pitcher, May 11, 2010
    #5
  6. Dave Harris

    Seebs Guest

    On 2010-05-10, Daniel T. <> wrote:
    > Seebs <> wrote:
    >> On 2010-05-10, Daniel T. <> 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.


    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.

    >> 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 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?

    Not a purely theoretical question here; in the roguelike I did, this was
    basically the case for a number of things, such as items. Each creature
    had a list of items it was holding. There did not exist, anywhere, a master
    list of items. Or a master list of creatures. Locality of reference FTW...
    As long as you don't need to do a search like that. :)

    > 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?


    You didn't ask me that, you asked someone else that.

    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. There is no general expectation that multidimensional
    data structures are contiguous in memory in C; it is much more common for
    them to consist of numerous allocated regions which are non-contiguous.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 11, 2010
    #6
  7. Dave Harris

    Seebs Guest

    On 2010-05-11, Keith Thompson <> wrote:
    > "Daniel T." <> writes:
    >> Seebs <> 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 /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 11, 2010
    #7
  8. Dave Harris

    Phil Carmody Guest

    Seebs <> writes:
    > On 2010-05-11, Keith Thompson <> wrote:
    >> "Daniel T." <> writes:
    >>> Seebs <> 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).


    Down staircases are not usually mobile, and I was searching for the
    down staircase.

    > 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.)


    I think the ggpp was just trying to blag that he was familiar
    with the field in question, and therefore his view must carry
    more weight about implementation issues. Is there a commonly-
    named logical fallacy for misdirection through use of jargon?

    Phil
    --
    I find the easiest thing to do is to k/f myself and just troll away
    -- David Melville on r.a.s.f1
    Phil Carmody, May 11, 2010
    #8
  9. Dave Harris

    Seebs Guest

    On 2010-05-11, Daniel T. <> wrote:
    > Seebs <> wrote:
    >> 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?


    My point is: In the case where that loop would have been written at all,
    the multiple-exit variant would be by far the cleanest solution. Every
    alternative provided has either been noticably more complex, or been
    reliant on an obviously-different data structure than the original addressed.

    I think in this case I'm pretty much in agreement with you on the issue;
    the correct thing to do is make a decision in each case based on the
    circumstances at hand.

    My objection is to having people invent things ("you look through the list
    of foos") which presume a wildly different data structure than had been
    suggested.

    > 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.


    That's a good point. I have certainly seen such loops which were indubitably
    a result of bad planning.

    I guess, offered as "this will necessarily work as a replacement", I find
    most of the replacements unappealing. Offered as "this is enough prettier
    that perhaps the data should be structured to suit it", many of them might
    be a step forwards... Depending, of course, on the specific data.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 11, 2010
    #9
  10. Dave Harris

    Seebs Guest

    On 2010-05-11, Richard Heathfield <> wrote:
    > Seebs 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?


    > No, that's a terrible way to do it.


    > You already have a list of foos, properly ordered for fast searching.


    No, I don't.

    Why are you running a binary search on this specific array to see whether
    an integer is found in it? You already have a list of integers, properly
    ordered for fast searching; just run through that list and then find out
    which array the integer you want is contained in.

    .... or don't.

    > If you don't already have a list of foos, then you are excusing one flaw
    > in your program by the existence of another flaw in your program. Two
    > bugs don't make a sensible programming strategy.


    I disagree. It is not at all obvious that "foo" is necessarily a type of
    thing that ought to have a central list. When doing a model of a world,
    it is quite often the case that there are many hundreds of types of objects
    which might exist, and each location has a list of the objects it contains.
    A single centrally sorted list of all the objects of each type would be
    ludicrous. A single centrally sorted list of all the objects which exist
    anywhere would be of extremely marginal utility. In particular, for the
    case of, say, a roguelike game which includes multiple dungeons, searching
    a given dungeon (using the nested loop) would be orders of magnitude faster
    than searching a complete list of every object stored anywhere in the game.

    In short:

    It depends. There exist problem spaces for which a nested search really is
    the right tool. There exist others for which it isn't. Dogmatically
    asserting that every problem for which a nested loop is the best solution
    exists only because of some other arbitrary flaw is pointless. We might
    as well point out that English is absolutely the clearest and most expressive
    language, because anyone who wants to say something which is not most clearly
    expressed in English is clearly saying something stupid.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 11, 2010
    #10
  11. On 11 May, 06:49, Richard Heathfield <> wrote:
    > Seebs wrote:
    > > 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?

    >
    > No, that's a terrible way to do it.
    >
    > You already have a list of foos, properly ordered for fast searching.
    > Search the list.
    >
    > If you don't already have a list of foos, then you are excusing one flaw
    > in your program by the existence of another flaw in your program. Two
    > bugs don't make a sensible programming strategy.
    >
    > --
    > 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
    Nick Keighley, May 11, 2010
    #11
  12. On 11 May, 06:49, Richard Heathfield <> wrote:
    > Seebs wrote:


    > > 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?

    >
    > No, that's a terrible way to do it.
    >
    > You already have a list of foos, properly ordered for fast searching.
    > Search the list.
    >
    > If you don't already have a list of foos, then you are excusing one flaw
    > in your program by the existence of another flaw in your program. Two
    > bugs don't make a sensible programming strategy.


    Richard <no-name>
    [response to same post]


    ****
    If you were a complete idiot maybe. More sensible is to have a
    structure
    representing each game object as there are almost certainly less of
    them
    than squares on the grid.

    So it would be


    forall(game objects in this level)
    if its a foo ....
    ****

    good grief, they're agreeing...
    Nick Keighley, May 11, 2010
    #12
  13. Dave Harris

    Richard Bos Guest

    Richard <> wrote:

    > Seebs <> writes:
    >
    > > 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?

    >
    > If you were a complete idiot maybe. More sensible is to have a structure
    > representing each game object as there are almost certainly less of them
    > than squares on the grid.


    You have a list of all altars in the dungeon? Why, for goodness' sake?
    The only thing important about them is that location L,R,C contains an
    altar, which is something which should be noted at the location (just as
    if there were a staircase, or a trap).
    Almost all of the uses of an altar depend only on there being something
    in L,R,C and that something being an altar. The only time you want to
    know where the next altar is, is when the player asks for one using the
    far-travel command; at that point, your time is bounded by keyboard
    interaction, so searching every location on the current level is
    perfectly acceptable.

    Richard
    Richard Bos, May 11, 2010
    #13
  14. Dave Harris

    Seebs Guest

    On 2010-05-11, Richard Heathfield <> wrote:
    > Seebs wrote:
    >>> You already have a list of foos, properly ordered for fast searching.


    >> No, I don't.


    > Then I suggest you get one.


    It's often completely unsuitable to the problem at hand.

    >> Why are you running a binary search on this specific array to see whether
    >> an integer is found in it? You already have a list of integers, properly
    >> ordered for fast searching; just run through that list and then find out
    >> which array the integer you want is contained in.


    > That's precisely why I'm running a *binary* search on this specific
    > array. Maybe it's my fault, but I'm not seeing your point here. I
    > originally advocated searching a properly sorted data structure instead
    > of a brute force search, and you seem to be asking me why I'm doing that
    > instead of... doing that.


    My point is that there are many examples of data types for which it would
    make no sense at all to have a single master list of all objects of that
    data type. Integers might be one. Objects in a roguelike game are likely
    another; there's no obvious reason to have a master list of them, because
    they are all more reasonably associated with some specific container.

    > Let's think about that, shall we? The original 3-nested loop was looking
    > for a particular object in, presumably, 3-D space. Let us be kind and
    > assume that the search was already localised to a particular dungeon. So
    > presumably we're looking at a 3D version of Rogue, where objects might
    > be on a shelf, or dangling from the ceiling, or perhaps currently in flight.


    I was thinking "on any of multiple dungeon levels".

    > Let us assume further that our location co-ordinates have a granularity
    > of one foot. We imagine a dungeon 10' tall, with floor dimensions 20'
    > times 30'. That's 6,000 cells to search. Searching every cell until we
    > find (or fail to find) the object involves an average search of 3,000
    > cells. When the object isn't present, we have to search the whole space
    > - 6,000 cells.


    Yes.

    > We're looking for a treasure chest. We could have a list of objects and
    > their locations. We could index that list in various ways, one of which
    > is by object, dungeon, and location within the dungeon. For the brute
    > force search to be more efficient, log2(number of treasure chests) would
    > have to exceed 3,000. You wouldn't be able to chuck a brick without
    > hitting at least a million chests.


    If searching is hugely common, maybe. If searching is rare, though, the
    cost of *maintaining* three sorted lists of treasure chests, and three sorted
    lists of every other object type in the game, plus three sorted lists of
    each of many categories of objects in the game, MASSIVELY overwhelms the
    cost of the brute-force search.

    And in reality, that's the case -- it is extremely common to want to look
    at "the objects in this specific location", and extremely rare to want to
    ask questions like "are there any objects of type X".

    The reasonable thing to do is write the search for objects of type X in
    a way that is probably slow but certainly simple and requires little
    maintenance, rather than developing and maintaining a huge number of variously
    sorted lists.

    In short: The proposal to create a sorted list is an extremely premature
    optimization. Unless we have concrete evidence that the brute-force search
    is hurting execution time, there's not (yet) any reason to avoid it.

    > I think you have yet to demonstrate a problem space where a nested
    > search really is the right tool. That is not to say that no such problem
    > space exists, however, and I am prepared to grant that it /does/ exist.
    > But, in solving that problem, I would still stick to my style rule,
    > because I find it easier to read SESE code than I do to read SEME code.


    If time and resources allowed, I'd love to test that. It would be very
    interesting to come up with a large pool of things all of which are
    comparably-well-written versions of SESE and SEME implementations of
    the same loops.

    My naive exppectation would be that, human cognition having a great deal
    of common ground, there would be many cases in which the SEME version would
    *in fact* be more readable. Meaning that, say, if we had you and a large
    number of other people who have the same views and preferences read all
    these loops and tested for common mistakes in reading loops, we'd find
    that there were many fewer errors with the SEME versions than the SESE
    versions.

    The only data point I have (and it's not large enough to justify a firm
    conclusion) supports this -- we had multiple people misread a SESE loop
    which no one misread when it was SEME.

    >> Dogmatically
    >> asserting that every problem for which a nested loop is the best solution
    >> exists only because of some other arbitrary flaw is pointless.


    > I don't recall making any dogmatic assertions about nested loops, and I
    > certainly don't recall using the word "every" in such a context. Are you
    > sure you're not trying to extend my position?


    Hmm. Not entirely.

    >> We might
    >> as well point out that English is absolutely the clearest and most expressive
    >> language, because anyone who wants to say something which is not most clearly
    >> expressed in English is clearly saying something stupid.


    > Actually, well-written C is much clearer than well-written English. I
    > would accept that it is not always quite so expressive, though. :)


    Heh.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 11, 2010
    #14
  15. Dave Harris

    Lie Ryan Guest

    On 05/11/10 18:26, Richard Heathfield wrote:
    > Seebs wrote:
    >> On 2010-05-11, Richard Heathfield <> wrote:
    >>> Seebs 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?

    >>
    >>> No, that's a terrible way to do it.

    >>
    >>> You already have a list of foos, properly ordered for fast searching.

    >>
    >> No, I don't.

    >
    > Then I suggest you get one.
    >


    If I'm searching for all cells whose sprite size is 56 pixels (e.g.
    7x8), do I create a list of all integers in the program?
    Lie Ryan, May 12, 2010
    #15
  16. Dave Harris

    Seebs Guest

    On 2010-05-12, Daniel T. <> wrote:
    > I think part of the problem here is that I'm being painted as some sort
    > of SESE bigot and attacked from those grounds.


    Sounds like crossed wires, I guess -- I didn't think you were any such
    thing. But I may have missed the attribution on a post at some point.

    > {
    > if () {
    > /*lines of code*/
    > }
    > else {
    > /*lines of code*/
    > if () {
    > /*lines of code*/
    > return;
    > }
    > /*lines of code*/
    > if () {
    > /*lines of code*/
    > }
    > else {
    > /*lines of code*/
    > }
    > /*lines of code*/
    > }
    > if () {
    > /*lines of code*/
    > }
    > /*lines of code*/
    > }


    > There was enough code distributed in this control structure (some 50
    > lines worth) that the 'return' was completely buried (at least to my
    > eyes. Even looking at the above, I find the return hard to spot.) I
    > waisted a half-hour trying to figure out why some stuff I added to the
    > end of the function only worked intermittently.


    Yeah. I am usually wary of such things. I do actually like to do:

    int
    foo(...) {
    if (condition)
    return -1;
    if (condition)
    return -1;

    /* lines of code */

    return meaningful_value;
    }

    I feel that getting the "we won't even try to do something" cases out of
    the way early on leads to more comprehensible code later, if only because
    of the reduced indentation.

    But apart from that... I am not a big fan of "exits scattered all over the
    place". I am okay with "exits at the beginning of a clearly coherent logical
    block, in circumstances where all other processing is necessarily impossible".

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 12, 2010
    #16
  17. On 12 May, 02:02, Richard Heathfield <> wrote:
    > Daniel T. wrote:


    > > I think part of the problem here is that I'm being painted as some sort
    > > of SESE bigot and attacked from those grounds.

    >
    > I don't think you're in any danger of being called a SESE bigot as long
    > as I'm around. I'm a much easier target. :)


    I think of you as low hanging fruit
    Nick Keighley, May 12, 2010
    #17
  18. On 12 May, 03:00, pete <> wrote:
    > Richard Heathfield wrote:
    >
    > > Daniel T. wrote:
    > > <snip>

    >
    > > > I think part of the problem here is that
    > > > I'm being painted as some sort
    > > > of SESE bigot and attacked from those grounds.

    >
    > > I don't think you're in any danger of being called
    > > a SESE bigot as long
    > > as I'm around. I'm a much easier target. :)

    >
    > I find SEME to be less objectionable in functions
    > which are small enough so that you can't look at one exit
    > without noticing the all the rest of the exits.


    is there any other sort of function?

    :)
    Nick Keighley, May 12, 2010
    #18
  19. Dave Harris

    gwowen Guest

    On May 11, 6:44 pm, Seebs <> wrote:
    > On 2010-05-11, Richard Heathfield <> wrote:
    >
    > > Seebs wrote:
    > >>> You already have a list of foos, properly ordered for fast searching.
    > >> No, I don't.

    > > Then I suggest you get one.

    >
    > It's often completely unsuitable to the problem at hand.


    If your problem is not amenable to Richard H's potted solutions, the
    fault lies with your problem, not Richard's solution. You should know
    this by now.

    So if you have a disk-backed self-caching nested container storing a
    2million * 2million * 2million high resolution MRI scan image,
    scrupiously reconstructed using Radon transforms. You're searching
    for pixels of a certain shade (that indicate a possible tumor, say),
    then the first thing you should do is convert it into a one-
    dimensional in-memory sorted C-array. The fact that you won't be able
    to obtain the co-ordinates afterwards to display the appropriate slice
    to the physician is irrelevant. Sort and binary search. Any other
    solution is wrong.
    gwowen, May 12, 2010
    #19
  20. Dave Harris

    gwowen Guest

    On May 12, 2:02 pm, "Daniel T." <> wrote:

    > If you use the 3-D algorithm presented as an example in this thread to
    > do the above, your an idiot. (Remember, the algorithm aborts when it
    > finds *one* object that is the right value.)


    No, but your non-toy algorithm would resemble the original toy
    algorithm far more closer than it would resemble a toy sort-and-bisect
    search algorithm. The actual return criteria are more complex in the
    real life case, but the principal is the same. (If such a tumor
    hunting algorithm has secondary criteria based on a point and its
    neighbouring points, sorting-and-bisecting becomes even less
    useful).

    Alternatively, that behaviour might be *exactly* what you require, if
    the search algorithm is looking for *potential* bad pixels, which need
    to be shown to a consultant for expert assessment. After all, that's
    what std::find() in the C++ standard library does.

    coordinate_t find_next_potential_point(const coordinate_t& start =
    {0,0,0})
    {
    size_t x,y,z;
    for(x=start.x;x<xdim;++x){
    for(y=start.y;y<ydim;++y){
    for(z=start.x;z<zdim;++z){
    if(criteria_met(x,y,z)) return coordinate_t(x,y,z);
    }
    }
    }
    return
    somekindof_not_found_sentinel_or_throw_an_exception_or_container.end();
    }

    > (Remember, the algorithm aborts when it finds *one* object that is the right value.)


    Which *might* be exactly what is wanted. Usage varies. One size does
    not fit all.

    Also, if you're going to say "your an idiot", you'll get a better
    response if you learn the difference between "you're" and "your". Oh,
    and the difference between "return" and "abort".
    gwowen, May 12, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. youngsun park
    Replies:
    2
    Views:
    612
    David Pursley
    Nov 18, 2003
  2. Skybuck Flying

    VHDL Goto statement ?

    Skybuck Flying, Aug 8, 2005, in forum: VHDL
    Replies:
    9
    Views:
    6,090
    ajahn
    Aug 26, 2005
  3. Skybuck Flying

    Re: VHDL Goto statement ?

    Skybuck Flying, Aug 8, 2005, in forum: VHDL
    Replies:
    0
    Views:
    727
    Skybuck Flying
    Aug 8, 2005
  4. Flip
    Replies:
    6
    Views:
    6,657
    Jeff Dillon
    Nov 18, 2004
  5. Flip
    Replies:
    1
    Views:
    630
    Brock Allen
    Apr 14, 2005
Loading...

Share This Page