Hi Jim,
There is no black and white when it comes to right or wrong
thinking. Each of us is guilty of it. You get an idea, try it out,
test it thoroughly and find that it isn't useful.
There is nothing wrong with this process itself - I view it as a
device that trains your intuition. The
However, perhaps there are ways to make testing a Go program use less clock
time?
This is the right idea.
Chess programmers use massive automated testing - playing games. To
measure a small ELO improvement in your program requires tens of
thousands of games.I think it's something
On Sun, Nov 25, 2007 at 11:52:14AM -0500, Don Dailey wrote:
I know that most go programmers don't concern themselves with small
improvements because of the sense that there is bigger fish to fry.
But this is wrong thinking. If you can get 10 small improvements it
can be equivalent to one
Heikki,
I'm with you. There is no wrong thinking at the present time. There
are too many differing agendas, with building the strongest program
immediately being only one, to claim any approach is futile, inefficient
or erred. Once there are approaches that actually come near playing low
Heikki Levanto wrote:
On Sun, Nov 25, 2007 at 11:52:14AM -0500, Don Dailey wrote:
I know that most go programmers don't concern themselves with small
improvements because of the sense that there is bigger fish to fry.
But this is wrong thinking. If you can get 10 small improvements
Jim O'Flaherty, Jr. wrote:
Heikki,
I'm with you. There is no wrong thinking at the present time.
Of course there is wrong thinking. Why do you think they call it the
trial and error approach?
- Don
There are too many differing agendas, with building the strongest
program
Don,
I think we have a semantic problem. Some things don't work as expected
but provide the genesis for further creativity. Other things work, but
not with sufficient additional value for the disproportionate effort
invested. Some things don't end up having any enduring value except as
Thought I'd emphasize this point:
Don Dailey:
I spend a great deal of time waiting on the computer, because I have no clue
what will work and I must test it.
This makes Go programming somewhat unusual; for a lot of programs, you
can arrange so that compiling and running your tests only takes
