ArnoHu wrote:

AZURUS41 wrote:

ArnoHu wrote:

AZURUS41 wrote:

HasiLover_Test wrote:

Hello everyone,
I have returned from my chess Tournament and will now go back to work on Scurious.
I have been thinking of holding another chess 960 Tournament today or maybe tomorrow.

I got a question about this, as we know scratch is very slow in terms of calculations, but what is the average nps of the chess bots over here ?
I'm asking because if this time I can make PyChess play 960 with the same speed as Scratch bots, it might participate too ?

On my system (TurboWarp) Scurious was at 200k NPS average (max. 300k) last time I checked, GoK avg. 150k (max. 250k), Element at 70k AFAIR, White Dove at 25k (if NPS calculations are correct)

Search depth reached in certain time might be more insightful.

And: Python as a platform has a huge advantage on performance and feature set (which again influences performance), compared to TurboWarp.

Thanks for the information, however, even if Python might be easier to as a platform, it's beacause of its libraries which I don't use, so it's back to some kind of equal… In comparason, PyChess is only at 7000 nps, which is way less than most of the engines made here.

I did not refer to libraries, but to all the Scratch-inherent overhead TurboWarp has to carry due to compatibility, the lack of 64bit ints and bitwise ops, and more. I do agree that Python is not the fastest either.

birdracerthree wrote:

ArnoHu wrote:

AZURUS41 wrote:

ArnoHu wrote:

AZURUS41 wrote:

HasiLover_Test wrote:

Hello everyone,
I have returned from my chess Tournament and will now go back to work on Scurious.
I have been thinking of holding another chess 960 Tournament today or maybe tomorrow.

I got a question about this, as we know scratch is very slow in terms of calculations, but what is the average nps of the chess bots over here ?
I'm asking because if this time I can make PyChess play 960 with the same speed as Scratch bots, it might participate too ?

On my system (TurboWarp) Scurious was at 200k NPS average (max. 300k) last time I checked, GoK avg. 150k (max. 250k), Element at 70k AFAIR, White Dove at 25k (if NPS calculations are correct)

Search depth reached in certain time might be more insightful.

And: Python as a platform has a huge advantage on performance and feature set (which again influences performance), compared to TurboWarp.

Thanks for the information, however, even if Python might be easier to as a platform, it's beacause of its libraries which I don't use, so it's back to some kind of equal… In comparason, PyChess is only at 7000 nps, which is way less than most of the engines made here.

I did not refer to libraries, but to all the Scratch-inherent overhead TurboWarp has to carry due to compatibility, the lack of 64bit ints and bitwise ops, and more. I do agree that Python is not the fastest either.

I think it might be slower than Turbowarp… although local variables and binary operations are very handy.

Does Python have some sort of overhead as well?

ArnoHu wrote:

HasiLover_Test wrote:

I am going to start running some of the Rounds now and some later.

Cool. But how does elimination work with 9 participants? Groups of 3? Is there some kind of seed list, to that GoK, WD and Element don't meet in 1st round?

HasiLover_Test wrote:

ArnoHu wrote:

HasiLover_Test wrote:

I am going to start running some of the Rounds now and some later.

Cool. But how does elimination work with 9 participants? Groups of 3? Is there some kind of seed list, to that GoK, WD and Element don't meet in 1st round?

It's just random, I could rehold the first round to make sure they dont meet, but I think that would be a bit unfair.

ArnoHu wrote:

HasiLover_Test wrote:

ArnoHu wrote:

HasiLover_Test wrote:

I am going to start running some of the Rounds now and some later.

Cool. But how does elimination work with 9 participants? Groups of 3? Is there some kind of seed list, to that GoK, WD and Element don't meet in 1st round?

It's just random, I could rehold the first round to make sure they dont meet, but I think that would be a bit unfair.

Just two different tournament modes, I am not saying one is better than the other.

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

AZURUS41 wrote:

ArnoHu wrote:

AZURUS41 wrote:

HasiLover_Test wrote:

Hello everyone,
I have returned from my chess Tournament and will now go back to work on Scurious.
I have been thinking of holding another chess 960 Tournament today or maybe tomorrow.

I got a question about this, as we know scratch is very slow in terms of calculations, but what is the average nps of the chess bots over here ?
I'm asking because if this time I can make PyChess play 960 with the same speed as Scratch bots, it might participate too ?

On my system (TurboWarp) Scurious was at 200k NPS average (max. 300k) last time I checked, GoK avg. 150k (max. 250k), Element at 70k AFAIR, White Dove at 25k (if NPS calculations are correct)

Search depth reached in certain time might be more insightful.

And: Python as a platform has a huge advantage on performance and feature set (which again influences performance), compared to TurboWarp.

Thanks for the information, however, even if Python might be easier to as a platform, it's beacause of its libraries which I don't use, so it's back to some kind of equal… In comparason, PyChess is only at 7000 nps, which is way less than most of the engines made here.

I did not refer to libraries, but to all the Scratch-inherent overhead TurboWarp has to carry due to compatibility, the lack of 64bit ints and bitwise ops, and more. I do agree that Python is not the fastest either.

I think it might be slower than Turbowarp… although local variables and binary operations are very handy.

Does Python have some sort of overhead as well?

Why do you think it might be slower?

Well, first of all we should establish what we refer to. Which kind of algorithm. Which Python runtime, interpreted or compiler? Which (if any) Python libraries (often native libs).

I am tempted to implement a benchmark, then no need to be guessing. But knowing the overhead even TurboWarp has to carry over due to Scratch compatibility (“compareEqualSlow()” anybody?), the matter of fact we have to work with lists to emulate a call stack (by slow list access), and more, should make it pretty clear, even if we talk about interpreted Python.

Take a look at what is running when replacing a list element:
https://github.com/TurboWarp/scratch-vm/blob/11eec6604d766dc75fc5eb223b7bd31f167fee88/src/compiler/jsexecute.js#L443
https://github.com/TurboWarp/scratch-vm/blob/11eec6604d766dc75fc5eb223b7bd31f167fee88/src/compiler/jsexecute.js#L415
https://github.com/TurboWarp/scratch-vm/blob/11eec6604d766dc75fc5eb223b7bd31f167fee88/src/compiler/jsexecute.js#L400

In a native language, this is one CPU instruction.

AZURUS41 wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

AZURUS41 wrote:

ArnoHu wrote:

AZURUS41 wrote:

HasiLover_Test wrote:

Hello everyone,
I have returned from my chess Tournament and will now go back to work on Scurious.
I have been thinking of holding another chess 960 Tournament today or maybe tomorrow.

I got a question about this, as we know scratch is very slow in terms of calculations, but what is the average nps of the chess bots over here ?
I'm asking because if this time I can make PyChess play 960 with the same speed as Scratch bots, it might participate too ?

On my system (TurboWarp) Scurious was at 200k NPS average (max. 300k) last time I checked, GoK avg. 150k (max. 250k), Element at 70k AFAIR, White Dove at 25k (if NPS calculations are correct)

Search depth reached in certain time might be more insightful.

And: Python as a platform has a huge advantage on performance and feature set (which again influences performance), compared to TurboWarp.

Thanks for the information, however, even if Python might be easier to as a platform, it's beacause of its libraries which I don't use, so it's back to some kind of equal… In comparason, PyChess is only at 7000 nps, which is way less than most of the engines made here.

I did not refer to libraries, but to all the Scratch-inherent overhead TurboWarp has to carry due to compatibility, the lack of 64bit ints and bitwise ops, and more. I do agree that Python is not the fastest either.

I think it might be slower than Turbowarp… although local variables and binary operations are very handy.

Does Python have some sort of overhead as well?

Why do you think it might be slower?

Well, first of all we should establish what we refer to. Which kind of algorithm. Which Python runtime, interpreted or compiler? Which (if any) Python libraries (often native libs).

I am tempted to implement a benchmark, then no need to be guessing. But knowing the overhead even TurboWarp has to carry over due to Scratch compatibility (“compareEqualSlow()” anybody?), the matter of fact we have to work with lists to emulate a call stack (by slow list access), and more, should make it pretty clear, even if we talk about interpreted Python.

Take a look at what is running when replacing a list element:
https://github.com/TurboWarp/scratch-vm/blob/11eec6604d766dc75fc5eb223b7bd31f167fee88/src/compiler/jsexecute.js#L443
https://github.com/TurboWarp/scratch-vm/blob/11eec6604d766dc75fc5eb223b7bd31f167fee88/src/compiler/jsexecute.js#L415
https://github.com/TurboWarp/scratch-vm/blob/11eec6604d766dc75fc5eb223b7bd31f167fee88/src/compiler/jsexecute.js#L400

In a native language, this is one CPU instruction.

Maybe, maybe… But the fact is that whatever it's coded in, I'm having a lower nps than most of the engines here,
Btw, I've added move ordering so it plays a bit faster ( back to 4500 nps )

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

How does GoK apply stand pat when running check extensions in quiescence? I’m removing stand pat for checks and check evasions, but it is not working.

Standing pat is simply not applied then, and also GoK looks for a check evasion during quiescence search.

Standing pat is not applied during when you are in check and when you are checking the opponent, correct?

By the way, are there any types of puzzles you are interested in? I need more puzzles for the test positions study.

Only for the side that is in check, on its next move. I give it a checkmate base evaluation, and it has to find a way out.

Great puzzles, yes, I already used them before.

So that’s only on check evasions? Is that equivalent to removing stand pat, or is there a difference?

I was asking if you need a different type of puzzle that is not in the study.

If you'd only remove standing pat, I think you would only escape by captures, not by evasions.

So you have to lower alpha as well as remove standing pat, or do I only lower alpha?

I do not apply standing pat, and return a checkmate evaluation, if there is no better move found.

ArnoHu wrote:

What do you mean by main search? Full search at depth 1 before entering quiescence? Or search from depth 2 on? The depth 1 extension affects quiescence only, and quiescence subpath result is identical for the same quiescence entry node. That is why quiescence evals in TT all have search horizon set to -1.

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

How does GoK apply stand pat when running check extensions in quiescence? I’m removing stand pat for checks and check evasions, but it is not working.

Standing pat is simply not applied then, and also GoK looks for a check evasion during quiescence search.

Standing pat is not applied during when you are in check and when you are checking the opponent, correct?

By the way, are there any types of puzzles you are interested in? I need more puzzles for the test positions study.

Only for the side that is in check, on its next move. I give it a checkmate base evaluation, and it has to find a way out.

Great puzzles, yes, I already used them before.

So that’s only on check evasions? Is that equivalent to removing stand pat, or is there a difference?

I was asking if you need a different type of puzzle that is not in the study.

If you'd only remove standing pat, I think you would only escape by captures, not by evasions.

So you have to lower alpha as well as remove standing pat, or do I only lower alpha?

I do not apply standing pat, and return a checkmate evaluation, if there is no better move found.

ArnoHu wrote:

What do you mean by main search? Full search at depth 1 before entering quiescence? Or search from depth 2 on? The depth 1 extension affects quiescence only, and quiescence subpath result is identical for the same quiescence entry node. That is why quiescence evals in TT all have search horizon set to -1.

I set alpha to -99999, but it's having some issues (sometimes it works, sometimes it doesn't, and sometimes it sees the forced sequence). Is this because of Element's depth 8 quiescence causing it to return 99999 if the search extends that far?

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

*snip*

*snip*.

Standing pat is not applied during when you are in check and when you are checking the opponent, correct?

By the way, are there any types of puzzles you are interested in? I need more puzzles for the test positions study.

Only for the side that is in check, on its next move. I give it a checkmate base evaluation, and it has to find a way out.

Great puzzles, yes, I already used them before.

So that’s only on check evasions? Is that equivalent to removing stand pat, or is there a difference?

I was asking if you need a different type of puzzle that is not in the study.

If you'd only remove standing pat, I think you would only escape by captures, not by evasions.

So you have to lower alpha as well as remove standing pat, or do I only lower alpha?

I do not apply standing pat, and return a checkmate evaluation, if there is no better move found.

ArnoHu wrote:

What do you mean by main search? Full search at depth 1 before entering quiescence? Or search from depth 2 on? The depth 1 extension affects quiescence only, and quiescence subpath result is identical for the same quiescence entry node. That is why quiescence evals in TT all have search horizon set to -1.

I set alpha to -99999, but it's having some issues (sometimes it works, sometimes it doesn't, and sometimes it sees the forced sequence). Is this because of Element's depth 8 quiescence causing it to return 99999 if the search extends that far?

In GoK I did not set alpha to -99999, but eval to checkmate-score, and if no move that gets us our of check (or no legal move at all) is found, that is what MiniMax will return.

ArnoHu wrote:

GoK currently has a regression regarding 3-fold-repetition-detection, caused by check-evasion / recent transposition table changes (in certain scenarios it seems them too late), and might run into draws that should not happen). I will look into it later today.

ArnoHu wrote:

ArnoHu wrote:

GoK currently has a regression regarding 3-fold-repetition-detection, caused by check-evasion / recent transposition table changes (in certain scenarios it seems them too late), and might run into draws that should not happen). I will look into it later today.

Fixed. I actually made it more eager, I hope there won't be any false positives (as opposed to false negatives before).

birdracerthree wrote:

ArnoHu wrote:

ArnoHu wrote:

GoK currently has a regression regarding 3-fold-repetition-detection, caused by check-evasion / recent transposition table changes (in certain scenarios it seems them too late), and might run into draws that should not happen). I will look into it later today.

Fixed. I actually made it more eager, I hope there won't be any false positives (as opposed to false negatives before).

Did you change GoK’s contempt factor from -50? I assume you also have a test position?

-089- wrote:

Does someone know how far Bonsai Chess thinks ahead with Blue Belt? I don't think it says it anywhere in the instructions. I've been using it as a benchmark opponent for a while now and normally it's about even with Shallow Blue (if not stronger) but this time it completely blundered the game away on move 5, resulting in SB 4+2 (v2.3b dev, currently unshared. will probably update it later today.) completely flattening Bonsai with 99% accuracy in 21 moves:
https://lichess.org/himODHxU#10
I would assume it's 5+0 or something by how far away the blunder is but I'm not 100% sure.

AZURUS41 wrote:

https://lichess.org/8rbNFdeK#0
Average game beetween me and GoK… 67% accuracy for it is crazy, what happened ?

HasiLover_Test wrote:

ArnoHu wrote:

HasiLover_Test wrote:

ArnoHu wrote:

HasiLover_Test wrote:

I am going to start running some of the Rounds now and some later.

Cool. But how does elimination work with 9 participants? Groups of 3? Is there some kind of seed list, to that GoK, WD and Element don't meet in 1st round?

It's just random, I could rehold the first round to make sure they dont meet, but I think that would be a bit unfair.

Just two different tournament modes, I am not saying one is better than the other.

I will rehold round 1 tomorrow with a new format