flok wrote:Henk,
You're not serious, right?
Does it matter. If it reduces complexity it might be interesting. But looks like it does not. So read it in reverse mode or be a good interpreter.
Moderators: hgm, Dann Corbit, Harvey Williamson
flok wrote:Henk,
You're not serious, right?
Code: Select all
#define while ifI suppose one could tackle this in something like SISAL or whatever. Certainly not MY cup of tea for chess, however.mvk wrote:Encapsulating state is generally considered a key defining property of OO. It would be Value Oriented programming if there were no mutable state. Some also call that functional programming of course. There is empirical evidence that that can work in the sense that products are made with it and people make their living that way.Henk wrote:Maybe OO programming is safe if you make all objects immutable. Don't know if that works in practice.
Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...Henk wrote:Functions compose well. Free or global variables usually cause problems.
I don't know if a twenty times slower transposition table will become the main computational bottleneck during normal move search otherwise using balanced trees might become an option.bob wrote:Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...Henk wrote:Functions compose well. Free or global variables usually cause problems.
I disagree.bob wrote:Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...Henk wrote:Functions compose well. Free or global variables usually cause problems.
How is that different from global variables? The problem with globals is that any procedure can modify them even when they are not formal parameters. How is that different that passing around a pointer that points to a large structure? You have the SAME problem. You can't tell which procedure modifies what unless you look.flok wrote:I disagree.bob wrote:Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...Henk wrote:Functions compose well. Free or global variables usually cause problems.
When you initiated the pool of threads that you use, you can setup a structure with pointers and values etc of parameters that would be global instead. That structure can then be passed to the threads at creation time.
Global variables are bad mkay.
It HAS to be fast. It HAS to be hashed, not searched.Henk wrote:I don't know if a twenty times slower transposition table will become the main computational bottleneck during normal move search otherwise using balanced trees might become an option.bob wrote:Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...Henk wrote:Functions compose well. Free or global variables usually cause problems.
A lot of sw engineering is about reuse (either in time or in space). Imagine trying to provide a libcrafty. You'll have to put each instance in its own address space to create new instances of its globals. Some people call that fork.bob wrote:You are going to have to convince me how a pointer to a bunch of things is different from a global in the context of software engineering and programming.