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

RE: [hackers-il] "Trial and Error" vs. "By the Book" programming

Expand Messages
  • Arik Baratz
    I like to think everything over, run simulations in my mind, perhaps trace an algorithm a few times on a piece of paper, and then dump it all in code-form
    Message 1 of 2 , Dec 9, 2001
      I like to think everything over, run simulations in my mind, perhaps trace
      an algorithm a few times on a piece of paper, and then dump it all in
      code-form overnight.

      It's a matter of preference.

      -- Arik

      -----Original Message-----
      From: Shlomi Fish [mailto:shlomif@...]
      Sent: Sun, December 09, 2001 1:58 PM
      To: Hackers-IL
      Subject: [hackers-il] "Trial and Error" vs. "By the Book" programming



      Nadav made an interesting point in which he contrasted those two
      viewpoints. However, my viewpoint is something in between.

      The way I see it when I have to come up with a technique or a methodology
      I:

      1. Think.

      2. After I came up with an idea, I try to "prove" that it will achieve
      what I intended it to. This is a rather informal proof in which I cover
      all the places where it may fail.

      3. I implement it.

      4. I run it and see if it performs OK.

      5. If it fails from some reason, I debug it, see where it fails. If it's a
      trivial bug, I fix it.

      6. If the bug is inherent, I think of an elegant workaround.

      So far this scheme worked wonderfully for me. I'll give you an example
      (this time not with Freecell Solver - :-)).

      During my "Structure of OS" course, my partner and I were given an
      assignment. We had to scan a directory structure for files, while
      allocating one thread for every directory, sub-directory,
      sub-sub-directory, etc. Then we had to keep a catalog of the files and
      use it to perform a substring search on the file names. (a very stupid
      strategy inherently, but that was what we were supposed to do.)

      Now, the user-interface thread could have received a command that would
      have told it to terminate the program. We wanted all the
      who-knows-how-many threads we initiated to exit prematurely (naturally),
      but we wanted the main thread to know when all of them did. What we did
      was:

      1. Signal all the threads to exit by setting a "global" (i.e: thread pool
      scoped) variable.

      2. The threads checked this flag in their main directory scanning loop.

      3. When a new thread was created it incremented a mutex-protected counter
      by 1, and when it terminated (either pre-maturely or maturely) it
      decremented it.

      4. The main thread looped on until this counter was set to zero (it too
      locked and unlocked the mutex in order to retrieve the value).

      Now, we did not learn this particular technique in the course, but it
      worked very well. Of course, if one if the threads is killed pre-maturely
      (somehow) there could be a deadlock, but I think most synchronization
      algorithms are not immune to such errors.

      I'll bet this technique or something similar is well-documented in the
      literature, but I came up by it myself. Actually, I did thought about it
      for something I wanted to implement for Freecell Solver, but have yet to
      do. But I made a working implementation of it for my class assignment.

      I love to think. And usually, I am feeling quite exhilirated when I come
      up with an interesting algorithm or mathemtical proof or technique or
      whatever. And if I eventually find out that somebody thought about it
      before me, it does not reduce my sense of achievement. I respect the "book
      worm" approach, and while I have read some technical books in my time, I
      acknowledge that it's not for me.

      Regards,

      Shlomi Fish



      ----------------------------------------------------------------------
      Shlomi Fish shlomif@...
      Home Page: http://t2.technion.ac.il/~shlomif/
      Home E-mail: shlomif@...

      If:
      1. A is A
      2. A is not not-A
      does it imply that
      1. B is B
      2. B is not not-B





      To unsubscribe from this group, send an email to:
      hackers-il-unsubscribe@egroups.com



      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.