Soberango 0.00.0 realized.

[tttony]

Soberango 0.09.4 realized.

I decided to turn off quiescence search. The level with it is weaker than without it because the loss of speed doing it.
I need to make a faster captures generator before activate QS again.

Web: http://www.luisbtenis.com.ar/Soberango/Soberango.html

I have no tested your engine yet, but I faced some problems with qsearch, like search explosion and mega blunders in the alphabeta search, what I did to solve it was:

Don't qsearch when in check and inside qsearch after makemove, if the moves gives check just continue to next move
In the search, like I said I was facing with mega blunders, my engine does not have trans table, just plain alphabeta search, no null move, no extensions, no killers, no history, also in the eval only PST from CPW etc... so there is no point to have a pv line, so at the end of the search I just save the first root "bestmove" and the engine played much better

Having a simple engine helps solving this kinds of problems, try to turn off all the features and test each feature to see if there is a hidden bug

[Luis Babboni]

I´m still working on test if QS works properly, actually I think yes but not sure.
0.09.4 is the best I have and the previous ones, 0.09.2 and 0.09.3 have certanly a buggy QS, thats why I posted 0.09.4 even not be 100% sure about it is correct.

I still thinks, that if QS works properly, the speed is the greater problem. I think my moves generator is very poor: use a simple 8x8 array!
The number: captures found / moves searched (that is what I´m looking for in QS) is far lower than possible moves / moves searched (thats is what the program do in full width search).
I mean this, in full width search I found that, say, 1% of the moves my generator test are possible moves, but in QS, just 0.1% of the moves my generator test are possible captures. The moves generator test the same number of moves in both cases but found far less in QS than in full width search. So the number of possible moves found per time unit, fall down a lot as soon as I start QS.
One way to improve this could be to not go so depth in QS with different criterium to decide when a capture deservs to not go further. Actual criterium is just if the captured piece have less value than the capturing one.
What convenced me of the speed problem is the comments chessprogramming web do about why to use bitboards here: https://chessprogramming.wikispaces.com ... ce+Attacks
"In Quiescence Search the performance of generating (winning) capture moves is crucial."

I repeat, I´m still not 100% sure that the QS works properly and I working on it with Sven´s help, but I´m thinking I will need something like use bitboards for at least to find the captures in the QS.


PS: of course any comment about it is WELCOME and thanks for your time buddies!!

[Luis Babboni]

Soberango 0.09.5 realized.

Thanks to Sven Schüle help, I could find why my QS was wrong* and now is working far better what makes Soberango skills made a jump ahead, may be some tens of ELO points.
*:he helped me in many other things too

I having problems with my web hosting so here a link to the exe:
https://dl.dropboxusercontent.com/s/rue ... 5.exe?dl=0

[zenpawn]

If you don't mind sharing, what was the issue with your QS?

[Luis Babboni]

The web up again!
http://www.luisbtenis.com.ar/Soberango/Soberango.html

[Luis Babboni]

If you don't mind sharing, what was the issue with your QS?

I didn´t it correctly.
Principaly, the engine did not make cutoffs using the static evaluation as a parameter.
In other words.... I did not understood how it must work!
Sven suggested me to make the engine able to print the search tree to could test it properly and then pointing me every time the QS works wrong till we find that works as it must..... it seems*!
*: at least now the skills are clearly better with QS than without QS as was before.
Plus that, he used a lot of his time to take a detailed look to my messed code to suggest other improvements (mostly to cut redundant use of code that are waste of time ) that I´ll for sure try to implement in next versions.

[Luis Babboni]

Soberango 0.09.6 realized.

Fixed two bugs:
One that made that after force mode, for example following an opening dictated by the GUI, evaluation have a constant shift from zero that made that eventually the engine crash.
Other that not allow the engine to detect some possible enpassant captures.

Web: http://www.luisbtenis.com.ar/Soberango/Soberango.html

[Luis Babboni]

Version 0.09.7 realized.

Fixed a pair of bugs* still remained after the implementation of QS and cuted some redundant code that made the engine did some checkings twice useless.
I think now have around 1100 ELO points in 40/4 compared with other engines in the CCRL rank.
*one did not allow to find castlings as possible moves during QS and the other did not allow to pass the actual best move to next iteration if that includes a QS part.

Web: http://www.luisbtenis.com.ar/Soberango/Soberango.html

[Luis Babboni]

Version 0.09.7 realized.

Fixed a pair of bugs* still remained after the implementation of QS and cuted some redundant code that made the engine did some checkings twice useless.
I think now have around 1100 ELO points in 40/4 compared with other engines in the CCRL rank.
*one did not allow to find castlings as possible moves during QS and the other did not allow to pass the actual best move to next iteration if that includes a QS part.

Web: http://www.luisbtenis.com.ar/Soberango/Soberango.html

Mmmmm... some problems with 0.09.7 version..... need to reuploaded it.

Thanks to Sven Schüle to see a wrongly fixed I did and I need to fix it again for next 0.09.8 version.

[Luis Babboni]

Soberango 0.09.8 version realized.

Version 0.09.7 had two bugs, stupid bugs.

Web: http://www.luisbtenis.com.ar/Soberango/Soberango.html