Author: Dan Honeycutt
Date: 13:42:10 11/22/04
Go up one level in this thread
On November 22, 2004 at 15:30:46, Anthony Cozzie wrote: >On November 22, 2004 at 11:59:22, Dan Honeycutt wrote: > >>I hear both sides. When I started grad school in 1972 I gained access to a >>teletype machine hooked into the campus mainframe. You could enter a program in >>BASIC, type run, and get instant answers. No more card decks and waiting >>several hours wondering if your program was going to crash. The teletype >>machine even had a paper tape that allowed you to save and reload your program. >>Not a lot faster than typing it in from scratch, but less error prone. >> >>With such awesome computing facilities at my disposal I decided it would be fun >>to write a chess program. With no forethought whatsoever I began: >> >>10 DIMENSION B(8, 8) >> >>"There, I've got a board". Needless to say, I didn't go far before I realized >>that some planning and design would be necessary if the program was ever going >>to actually play. I put the program aside and worked out an outline for what >>various parts should do. When I returned to the program I was forced to throw >>away a fair amount of code. >> >>Over the years I've developed my "style". I do a little planning - what the >>program should look like at the top - and I begin coding the pieces at the >>bottom. The plan grows down and the code grows up. If I plan too much I end up >>throwing away plans as unexpected things surface as I code. If I code too much >>I end up throwing away code for lack of a plan. I don't claim what I do is >>best, but I'm comfortable with it and I know it works for me. Plus I'm too old >>to change. >> >>It sounds like Daniel is proceeding in the manner that suits his style. His >>style may also not be the best, but I believe it will work and he will succeed. >>I think he deserves a little more encouragement and a little less "that's a >>recipe for disaster". >> >>Good luck to you Daniel. >> >>Dan H. > >IMHO, > >The reason I think it is important to think a bit about parallel search is that >you can go through designs faster. I discarded AT LEAST five designs on paper >after I realized they wouldn't work/would be slow/etc. The point is that it >took me 2-3 days of thinking about each design and realizing it would suck, >rather than 2-3 months of implementing it, and then realizing that is sucked. >However, I also was designing for a very different problem: N (well, reasonably >small N) completely disassociated CPUs vs 2 tightly bound CPUs. Zappa contains >a complete implementation of DTS (and _almost_ debugged for >2 CPUs :). > >Daniel is of course free to proceed in any matter he likes. I'll give him >whatever advice he wants (although I won't tell him how my search works :), even >if he doesn't take all of it. I'm not God; I don't have all the answers. I >genuinely hope things work out for him; I'm not trying to hold him or anyone >else back by raving about how difficult things are or cracking the whip to keep >him drawing on paper for two months. > >anthony That's fair. I suspect Daniel and I are rather alike in our approach to programming; as are you and Bob. No disagreeent that any and all advice from those who have experience is good. It just seemed like the thread had gone more from advice to "what you're doing doesn't have a snowball's chance". I didn't agree with that. Plus it was 2 against 1 so I hopped in to even the odds. Dan H.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.