Gian-Carlo Pascutto wrote:
except there is _no_ usable representation of the board that does
that.

...that you know of

It's a bit better than that.

You _must_ know which squares are empty. Or else you have to compute
'em based on what squares are not. Not efficient.

0x88 is an example. I prefer bitmaps over that for many reasons.

--
GCP



--
Robert Hyatt Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170

"Gian-Carlo Pascutto" schrieb im Newsbeitrag
...
However, when thinking about check testing before, I discarded the idea
of
doing it "incrementally",
as it seemed too complicated and also not very fast (I though, there
were
too many cases
of ranks/files/diagonals getting opened or closed, "rays" getting cut
and
so
on).

You only need to look at rays that can actually bear on your king.

If you find a certain case too difficult to deal with, just call
the old incheck routine at that point. As long as the majority of
cases is handled the quick way, you'll be fine.

--
GCP



I thought about it and it really looks that there is a possibility to get
faster code by enumerating all cases of an opponents move to check
the own king, mainly by looking at the last piece moving. It _must_ be
directly or indirectly responsible for a check (if there is one).
In my way of doing it, however, I want to know, if a move by a side
means that _after_ that move the king is (still) in check. This seems
more complicated and has also to take into account, if the king was
already checked _before_ the move.

BTW, I looked at Gerbil, and the approach there is like mine.
It does _not_ take the last move into account, but uses tables and
ray information for all pieces on the board.

-delphi-

[...]

My q-search is very simple, as I didn't find a good way to reduce the
number
of nodes searched there.
I consider only some captures there, so as in the other search part
InCheck
is called in MakeMove
and of course again in the leaf nodes. Did you mean that by avoiding the
in-check testing?

In the q-search I _never_ do an "in check" test. If you use the same
MakeMove() in the normal and quiescence searches, then it sounds like
you do in-check everywhere..

Well, I do, so this might be one reason for bad performance.
So is in your q-search approach illegality handled but special
scores for king captures?

-delphi-

[...]





--
Robert Hyatt Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170

"Gian-Carlo Pascutto" schrieb im Newsbeitrag
news
"Delphi" wrote in message
...
I thought about it and it really looks that there is a possibility to
get
faster code by enumerating all cases of an opponents move to check
the own king, mainly by looking at the last piece moving. It _must_ be
directly or indirectly responsible for a check (if there is one).
In my way of doing it, however, I want to know, if a move by a side
means that _after_ that move the king is (still) in check. This seems
more complicated and has also to take into account, if the king was
already checked _before_ the move.

Yes. The free (opensouce) version of my program did exactly
that, if you need an example implementation you can look there.

You just elimate the more common cases where you can't
possibly be in check, and exit. The remaining ones can use
the old routine. You don't have to do everything the hard
way, just the most common ones.

BTW, I looked at Gerbil, and the approach there is like mine.
It does _not_ take the last move into account, but uses tables and
ray information for all pieces on the board.

Ok, I remember wrong then. Gerbil is very fast, so whatever it is
doing must be 'fast enough', I assume.

--
GCP



The start of my post was exactly that I used the results of the useful
performance tests included in your program sjeng (11.2)!
When I started testing, the move-gen speed of sjeng was about
147k Nodes/s and mine was about 45k!!!
However, after looking at your code and looking at mine, figuring out
the differences and a little trial, I managed my program to get to
180k Nodes/s. With makemove-unmake, you are a little better,
but my real bottleneck is InCheck, so that overall doing perft n
yields that your program is twice as fast as mine there.
I noticed in your source code something special about in check testing,
but (as I mentioned) it looked rather complicated to me.
I will have a closer look later.
Another question: I compiled Sjeng with vc6++ and the resulting exe is much
bigger
than the one in the zip archive, additionally it is half that fast! How did
you compile it???
(at least I could compare the results having used the same compiler).

-delphi-

"Delphi" wrote in message
...

Another question: I compiled Sjeng with vc6++ and the resulting exe is
much
bigger
than the one in the zip archive, additionally it is half that fast! How
did
you compile it???
(at least I could compare the results having used the same compiler).

I see two possibilities:

1) You forgot to turn on Release mode and are compiling in Debug mode
2) You are using some version of Visual C++ that doesn't have an
optimizing compiler.

--
GCP

Delphi wrote:
[...]

My q-search is very simple, as I didn't find a good way to reduce the
number
of nodes searched there.
I consider only some captures there, so as in the other search part
InCheck
is called in MakeMove
and of course again in the leaf nodes. Did you mean that by avoiding the
in-check testing?

In the q-search I _never_ do an "in check" test. If you use the same
MakeMove() in the normal and quiescence searches, then it sounds like
you do in-check everywhere..

Well, I do, so this might be one reason for bad performance.
So is in your q-search approach illegality handled but special
scores for king captures?

The simplest answer is to return +king_value, since you are capturing
a king. That should be outside any possible alpha/beta window...


-delphi-

[...]





--
Robert Hyatt Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170



--
Robert Hyatt Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170