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
one of the many infinite possible paths eliminated.
Maybe we are being too abstract here. If you have the time and
motivation, would you please tell me in a couple of sentences what your
standard(s) is upon which you can clearly distinguish right thinking
from wrong thinking? And how that standard accommodates active random
walk experimentation and creativity such that an experimenter can know
PRIOR to doing the experiment if he is headed off in a right or wrong path?
Jim
Don Dailey wrote:
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 immediately being only one, to claim any approach is futile,
inefficient or erred. Once there are approaches that actually come
near playing low dan levels against humans, I can see how narrowing
approaches and thinking will become useful. Until then, lots of
chaotic and random path experimentation is desirable, including other
languages, specialized languages, techniques, etc.
Jim
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 it
can be equivalent to one very large improvement.
This is frong thinking *for you*. Wasn't it yourself who said that people
program go for various reasons, only one of them being "making the strongest
possible program". A person with a more theoretical approach might lament
that all that speed optimizing indeed improved the play considerably, but has
not produced any new insight or theory on how best to approach the problem. A
mere amateur like me could complain about the time invested in those small
improvements, that I did not gain any new knowlege for myself, it was just
routine programming. I humbly suggest that none of us (including you :-) is
guilty of "wrong thinking".
Regards
Heikki
------------------------------------------------------------------------
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
