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

[XP] Re: New Article: Haskell Bowling

Expand Messages
  • igouy2
    ... I m afraid I haven t read his program or your program. I knew that you d already seen the pattern-matching bowling game programs I wrote in Clean - so I
    Message 1 of 23 , Nov 4, 2006
      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      <ronjeffries@...> wrote:
      >
      > Hello, Isaac. On Saturday, November 4, 2006, at 9:13:38 PM, you
      > wrote:
      >
      > > I seem to remember learning about recursive functions 30 years ago, in
      > > the second week of a Pascal programming course, so it's a little
      > > puzzling to me that a software developer would say "Recursive methods
      > > tend to be confusing, in my opinion."
      >
      > Isaac, I feel sure that had you noticed the fatal defect in Dan's
      > original Haskell, and the Ruby and Java programs based on it, you'd
      > have gleefully reported it here. Yet, with your 30 years of
      > experience in recursion, you did not. Recursive algorithms do not
      > give up their secrets easily.
      >

      I'm afraid I haven't read his program or your program. I knew that
      you'd already seen the pattern-matching bowling game programs I wrote
      in Clean - so I chose to gleefully remind you of those working programs.

      > I wrote my first recursions in the early sixties, wrote a Master's
      > thesis on the topic, and have written recursive algorithms in a
      > dozen or more languages.
      >
      > And yes, I say that they tend to be confusing.

      Good for you!

      I always find proving loop-termination conditions rather gnarly but no
      one says iterative algorithms are confusing just because they mess up
      the termination condition.
    • Anthony Williams
      ... There s a large stretch of water commonly called the Atlantic Ocean between here and there. ;-) ... No, not as a rule. This question has helped me pin
      Message 2 of 23 , Nov 5, 2006
        Ron Jeffries <ronjeffries@...> writes:

        > I do like your version better, why weren't you here pairing with me?

        There's a large stretch of water commonly called "the Atlantic Ocean" between
        here and there. ;-)

        > Would you, as a rule, have all your member variables invariant over
        > the lifetime of your objects? I've seen people argue in favor of
        > that, but state changes need to live somewhere, and on the call
        > stack isn't always my favorite place.

        No, not as a rule. This question has helped me pin down what I didn't like:
        the mix of returning values and performing side effects. "score" should be a
        pure function, returning the score, yet your version passes parameters to
        itself for the recursive call by means of a side-effect: modifying the rolls
        data member. I suspect that this is a characteristic of Temporary Field.

        Incidentally, it bugs me that I missed the flaw. I was focusing on the
        structure of the code and how it reflected the Haskell, but that's not really
        an excuse; I've written code to score bowling enough times (though surely
        fewer than your good self) that I should have seen it.

        When I showed her your follow-up article, my wife chastised me for posting
        untested code: "I thought you always wrote tests first!".

        Anthony
        --
        Anthony Williams
        Software Developer
        Just Software Solutions Ltd
        http://www.justsoftwaresolutions.co.uk
      • Ron Jeffries
        Hello, Anthony. On Sunday, November 5, 2006, at 7:20:26 PM, you ... Yes, it does pass the parms using a member variable, and that s certainly questionable. In
        Message 3 of 23 , Nov 5, 2006
          Hello, Anthony. On Sunday, November 5, 2006, at 7:20:26 PM, you
          wrote:

          >> Would you, as a rule, have all your member variables invariant over
          >> the lifetime of your objects? I've seen people argue in favor of
          >> that, but state changes need to live somewhere, and on the call
          >> stack isn't always my favorite place.

          > No, not as a rule. This question has helped me pin down what I didn't like:
          > the mix of returning values and performing side effects. "score" should be a
          > pure function, returning the score, yet your version passes parameters to
          > itself for the recursive call by means of a side-effect: modifying the rolls
          > data member. I suspect that this is a characteristic of Temporary Field.

          Yes, it does pass the parms using a member variable, and that's
          certainly questionable. In the latest article, just posted, I went
          back to passing the parms all over the map. Every single method in
          the class wants to look at the current rolls! I understand the
          debate but it seems to me that when all the methods want the same
          value, a member variable might be a decent approach.

          > Incidentally, it bugs me that I missed the flaw. I was focusing on the
          > structure of the code and how it reflected the Haskell, but that's not really
          > an excuse; I've written code to score bowling enough times (though surely
          > fewer than your good self) that I should have seen it.

          Well, I have this unpopular theory that untangling recursions is
          harder than untangling iterations. Dan Mead has communicated via
          email that he has a version that passes a couple of zeros as end
          markers, and that that fixes the bug. I find that I can't reason
          effectively about whether that would work, or not.

          Could be a personal problem, of course ...

          > When I showed her your follow-up article, my wife chastised me for posting
          > untested code: "I thought you always wrote tests first!".

          Well, you had some excuse about not having a Java compiler with you
          at the time ... ;->

          Ron Jeffries
          www.XProgramming.com
          Fatalism is born of the fear of failure, for we all believe that we carry
          success in our own hands, and we suspect that our hands are weak. -- Conrad
        • Anthony Williams
          ... I agree that it ought to be a member. I just happen to think that a final member of a method object is more appropriate in this case. YMMV. ... Just
          Message 4 of 23 , Nov 5, 2006
            Ron Jeffries <ronjeffries@...> writes:

            > Hello, Anthony. On Sunday, November 5, 2006, at 7:20:26 PM, you
            > wrote:
            >
            >>> Would you, as a rule, have all your member variables invariant over
            >>> the lifetime of your objects? I've seen people argue in favor of
            >>> that, but state changes need to live somewhere, and on the call
            >>> stack isn't always my favorite place.
            >
            >> No, not as a rule. This question has helped me pin down what I didn't like:
            >> the mix of returning values and performing side effects. "score" should be a
            >> pure function, returning the score, yet your version passes parameters to
            >> itself for the recursive call by means of a side-effect: modifying the rolls
            >> data member. I suspect that this is a characteristic of Temporary Field.
            >
            > Yes, it does pass the parms using a member variable, and that's
            > certainly questionable. In the latest article, just posted, I went
            > back to passing the parms all over the map. Every single method in
            > the class wants to look at the current rolls! I understand the
            > debate but it seems to me that when all the methods want the same
            > value, a member variable might be a decent approach.

            I agree that it ought to be a member. I just happen to think that a "final"
            member of a method object is more appropriate in this case. YMMV.

            >> Incidentally, it bugs me that I missed the flaw. I was focusing on the
            >> structure of the code and how it reflected the Haskell, but that's not really
            >> an excuse; I've written code to score bowling enough times (though surely
            >> fewer than your good self) that I should have seen it.
            >
            > Well, I have this unpopular theory that untangling recursions is
            > harder than untangling iterations. Dan Mead has communicated via
            > email that he has a version that passes a couple of zeros as end
            > markers, and that that fixes the bug. I find that I can't reason
            > effectively about whether that would work, or not.

            Just adding an empty frame would certainly not work, as it would cause a
            tenth-frame strike to have the bonus rolls scored as a new frame, since there
            would now be 5 rolls left rather than 3. I thought for a second that you could
            just have them always there, and zero if not used, this would cause
            tenth-frame spares to be scored wrong, as there would be four rolls
            remaining. Changing the termination to be 4 rolls left rather than 3 would
            break games with both 9th and 10th frames being strikes.

            Bowling is such that you cannot work out the frames going backwards, so you
            need the framecount to know whether the 3 rolls left are 9th+10th, or
            10th+bonus. The problem with the recursive solutions is not that their
            recursive, but that they try and get away from that fact.

            BTW, in your final version in "Recurring Drama", I think "remainingFrames" is
            a better name than "frameNumber", since frame numbers tend to increase from 1
            to 10, not decrease from 10 to 1.

            Anthony
            --
            Anthony Williams
            Software Developer
            Just Software Solutions Ltd
            http://www.justsoftwaresolutions.co.uk
          • Ron Jeffries
            Hello, Anthony. On Sunday, November 5, 2006, at 8:52:06 PM, you ... I share your intuition. Dan claims that it will work. So far I don t know whether it
            Message 5 of 23 , Nov 5, 2006
              Hello, Anthony. On Sunday, November 5, 2006, at 8:52:06 PM, you
              wrote:

              >> Well, I have this unpopular theory that untangling recursions is
              >> harder than untangling iterations. Dan Mead has communicated via
              >> email that he has a version that passes a couple of zeros as end
              >> markers, and that that fixes the bug. I find that I can't reason
              >> effectively about whether that would work, or not.

              > Just adding an empty frame would certainly not work, as it would cause a
              > tenth-frame strike to have the bonus rolls scored as a new frame, since there
              > would now be 5 rolls left rather than 3. I thought for a second that you could
              > just have them always there, and zero if not used, this would cause
              > tenth-frame spares to be scored wrong, as there would be four rolls
              > remaining. Changing the termination to be 4 rolls left rather than 3 would
              > break games with both 9th and 10th frames being strikes.

              I share your intuition. Dan claims that it will work. So far I don't
              know whether it actually does run all the tests, and I certainly
              don't see why it WOULD work. But I also don't know just what his
              code is going to look like.

              > Bowling is such that you cannot work out the frames going backwards, so you
              > need the framecount to know whether the 3 rolls left are 9th+10th, or
              > 10th+bonus. The problem with the recursive solutions is not that their
              > recursive, but that they try and get away from that fact.

              Interesting points!!

              > BTW, in your final version in "Recurring Drama", I think "remainingFrames" is
              > a better name than "frameNumber", since frame numbers tend to increase from 1
              > to 10, not decrease from 10 to 1.

              You're right.

              Ron Jeffries
              www.XProgramming.com
              Baka ni tsukeru kusuri wa nai. -- Japanese Proverb
            • Pit Capitain
              ... programs. Isaac, you might not have read the programs Ron mentioned, but you certainly have read your own programs. This one
              Message 6 of 23 , Nov 6, 2006
                --- In extremeprogramming@yahoogroups.com, "igouy2" <igouy2@...> wrote:
                >
                > --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                > <ronjeffries@> wrote:
                > > Isaac, I feel sure that had you noticed the fatal defect in Dan's
                > > original Haskell, and the Ruby and Java programs based on it, you'd
                > > have gleefully reported it here. Yet, with your 30 years of
                > > experience in recursion, you did not. Recursive algorithms do not
                > > give up their secrets easily.
                >
                > I'm afraid I haven't read his program or your program. I knew that
                > you'd already seen the pattern-matching bowling game programs I wrote
                > in Clean - so I chose to gleefully remind you of those working
                programs.

                Isaac, you might not have read the programs Ron mentioned, but you
                certainly have read your own programs. This one

                http://groups.google.com/group/comp.object/msg/b8dfcb9fcaa45b4e

                is indeed working, because it uses a frame counter, but this one

                http://groups.google.com/group/comp.object/msg/f37aea0bf095cc72

                isn't. It does have the defect...

                In the newsgroup thread from January 2005, I didn't find any note
                about the defect, so I assume you thought both programs would be working.

                This supports Ron's point, doesn't it?

                Regards,
                Pit
              • igouy2
                ... working. ... LOL! No it doesn t support Ron s point. (Assuming we understand Ron s point to be that this error has something to do with the solution
                Message 7 of 23 , Nov 6, 2006
                  > Isaac, you might not have read the programs Ron mentioned, but you
                  > certainly have read your own programs. This one
                  >
                  > http://groups.google.com/group/comp.object/msg/b8dfcb9fcaa45b4e
                  >
                  > is indeed working, because it uses a frame counter, but this one
                  >
                  > http://groups.google.com/group/comp.object/msg/f37aea0bf095cc72
                  >
                  > isn't. It does have the defect...
                  >
                  > In the newsgroup thread from January 2005, I didn't find any note
                  > about the defect, so I assume you thought both programs would be
                  working.
                  >
                  > This supports Ron's point, doesn't it?
                  >
                  > Regards,
                  > Pit
                  >

                  LOL!

                  No it doesn't support Ron's point. (Assuming we understand "Ron's
                  point" to be that this error has something to do with the solution
                  being recursive rather than iterative.)

                  It just demonstrates that I'm capable of breaking something I wrote a
                  year earlier.
                  http://groups.google.com/group/comp.object/msg/45ed159928b69648


                  Questions for code archaeologists
                  - is the fact that the Nov 2003 (shown again in Jan 2005) program
                  works correctly just a happy accident that followed from the chance
                  use of framecount in a termination condition?
                  - is the fact that the Nov 2003 iterative program works correctly just
                  a happy accident that followed from the chance use of framecount in a
                  termination condition?
                  - was the problem understood in Nov 2003 and misunderstood in Jan 2005
                  when the second incorrect solution was created?
                  - was there ever a test case for this error? (If not we should suspect
                  that the problem hadn't been recognised.)

                  There are obvious lessons here and they run counter to Ron's statement
                  "I fancy I understand Bowling scoring rather well now, having
                  programmed it so many times."

                  The fact that we understood a problem well the last time we programmed
                  it doesn't mean that we are still mindful of the problem details in
                  the way we were then.
                  The fact that our program was correct the last time doesn't mean we
                  understood the problem then.
                • igouy2
                  ... -snip- ... I ve looked at the various Bowling Game programs I wrote back in 2003, and I ve looked through those old discussion group postings. 1) afaict I
                  Message 8 of 23 , Nov 8, 2006
                    --- In extremeprogramming@yahoogroups.com, "igouy2" <igouy2@...> wrote:

                    -snip-
                    > Questions for code archaeologists

                    I've looked at the various Bowling Game programs I wrote back in 2003,
                    and I've looked through those old discussion group postings.


                    1) afaict I never used these explicit test cases to check any of the
                    bowling game programs I wrote
                    [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]


                    2) Back in 2003 I did seem to understand that "To calculate the total
                    score for a game, we need to know if we've reached the tenth frame."

                    http://groups.google.com/group/comp.object/msg/d365e30e4e1e56de

                    However it's not obvious that I understood all the ways that programs
                    might fail if they didn't distinguish between the tenth and previous
                    frames - which leaves a question mark over how well I understood the
                    problem ;-)


                    3) It seems safe to say that the understanding was implicit, and
                    not remembered a year later - in a way that would not have been likely
                    if we had those explicit test cases.
                  Your message has been successfully submitted and would be delivered to recipients shortly.