TalkChess.com

Hi Louis,

Just in case your engine might appear on our list: where are you from?

Hi there Raoni,

thank you for your kind words! I will definitely look into Travis, as it seems like it could be a real help, thanks for this cool idea.

Kind regards,

Louis

Hi Tirsa,

thank you for your help and support! Well noticed about the node count. I was not counting any moves made in Q search, which made the number rather low. It is still pretty low, but I see this as a challenge for the future

With regard to the version info in the ID name: I am not sure I understand exactly what you mean - when the engine receives the "uci" command, it currently prints:
id name Axolotl-v1.1
id author Louis James Mackenzie-Smith

Are you recommending lengthening the id name part, to become, for example:
id name Axolotl-v1.1, improved move ordering
?

Sorry if I have misunderstood what you mean,

Kind wishes,
Louis

Hi Gabor,

I am from the UK and France. I don't suppose there is support for this?
If not, then just a UK flag.

Thank you kindly for your interest,
Best,
Louis

AxolotlFever wrote: ↑Fri Nov 16, 2018 10:48 am when the engine receives the "uci" command, it currently prints:
id name Axolotl-v1.1
id author Louis James Mackenzie-Smith

That's not what I get here:
Axolotl.jar CRC-32: 7B2B8144

One good archiving practice to follow is always ZIP your files to preserve the original timestamps.

BTW, the .jar for v1.1 is only about half the size of that for v1; is that by design?

Hi Tirsa,

Thanks again for noticing this! I had changed this in my source code, but made a mistake in the commit. I hope you will not have this issue again.
The reason for the larger .jar was that I accidentally bundled some test classes that are not used in the final product. I have removed them, this was a mistake :/

I am curious about your zip idea - if I understand you correctly, are you suggesting that I commit a zipped version of the source code and .jar? I am sorry that I misunderstand you on this.

Thank you very much for your continued support,

With best wishes,
Louis

AxolotlFever wrote: ↑Fri Nov 16, 2018 8:58 pm Thanks again for noticing this! I had changed this in my source code, but made a mistake in the commit. I hope you will not have this issue again.
The reason for the larger .jar was that I accidentally bundled some test classes that are not used in the final product. I have removed them, this was a mistake :/

I see, thank you for the explanation.

AxolotlFever wrote: ↑Fri Nov 16, 2018 8:58 pmI am curious about your zip idea - if I understand you correctly, are you suggesting that I commit a zipped version of the source code and .jar?

The idea is that once you implement the release system recommended by Raoni the .jar you provide should be zipped. The purpose is preserving the original timestamp of the file. When someone downloads your .jar his browser will set the timestamp to the time of the download; zipping avoids that.

Another idea is to have the version number in the filename, e.g. "axolotl-112.jar" rather than "axolotl.jar".

A new Java engine!

I've just looked at your code and have some performance suggestions:

1) Use Long.numberOfTrailingZeros() instead of getIndexOfFirstPiece()
2) Use the following code instead of getIndexOfAllPieces():

I didn't run the engine, but I have some notes from reading the source code:

This may seem obvious, but run the engine with profiling to find out where it's spending most of its time. This is necessary before attempting any optimization.

Instead of returning ArrayList objects from each of your move generation methods, pass a List<Move> as a parameter to each move generation method and have them add to the provided list. However, this may be a negligible performance improvement -- see above.

It looks like your transposition table will grow without bounds (unless I missed something). Normally, a transposition table is a simple array with a fixed size (usually configurable in UCI options), with a bucket replacement strategy (simplest being "always replace"). Board positions are indexed by [zobristHash % array.length].

An engine with your feature set, written in java, should be able to achieve more than 1Mn/s (single threaded, on a modern CPU). One area of concern with java is, of course, the gc. Not sure how much it slows you down, but creating many small objects (moves being the main thing I noticed) certainly isn't helping you.

AxolotlFever wrote: ↑Fri Nov 16, 2018 10:57 am I am from the UK and France. I don't suppose there is support for this?

Go team France !