Scorpio bitbases question

[hgm]

Where kan I find a description of how to interface with the EGBB .dll or .so file? I downloaded the source code egbbprobe_src.zip, but it did not seem to contain any README file or other docs.

[Daniel Shawul]

You can find a documentation at https://github.com/dshawul/Scorpio.
Note that the documentation describes the 5-men probing method. The next version of Scorpio will support 6 men (48.1gb in size), which does the probing with null terminated arrays instead of plain piece_1, location_1.

[beachknight]

You can find a documentation at https://github.com/dshawul/Scorpio.
Note that the documentation describes the 5-men probing method. The next version of Scorpio will support 6 men (48.1gb in size), which does the probing with null terminated arrays instead of plain piece_1, location_1.

Great news Daniel.

Could we able to produce 6-men bitbases on our computers?

I will ask the same question to Miguel regarding Gaviota 6-men.

Best,

[hgm]

OK, I found it in the file readme.md. Just for confirmation:
*) Square 1 would be B1?
*) Pieces are numbered 1-6 for PNBRQK
*) Black pieces are negated?

And a dumb question (as I have never used .so files on Linux): is this description platform independent, or only for Windows?

[Daniel Shawul]

OK, I found it in the file readme.md. Just for confirmation:
*) Square 1 would be B1?
*) Pieces are numbered 1-6 for PNBRQK
*) Black pieces are negated?

And a dumb question (as I have never used .so files on Linux): is this description platform independent, or only for Windows?

Here is a link to the new probing code https://github.com/dshawul/Scorpio/blob ... /probe.cpp

The function pointer to probe an egbb looks like

Code: Select all

typedef int (CDECL *PPROBE_EGBB) (int player, int* piece,int* square);

So for 6 men, you put in the piece array the type of piece and in square array the corresponding locations. To indicate the number of pieces, the piece array should be terminated with a 0.
The pieces are numbered

Code: Select all

enum egbb_occupancy {
        _EMPTY,_WKING,_WQUEEN,_WROOK,_WBISHOP,_WKNIGHT,_WPAWN,
    _BKING,_BQUEEN,_BROOK,_BBISHOP,_BKNIGHT,_BPAWN
};

The squares are standard 64 squares table where A1=0 and H8=63. If you are planning to use it just for a GUI, I could add a FEN prober to avoid this hassle.

The .so files are unix dynamically linked libraries corresponding to .dll of windows. Both come with the bitbases so all you have to do is, load the proper file depending on OS (linux/windows) and 32/64 bit. I have the following for that.

Code: Select all

#ifdef _MSC_VER
#        ifdef ARC_64BIT
#                define EGBB_NAME "egbbdll64.dll"
#        else
#                define EGBB_NAME "egbbdll.dll"
#        endif
#else
#        ifdef ARC_64BIT
#                define EGBB_NAME "egbbso64.so"
#        else
#                define EGBB_NAME "egbbso.so"
#        endif
#endif

[Daniel Shawul]

You can find a documentation at https://github.com/dshawul/Scorpio.
Note that the documentation describes the 5-men probing method. The next version of Scorpio will support 6 men (48.1gb in size), which does the probing with null terminated arrays instead of plain piece_1, location_1.

Great news Daniel.

Could we able to produce 6-men bitbases on our computers?

I will ask the same question to Miguel regarding Gaviota 6-men.

Best,

Yes but I don't recommend it for 6 men. Joshua will share them via bittorrent once I manage to send it to him.
Here are the new 5-men which you can use for old engines as well, so you can just replace the old ones
http://shawul.olympuschess.com/egbb/egbb5men.7z
And one 6-men KPPkpp for testing
http://shawul.olympuschess.com/egbb/6men/
You would need a new scorpio version to test the 6-men though because currently no other engine supports them. My current scorpio github code can be compiled to work with them.
Daniel

[hgm]

The squares are standard 64 squares table where A1=0 and H8=63. If you are planning to use it just for a GUI, I could add a FEN prober to avoid this hassle.

Don't bother, as I don't have a FEN available either, just a 2D array, and converting that to a list is easy enough. Is the ordering of the pieces in the list of any importance? Or could I just raster-scan the board and add pieces in the order I encounter them?

I plan to make the name of the egbb dll a configurable option.

I compatibility worry: will the 5-men probing and 6-men probing API continue to exist next to each other?

[Daniel Shawul]

The squares are standard 64 squares table where A1=0 and H8=63. If you are planning to use it just for a GUI, I could add a FEN prober to avoid this hassle.

Don't bother, as I don't have a FEN available either, just a 2D array, and converting that to a list is easy enough. Is the ordering of the pieces in the list of any importance? Or could I just raster-scan the board and add pieces in the order I encounter them?

Yes, you can put them in any order.

I compatibility worry: will the 5-men probing and 6-men probing API continue to exist next to each other?

Yes, even older engines even from 2005 ,when I had only 4 men, can use the new dlls.

I plan to make the name of the egbb dll a configurable option.

This may not be a good idea. Many engines depend on the current naming conventions, so if you rename the dll, other engines won't be able to load them. Engines do not usually make the names configurable via xboard/uci options, because they have to be loaded at start up before any communication is established or even an .ini file is read. Four windows/mac 32/54 bit binaries for egbbprobe will come prepackaged with the bitbases. The mac binaries unfortunately have the same name as the linux ones.

Maybe it would have been better if one common name is used, but that will require replacing dll binaries which will cause even more confusion. I get way too many complains from users who download older dlls and try to use them with new ones, so my solution was try to provide everthing they need with the bitbases they downloaded. In the current way, the bitbases work on 4 systems without the user doing any more than unzipping. A second option is to put them in different directories windows/linux/mac then 32/64 folders which will solve the linux/mac naming clash as both use .so. But this will break older engines compatibility, and also put more work on the engine author.

I am open to changing this way of handling dlls in the new 6-men egbbs. Programers are forced to change to the new way of probing to use them, so I might as well enforce a new naming convention.

[jshriver]

The squares are standard 64 squares table where A1=0 and H8=63. If you are planning to use it just for a GUI, I could add a FEN prober to avoid this hassle.

I'd be interested in that

[mvk]

OK, I found it in the file readme.md. Just for confirmation:
*) Square 1 would be B1?

Careful, square 1 could also be A2. From the Readme.md file one can't tell. All it says is "A1 = 0 ... H8 = 63", which is ambiguous.