To the guy that gave me a cussin

[kgburcham]

If Vas can leave the Tachometer and the Odometer off of my program, then I can post a reply to a test position without the program name as long as I do not violate the charter, or the interpretation of said document.

Did Vas announce pre-release that Rybka would report a lower than normal kns? did Vas announce pre-release that Rybka would not report a % of hash fill?
If he did I missed it, so I am assuming he did not. I will admit corrected if needed.

To the guy that gave me a cussin, even though it was kind of a girlie man cussin----I curse you back with one of the following:
I hope your new pullstart lawnmower has a 12 inch rope.
I hope your new BMW only has a reverse.
I hope refrigerator parts have been installed inside your hot water heater.
I hope your new leather recliner turns out to be an "assist out" chair.
I hope every time you fire your new 40 mm Glock, the mag falls out.
I hope you get the Blue Screen of Death every time you start Windows 7 Ultimate with your new $250 copy of Rybka 4.5 on your 16 core with 16 gigs of Ram.
I hope the next time your are hanging blinds for your wife, and you are trying to impress her, you slip, the blinds fall to the floor, the window flies open, your phillips screwdriver breaks, you bruise your testicles and your wife is mad because you cant have sex for two days.

If I find out none of these worked, then I will try some others later.

Vas sent a message to all, that if you are the "seller" of the program, then you can set your own standards outside of tradition.

kgburcham

[Rolf]

If Vas can leave the Tachometer and the Odometer off of my program, then I can post a reply to a test position without the program name as long as I do not violate the charter, or the interpretation of said document.

Did Vas announce pre-release that Rybka would report a lower than normal kns? did Vas announce pre-release that Rybka would not report a % of hash fill?
If he did I missed it, so I am assuming he did not. I will admit corrected if needed.

To the guy that gave me a cussin, even though it was kind of a girlie man cussin----I curse you back with one of the following:
I hope your new pullstart lawnmower has a 12 inch rope.
I hope your new BMW only has a reverse.
I hope refrigerator parts have been installed inside your hot water heater.
I hope your new leather recliner turns out to be an "assist out" chair.
I hope every time you fire your new 40 mm Glock, the mag falls out.
I hope you get the Blue Screen of Death every time you start Windows 7 Ultimate with your new $250 copy of Rybka 4.5 on your 16 core with 16 gigs of Ram.
I hope the next time your are hanging blinds for your wife, and you are trying to impress her, you slip, the blinds fall to the floor, the window flies open, your phillips screwdriver breaks, you bruise your testicles and your wife is mad because you cant have sex for two days.

If I find out none of these worked, then I will try some others later.

Vas sent a message to all, that if you are the "seller" of the program, then you can set your own standards outside of tradition.

kgburcham

I recall that Vas explicitly stated that he didnt think that the "output" of evals had anything deeper or more relevant in itself. I am absolutely sure that I've read it either in the beginning in a forum or then in his own FAQ. You must ask the question in the reverse mode. Critics of Vas base their questions on the assumption that it were existing a sort of true number stuff every "true" program would display. So consequently they asked why Vas didnt offer the same. But IMO - dont forget that I'm a lay, but I understand this from other sciences - there is no such thing as the absolute true eval output so that one could say that someone who didnt display it would therefore cheat the user. I think it's a myth, that allegedly true output. IMO please with all respect.

[kgburcham]

I recall that Vas explicitly stated that he didnt think that the "output" of evals had anything deeper or more relevant in itself.
(Not true--a more traditional output is used by the gamer in competition to get a feel that "everything seems normal". This includes hash % and kns, of course everyone here knows that code can be written to count the hairs that fall on the keyboard, can count the current cycles through the Motherboard, can count the drops of sweat on Vas forehead when he tries to run his program on an unstable cluster, duh. Rolf everyone knows that the programmer controlled eval output as read by the buyer does not effect the strength of the program, duh).
I am absolutely sure that I've read it either in the beginning in a forum or then in his own FAQ. (no proof)
You must ask the question in the reverse mode. Critics of Vas base their questions on the assumption that it were existing a sort of true number stuff every "true" program would display. (nope not true--no one expects exact--only closer to true and then minimal variation with hardware changes)
So consequently they asked why Vas didnt offer the same.(nope not true-no one has said the same as another program)
But IMO - dont forget that I'm a lay, but I understand this from other sciences - there is no such thing as the absolute true eval output (nope not true again)
so that one could say that someone who didnt display it would therefore cheat the user. (the expected output has been modified extremely from traditional gamer expectations, this was not revealed before release, the first time I read about it was when MANSARI first posted his experiences with low node count).
I think it's a myth, that allegedly true output. IMO please with all respect.
Rolf

I find it difficult communicating with you, Rolf. Your posts do not seem to reply to the subject. Your last post is another example of the same.

It also seems each reply from you Rolf gets further from the original subject. good luck

kgburcham

[kgburcham]

Rolf I am not saying exactly like this definition.
Rolf I am not saying a true number.
Rolf I am not saying Like another program.
Rolf I did not say absolute.

Rolf I am saying the output should have been closer to the below definition, or should have been closer to a traditional count.
I dont really care about the kns as much as feeling comfortable that when I am running a program online in competition, or when I am analyzing a position, I want to know that the part of the code that tells me the kns is also telling me that everything seems to be as normal as can be expected at that moment in time.
Rolf do you know the meaning of these comments by the operator in competition?
1. Damn do you smell that? overload
2. Damn do you hear that? cooling fan
3. Damn what was that? erratic decrease in kns output
4. Damn what was that? erratic increase in kns output
5. Damn how can that be? the hash is full
6. Damn where did that porno come from? whos been using this pc.

Do you have to have Rybka kns or hash %. nope. Can I drive my car without a tach or speeometer or any of the other gauges with a traditional output, why sure no problem---but feel better with lots of gauges.

I think this is Doctor Hyatts definition, not sure.

"node" is _precisely_ defined in tree searching. Making a move leads to a new position, which is called a node. If you have a position with 20 legal moves, and you search exactly one ply (no extensions) deep.you search 20 nodes. no more, no less. One can argue about the "illegal moves" that are made, but if you "make illegal moves" then counting them is reasonable, and they represent a tiny fraction of the total nodes anyway and don't change the significance of that number.

The classic definition of a node could be stated as "a node is what you get when you make a move and update the game board to a position that is not the same as it was before you made the move." It doesn't matter whether a node has branches leading out of it or not, all that matters is if you actually follow any of those branches, and to do so you just make the move the branch (arc) represents, and that takes you to a new node...
Again, each call to MakeMove(), or as an alternative, each call to Search()/Quiesce(), is a node. If you make a move, visit a new node, and get a hash hit, that's all you count. No way to know how much work that hash hit prevented you from doing and trying to count that.

We have one program that is trying to hide things. That doesn't make it impossible for the rest of us to produce a real value for NPS that is comparable. Comparing NPS values reveals details. How long it takes to expand a node, which could be attributed to evaluation or complexities in the search brought on by pruning/etc.

(For me the more interesting subject about Rybka Node Count is not being discussed in this thread).

kgburcham

[CThinker]

Even in crafty, not all nodes are equal. Some nodes are more expensive than others. NPS for crafty is actually 'average' NPS. A cheap (quick) qsearch node is one where eval hit a 'lazy' score, and returned quickly. An expensive (slow) qsearch node is one where eval had to do every line of code in the eval function.

Crafty also does not count nodes each time it calls the MakeMove() function, even though one would claim that it is the the definition of a node. In crafty, there are more calls to the MakeMove() function than there are node counts. This is because crafty calls MakeMove() even for invalid moves. In crafty, node count is done at the start of search/qsearch.

I agree with Vas in that I think that an engine's statistics is specific to the engine. It only makes sense to that engine. As long it is possible to interpret the statistics and that they are consistent, then that I think is good enough.

I myself don't use NPS as a gauge. Instead, I run the profiler and look at its output. Then I can tell how much CPU time is spent on each function and how many times each function is called. I do that during code development. When the engine is released and in use, I no longer care what the NPS is - I already know during development time how the engine behaves. But that is just me...

[bob]

Even in crafty, not all nodes are equal. Some nodes are more expensive than others. NPS for crafty is actually 'average' NPS. A cheap (quick) qsearch node is one where eval hit a 'lazy' score, and returned quickly. An expensive (slow) qsearch node is one where eval had to do every line of code in the eval function.

Crafty also does not count nodes each time it calls the MakeMove() function, even though one would claim that it is the the definition of a node. In crafty, there are more calls to the MakeMove() function than there are node counts. This is because crafty calls MakeMove() even for invalid moves. In crafty, node count is done at the start of search/qsearch.

I agree with Vas in that I think that an engine's statistics is specific to the engine. It only makes sense to that engine. As long it is possible to interpret the statistics and that they are consistent, then that I think is good enough.

I myself don't use NPS as a gauge. Instead, I run the profiler and look at its output. Then I can tell how much CPU time is spent on each function and how many times each function is called. I do that during code development. When the engine is released and in use, I no longer care what the NPS is - I already know during development time how the engine behaves. But that is just me...

The issue is nodes however. And whether you count illegal moves or not is not a very big deal. There's a huge difference between whether you choose to count nodes as legal moves only, or as every move you make/unmake, as opposed to making up numbers that are absolutely meaningless intentionally...

The first two cases will be very close overall... if you make up numbers nobody has a clue about what the search is doing...

[AdminX]

If Vas can leave the Tachometer and the Odometer off of my program, then I can post a reply to a test position without the program name as long as I do not violate the charter, or the interpretation of said document.

kgburcham

ROTFLMAO,

I was wondering why you did that!

[CThinker]

Even in crafty, not all nodes are equal. Some nodes are more expensive than others. NPS for crafty is actually 'average' NPS. A cheap (quick) qsearch node is one where eval hit a 'lazy' score, and returned quickly. An expensive (slow) qsearch node is one where eval had to do every line of code in the eval function.

Crafty also does not count nodes each time it calls the MakeMove() function, even though one would claim that it is the the definition of a node. In crafty, there are more calls to the MakeMove() function than there are node counts. This is because crafty calls MakeMove() even for invalid moves. In crafty, node count is done at the start of search/qsearch.

I agree with Vas in that I think that an engine's statistics is specific to the engine. It only makes sense to that engine. As long it is possible to interpret the statistics and that they are consistent, then that I think is good enough.

I myself don't use NPS as a gauge. Instead, I run the profiler and look at its output. Then I can tell how much CPU time is spent on each function and how many times each function is called. I do that during code development. When the engine is released and in use, I no longer care what the NPS is - I already know during development time how the engine behaves. But that is just me...

The issue is nodes however. And whether you count illegal moves or not is not a very big deal. There's a huge difference between whether you choose to count nodes as legal moves only, or as every move you make/unmake, as opposed to making up numbers that are absolutely meaningless intentionally...

The first two cases will be very close overall... if you make up numbers nobody has a clue about what the search is doing...

I think users don't have to know what the search is doing. Whatever it is doing is specific to that engine. I don't see the value in having to expose the details of engine implementation to end users.

I am also not convinced that Vas is just making up numbers. I believe that whatever it is that he is counting is not the same as what others would call nodes. And I think that is what Vas is guilty of - a mistake in terminology. Instead of calling his nodes, "nodes", he should call it "Rybka nodes".

I have here an example on the other direction. Let's say that everyone agrees that a node count is defined as a call to MakeMove(). Now, I implement an engine this way:
1. Increment node count at the start of MakeMove().
2. Always generate 'all' moves in Search (like Rebel does, to have better move ordering).
3. Always use SEE to order all moves (even non-captures, to determine if a piece in a non-capture piece is being given away for free; again, as hinted by Ed in Rebel).
4. Use MakeMove()/UnmakeMove in SEE to do the capture sequence. This avoids the problem with pinned pieces that plague traditional SEE.

For that engine, the node count will be outrageously large. People would complain that I am making up the numbers.

The really big numbers still make sense to me as the developer. I know what the engine is doing.

As for Vas and Rybka, my guess is that the counter is at the start of Search(), and there is no counter in QSearch() or anywhere else. In Thinker, the ratio between calls to Search() and calls to QSearch() is something like 1:200. This looks more like the kind of low numbers that Rybka displays.

So, again, I don't think there is intentional misleading here. Just a difference is terminology and what is being counted.

[Dann Corbit]

Even in crafty, not all nodes are equal. Some nodes are more expensive than others. NPS for crafty is actually 'average' NPS. A cheap (quick) qsearch node is one where eval hit a 'lazy' score, and returned quickly. An expensive (slow) qsearch node is one where eval had to do every line of code in the eval function.

Crafty also does not count nodes each time it calls the MakeMove() function, even though one would claim that it is the the definition of a node. In crafty, there are more calls to the MakeMove() function than there are node counts. This is because crafty calls MakeMove() even for invalid moves. In crafty, node count is done at the start of search/qsearch.

I agree with Vas in that I think that an engine's statistics is specific to the engine. It only makes sense to that engine. As long it is possible to interpret the statistics and that they are consistent, then that I think is good enough.

I myself don't use NPS as a gauge. Instead, I run the profiler and look at its output. Then I can tell how much CPU time is spent on each function and how many times each function is called. I do that during code development. When the engine is released and in use, I no longer care what the NPS is - I already know during development time how the engine behaves. But that is just me...

The issue is nodes however. And whether you count illegal moves or not is not a very big deal. There's a huge difference between whether you choose to count nodes as legal moves only, or as every move you make/unmake, as opposed to making up numbers that are absolutely meaningless intentionally...

The first two cases will be very close overall... if you make up numbers nobody has a clue about what the search is doing...

I think users don't have to know what the search is doing. Whatever it is doing is specific to that engine. I don't see the value in having to expose the details of engine implementation to end users.

I am also not convinced that Vas is just making up numbers. I believe that whatever it is that he is counting is not the same as what others would call nodes. And I think that is what Vas is guilty of - a mistake in terminology. Instead of calling his nodes, "nodes", he should call it "Rybka nodes".

I have here an example on the other direction. Let's say that everyone agrees that a node count is defined as a call to MakeMove(). Now, I implement an engine this way:
1. Increment node count at the start of MakeMove().
2. Always generate 'all' moves in Search (like Rebel does, to have better move ordering).
3. Always use SEE to order all moves (even non-captures, to determine if a piece in a non-capture piece is being given away for free; again, as hinted by Ed in Rebel).
4. Use MakeMove()/UnmakeMove in SEE to do the capture sequence. This avoids the problem with pinned pieces that plague traditional SEE.

For that engine, the node count will be outrageously large. People would complain that I am making up the numbers.

The really big numbers still make sense to me as the developer. I know what the engine is doing.

As for Vas and Rybka, my guess is that the counter is at the start of Search(), and there is no counter in QSearch() or anywhere else. In Thinker, the ratio between calls to Search() and calls to QSearch() is something like 1:200. This looks more like the kind of low numbers that Rybka displays.

So, again, I don't think there is intentional misleading here. Just a difference is terminology and what is being counted.

Junior counts nodes differently. For instance, single reply extensions are not counted as a full node.

I think that if there were a clear definition of what a node is, then a node count would be meaningful.

Do we want to say that every entrance into alpha-beta is a node? If it is, what happens when we circumvent the search with a hash lookup. Is it a node or not?

If a search circumvents quiesce() is it still a node?

We could also count eval() calls, but eval() can also be hashed.

One program does a full minimax, has no hash table of any kind, and so it produces a node number we can understand.

Another program has all sorts of reductions like alpha-beta, null move, lmr, etc, and does not consider single reply extensions as nodes.

If we compare the numbers from these two programs what will we learn?
If we do not know the kind of reductions that are going on inside of a program, I submit that node counts are almost completely meaningless.

[bob]

Even in crafty, not all nodes are equal. Some nodes are more expensive than others. NPS for crafty is actually 'average' NPS. A cheap (quick) qsearch node is one where eval hit a 'lazy' score, and returned quickly. An expensive (slow) qsearch node is one where eval had to do every line of code in the eval function.

Crafty also does not count nodes each time it calls the MakeMove() function, even though one would claim that it is the the definition of a node. In crafty, there are more calls to the MakeMove() function than there are node counts. This is because crafty calls MakeMove() even for invalid moves. In crafty, node count is done at the start of search/qsearch.

I agree with Vas in that I think that an engine's statistics is specific to the engine. It only makes sense to that engine. As long it is possible to interpret the statistics and that they are consistent, then that I think is good enough.

I myself don't use NPS as a gauge. Instead, I run the profiler and look at its output. Then I can tell how much CPU time is spent on each function and how many times each function is called. I do that during code development. When the engine is released and in use, I no longer care what the NPS is - I already know during development time how the engine behaves. But that is just me...

The issue is nodes however. And whether you count illegal moves or not is not a very big deal. There's a huge difference between whether you choose to count nodes as legal moves only, or as every move you make/unmake, as opposed to making up numbers that are absolutely meaningless intentionally...

The first two cases will be very close overall... if you make up numbers nobody has a clue about what the search is doing...

I think users don't have to know what the search is doing. Whatever it is doing is specific to that engine. I don't see the value in having to expose the details of engine implementation to end users.

I am also not convinced that Vas is just making up numbers. I believe that whatever it is that he is counting is not the same as what others would call nodes. And I think that is what Vas is guilty of - a mistake in terminology. Instead of calling his nodes, "nodes", he should call it "Rybka nodes".

Unfortunately, data doesn't support you. What kind of a node could cause the counter to go "backward"??? A node is a node. It is a term that is defined in any AI / Computer Science textbook. There is a little bit of room for variance, such as do you count legal moves or all moves. But that is not significant over the course of a normal search. One can not suddenly use the term "miles per hour" and define it in another way to mean something like "revolutions per minute" or "pounds per hour". An "accepted term" (which node clearly is) should be used according to "accepted usage". And Vas clearly did not do that... Ditto for depth. And we know this because some hacked the code and found the fakery and fixed it...

I have here an example on the other direction. Let's say that everyone agrees that a node count is defined as a call to MakeMove(). Now, I implement an engine this way:
1. Increment node count at the start of MakeMove().
2. Always generate 'all' moves in Search (like Rebel does, to have better move ordering).
3. Always use SEE to order all moves (even non-captures, to determine if a piece in a non-capture piece is being given away for free; again, as hinted by Ed in Rebel).
4. Use MakeMove()/UnmakeMove in SEE to do the capture sequence. This avoids the problem with pinned pieces that plague traditional SEE.

For that engine, the node count will be outrageously large. People would complain that I am making up the numbers.

It wouldn't be that large when translated to NPS. Make/Unmake are not free. That's why we don't use them in swap(). I'd bet your numbers would be in the ballpark with others. Your search depth would certainly fall off.

And that is not the usual definition of "node". "node" is a point on a graph where you can follow an arc to another point. That's why most of us count recursive calls to search/quiesce since each time either gets control, they are at a node where we are prepared to expand the node and follow the successors to new nodes (or not for terminal nodes).

The really big numbers still make sense to me as the developer. I know what the engine is doing.

As for Vas and Rybka, my guess is that the counter is at the start of Search(), and there is no counter in QSearch() or anywhere else. In Thinker, the ratio between calls to Search() and calls to QSearch() is something like 1:200. This looks more like the kind of low numbers that Rybka displays.

So, again, I don't think there is intentional misleading here. Just a difference is terminology and what is being counted.

All I can say is "dream on". Someone found where the node count was divided by something and removed the divide, and the numbers started to look better. Ditto for fudging the depth...