Loading ...
Sorry, an error occurred while loading the content.

[XP] Re: New Article: More Hassling with Haskell

Expand Messages
  • igouy2
    ... wrote: -snip- ... Let s agree the defect is due to an incorrect termination condition. What puzzles me is that you keep saying it matters
    Message 1 of 33 , Nov 5, 2006
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      <ronjeffries@...> wrote:
      -snip-
      > > afaict the fact that the program used recursion is incidental, I
      > > imagine we can have the same error using a for loop - the mistake was
      > > a mistake in understanding the problem.
      >
      > Hardly. I fancy I understand Bowling scoring rather well now, having
      > programmed it so many times. And I'd like to see you code up that
      > same error with a for loop, since the defect is due, precisely, to
      > an erroneous recursion termination condition which must be hard to
      > spot, since so many keen eyes, including our own, didn't spot it.

      Let's agree the defect is due to an incorrect termination condition.

      What puzzles me is that you keep saying it matters that we are
      terminating a recursion rather than an iteration - it does not.

      What matters is that we take account of the difference in scoring
      rules between the 10th and previous frames, and for that we need a
      frame count of some kind.

      This program uses iteration (I even used a for loop just in case you
      were feeling pernickety) and has the same error as those recursive
      programs.


      int score(int[] pins){
      var total = 0;
      var i = 0;

      for (var j = 0; j<pins.length; j++){

      if (i+3==pins.length) {
      total += pins[i] + pins[i+1] + pins[i+2];
      i += 2;
      }
      else if (i+2<pins.length && pins[i] == 10) {
      total += pins[i] + pins[i+1] + pins[i+2];
      i ++;
      }
      else if (i+2<pins.length && pins[i]+pins[i+1] == 10) {
      total += pins[i] + pins[i+1] + pins[i+2];
      i += 2;
      }
      else if (i+1<pins.length) {
      total += pins[i] + pins[i+1];
      i += 2;
      }
      }
      return total;
      }

      void main(String[] args){
      let int[][] tests = [
      [0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
      [3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3],
      [4,6, 3,5, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
      [4,6, 5,3, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
      [10, 5,3, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
      [0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10, 5,3],
      [0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 4,6, 5],
      [10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10],
      [10, 4,6, 10, 4,6, 10, 4,6, 10, 4,6, 10, 4,6, 10],
      [0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10, 2,3],
      [0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10, 2,3]
      ];

      for(each:tests) println( score(each) );
      }



      >nicec --sourcepath .. -a t.jar tenpin
      nice.lang: parsing
      tenpin: parsing
      tenpin: typechecking
      tenpin: generating code
      tenpin: linking
      tenpin: writing in archive
      nice.lang: writing in archive

      >java -jar t.jar
      0
      60
      21
      23
      26
      18
      15
      300
      200
      15
      15
    • Buddha Buck
      ... I m reading it via gmail, and I just decided to go back and look at your message via show original message , which shows the message without any
      Message 33 of 33 , Nov 20, 2006
      • 0 Attachment
        On 11/20/06, Donald Roby <droby@...> wrote:
        >
        > Buddha Buck wrote:
        > >
        > > For what it's worth, it looks OK to me (i.e., it doesn't look weirdly
        > > misformatted), but I don't do that much Haskell, so I might be missing
        > > something. The only unusual formatting I saw was one line looked as if
        > it
        > > had been word-wrapped. It certainly didn't look like I would expect
        > > code-interpreted-as-HTML would have looked. If course, as a
        > traditionalist,
        > > I get this list from yagoogroups in "text email", not "HTML email". That
        > > might have something to do with it.
        > >
        >
        > This one wasn't as bad as the previous one, basically because there was
        > less line wrap due to less long lines. But at least as viewed through
        > Thunderbird and via the group web interface, it pretty much removed
        > indentation. And indentation is sometimes important in Haskell ... even
        > more in Python. Maybe as you're reading with a text-based system, the
        > indentation was intact.


        I'm reading it via gmail, and I just decided to go back and look at your
        message via "show original message", which shows the message without any
        formatting.

        When the original message is viewed, in the "code" section (which I saw as
        raw tags, not as formatted stuff), I can see that everything except the
        first "module Bowling where" line is indented (at least) two spaced. In the
        formatted version, that is basically invisible, but I think that has more to
        do with gmail defaulting to a proportional font so consecutive spaces are
        nearly invisible.

        The rest of the indenting looks odd to me, but that may be due to Haskell
        formatting conventions than anything. The definition of framescores(x:xs)
        has the "=" on the second line under the xs. And the definition of
        bonus(x:xs) has the "then" and "else" clauses lined up with the "10" in the
        conditional. No other statement or definition is written across two lines
        (I'm considering framescores([]) and framescores(x:xs) to be two
        defintions).


        > Thought of that after I saw the effect. I use "tags" in email
        > frequently, but don't actually expect them to affect the display.


        I don't think it did on my end.

        If the server allows through arbitrary markup and lets it remain as
        > markup, it's subject to lots of abuse, so even though it would help in
        > this instance, I hope they don't do that.


        The server *should* allow it through. How the message is formatted should
        ultimately be a result of my mailreader, not what an intermediary chooses to
        do with it. Part of my "traditionalist" leanings is that I don't want
        yahoogroups (or Google, for that matter) making arbitrary changes to my
        email as it goes through.


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.