Matthias Gemuh wrote:
Under ChessGUI, you need only the jar file.
Rename it to "Cuckoo 112.jar" without the quotes.
Install as UCI2+java engine. It needs "uci" as command line option.
All this will be good, but if I download JA's compile, I will get the same strength I would think- and I can load that way in 15 or 20 seconds. Why would I choose an alternate method that was more difficult to set up to begin with? The logic escapes me- what am I overlooking?
Best,
gts
You get to know how to run java chess engines for which there are no JA compiles.
There are many of them out there.
Best,
Matthias.
Thanks, Matthias. I knew there had to be a reason. But one more thing. I wonder if there is a difference in Ablett's compile run in your gui and in the Fritz 11 gui. Might there be a problem in your gui that doesn't occur in Fritz gui? The only reason I ask this is because Graham was thinking about not running the engine because of having to set everything up. I know he uses your gui the majority of the time- so I was wondering why he did not consider just running Ablett's compile which requires no instructions. It just doesn't make sense he would pass on the engine thinking the setup might be too complicated. I would think he would have just opted for the compile instead of not running this version. Doesn't make sense. (Won't talk to him again for 10 or 12 hours- hence my asking you.)
What I mean is, which folder inside the zip file does the .jar file reside? I do not see it in any of these folders.
The zip file is the jar file. Just rename it to .jar and it should work.
A jar file is actually a zip file (with specific rules for what it must contain to be a vaild jar file), so I guess your browser tried to auto-detect the file type and decided to change the file extension to .zip.
What I mean is, which folder inside the zip file does the .jar file reside? I do not see it in any of these folders.
The zip file is the jar file. Just rename it to .jar and it should work.
A jar file is actually a zip file (with specific rules for what it must contain to be a vaild jar file), so I guess your browser tried to auto-detect the file type and decided to change the file extension to .zip.
Thank you, Peter.
I like it when I learn something new. And I don't when a program tries to do too much for me.
Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.
Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.
Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.
So it seems like the JExecutable is running the 32-bit JVM even though both 32- and 64-bit version are installed on this computer. Maybe that is expected.
A bigger concern is that the Excelsior compile doesn't produce the same search tree as the other versions. The code is supposed to be deterministic, so this needs some investigation to figure out if the difference could also affect playing strength. (It also means that the Excelsior nps value can't be directly compared to the other versions.)
When searching from the start position, the difference is seen for depth >= 14. I tried two different hash sizes and got 14 in both cases.
Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.
So it seems like the JExecutable is running the 32-bit JVM even though both 32- and 64-bit version are installed on this computer. Maybe that is expected.
A bigger concern is that the Excelsior compile doesn't produce the same search tree as the other versions. The code is supposed to be deterministic, so this needs some investigation to figure out if the difference could also affect playing strength. (It also means that the Excelsior nps value can't be directly compared to the other versions.)
When searching from the start position, the difference is seen for depth >= 14. I tried two different hash sizes and got 14 in both cases.
Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.
So it seems like the JExecutable is running the 32-bit JVM even though both 32- and 64-bit version are installed on this computer. Maybe that is expected.
A bigger concern is that the Excelsior compile doesn't produce the same search tree as the other versions. The code is supposed to be deterministic, so this needs some investigation to figure out if the difference could also affect playing strength. (It also means that the Excelsior nps value can't be directly compared to the other versions.)
When searching from the start position, the difference is seen for depth >= 14. I tried two different hash sizes and got 14 in both cases.
The difference is in evaluation and happens first in this position:
[d]r1bqk2r/pppp1pRp/5n2/2b5/8/2N2P2/PPP1PP1P/R1BQKB2 b Qkq - 0 7[/d]
The java version evaluates this position to 165 and the Excelsior version evaluates it to 185. This exactly matches the bonus for having more than 1 rook on the 7:th rank. To confirm this suspicion, can you please compile this new debug version that adds some logging in the evaluation code: http://web.comhem.se/petero2home/javach ... 112_d2.jar
Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.
So it seems like the JExecutable is running the 32-bit JVM even though both 32- and 64-bit version are installed on this computer. Maybe that is expected.
A bigger concern is that the Excelsior compile doesn't produce the same search tree as the other versions. The code is supposed to be deterministic, so this needs some investigation to figure out if the difference could also affect playing strength. (It also means that the Excelsior nps value can't be directly compared to the other versions.)
When searching from the start position, the difference is seen for depth >= 14. I tried two different hash sizes and got 14 in both cases.
The difference is in evaluation and happens first in this position:
[d]r1bqk2r/pppp1pRp/5n2/2b5/8/2N2P2/PPP1PP1P/R1BQKB2 b Qkq - 0 7[/d]
The java version evaluates this position to 165 and the Excelsior version evaluates it to 185. This exactly matches the bonus for having more than 1 rook on the 7:th rank. To confirm this suspicion, can you please compile this new debug version that adds some logging in the evaluation code: http://web.comhem.se/petero2home/javach ... 112_d2.jar
Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.
So it seems like the JExecutable is running the 32-bit JVM even though both 32- and 64-bit version are installed on this computer. Maybe that is expected.
A bigger concern is that the Excelsior compile doesn't produce the same search tree as the other versions. The code is supposed to be deterministic, so this needs some investigation to figure out if the difference could also affect playing strength. (It also means that the Excelsior nps value can't be directly compared to the other versions.)
When searching from the start position, the difference is seen for depth >= 14. I tried two different hash sizes and got 14 in both cases.
The difference is in evaluation and happens first in this position:
[d]r1bqk2r/pppp1pRp/5n2/2b5/8/2N2P2/PPP1PP1P/R1BQKB2 b Qkq - 0 7[/d]
The java version evaluates this position to 165 and the Excelsior version evaluates it to 185. This exactly matches the bonus for having more than 1 rook on the 7:th rank. To confirm this suspicion, can you please compile this new debug version that adds some logging in the evaluation code: http://web.comhem.se/petero2home/javach ... 112_d2.jar
public class JetBug {
public static void main(String[] args) {
long l = 0;
if (args.length > 0)
l = Long.parseLong(args[0]);
long x = l & (l - 1);
boolean b = (l & (l - 1)) != 0;
System.out.printf("l:%d x:%d b:%d\n", l, x, b?1:0);
}
}
l=18014398509481984 corresponds to the error in the chess position above.
