Firenzina 2.2.2 xTreme, a clone of Fire 2.2 xTreme

[Gusev]

Fixed and accommodated. Thanks!!

[Gusev]

I was actually thinking of deprecating most of the UCI options, with a focus on fire.cfg.

Matthew, consider creating an IvanHoe GitHub, starting with Velmarin's version of IvanHoe. Velmarin's version compiles under Windows; extra steps may be needed to ensure compatibility with Linux. That IvanHoe won't have those options. With Fire/Firenzina, the problem is, xTreme stands for "xTreme configurability". If it's taken away, the xTreme designation will have to be dropped.

[Gusev]

I have found the troublesome commit: 8a4bcae8d89f2e7174a9dc0ed6ebce291289febd

Or, if you can't read SHA sums, "Linux/Housekeeping/Bug fixes/Extend xTreme/Defs".

Now to find which particular patch caused this.

EDIT: hash.c is the culprit. It isn't needed anyway, a newer version of it is included in the source code, and overridden in hash.h.

Matthew:out

I deleted hash.c. Disregard what I wrote about main.c, I was obviously confused.

[ZirconiumX]

xTreme stands for "xTreme configurability". If it's taken away, the xTreme designation will have to be dropped.

It won't be taken away. You just use fire.cfg instead. This way new users aren't immediately confronted by several billion UCI options, but advanced users can use fire.cfg.

Matthew:out

[ZirconiumX]

I have found the troublesome commit: 8a4bcae8d89f2e7174a9dc0ed6ebce291289febd

Or, if you can't read SHA sums, "Linux/Housekeeping/Bug fixes/Extend xTreme/Defs".

Now to find which particular patch caused this.

EDIT: hash.c is the culprit. It isn't needed anyway, a newer version of it is included in the source code, and overridden in hash.h.

Matthew:out

After hash.c is excluded, does everything compile on your side? Also, is main.c needed? I believe that both came in as parts of the code from JA.

Not really, no.

Code: Select all

$ wc -l errors
134953 errors

The file of error messages is 134,953 lines long.

Matthew:out

[ZirconiumX]

I have found the troublesome commit: 8a4bcae8d89f2e7174a9dc0ed6ebce291289febd

Or, if you can't read SHA sums, "Linux/Housekeeping/Bug fixes/Extend xTreme/Defs".

Now to find which particular patch caused this.

EDIT: hash.c is the culprit. It isn't needed anyway, a newer version of it is included in the source code, and overridden in hash.h.

Matthew:out

After hash.c is excluded, does everything compile on your side? Also, is main.c needed? I believe that both came in as parts of the code from JA.

Not really, no.

Code: Select all

$ wc -l errors
134953 errors

The file of error messages is 134,953 lines long.

Matthew:out

However, having back-ported the major changes (read copied from your Github master) to Firenzina-2_3-xTreme everything runs fine.

Go figure.

Matthew:out

[ZirconiumX]

Matthew,
Given that I had set the default parameters in master to the so-called "Aggressive" option, see if you can
(a) keep a copy of your "Aggressive" compile,
(b) in fire.h, reset the default parameter values back to "Original" ones from my comments (keep the "Aggressive" values in comments),
(c) re-compile under the same compiler settings, and
(d) test to see which compile performs better against Stockfish 2.3.1 for Linux.
The test that I ran today ostensibly predicts that the original settings will fare better (that's why I am suggesting that you reset them in the code), but this is not certain.
Dmitri

I would if cutechess-cli actually launched them...

Matthew:out

[velmarin]

Matthew,
Given that I had set the default parameters in master to the so-called "Aggressive" option, see if you can
(a) keep a copy of your "Aggressive" compile,
(b) in fire.h, reset the default parameter values back to "Original" ones from my comments (keep the "Aggressive" values in comments),
(c) re-compile under the same compiler settings, and
(d) test to see which compile performs better against Stockfish 2.3.1 for Linux.
The test that I ran today ostensibly predicts that the original settings will fare better (that's why I am suggesting that you reset them in the code), but this is not certain.
Dmitri

I would if cutechess-cli actually launched them...

Matthew:out

Quote I put, but only for aiming.

In my opinion, all options, weights etc, are just how statistical noise (so what you write, I think is fine)

I have pieces like the following values​​:
#define PValue 94
#define NValue 315
#define BValue 325
#define RValue 515
#define QValue 975
#define BPValue 42


I like almost all other Ippolits by default
You can experience almost all these options, it will almost certainly noise.
You can see the thread Fire in Inmortalforum, just noise.

I can not imagine testers changing these parameters or cfg file.
In my opinion the end user must be given things done.

If you decide to change to Ivanhoe (may be parallel, two proyects, are equal to 99%) advise Ivanhoe 46h, Robbobaes can put in a DLL, and compiled and also has support chess960.

[Gusev]

xTreme stands for "xTreme configurability". If it's taken away, the xTreme designation will have to be dropped.

It won't be taken away. You just use fire.cfg instead. This way new users aren't immediately confronted by several billion UCI options, but advanced users can use fire.cfg.

Matthew:out

Matthew,

I will give fire.cfg a try. Haven't tested it yet with Firenzina. My immediate concern is, will the options for configuring RobboBases show up?.. Will report.

In the meanwhile, could you please check to see if you can compile master for Linux without fire.c? (This is what I had main.c confused with for a brief moment. There were two files in JA's code that I didn't have before: hash.c and fire.c. I have already removed hash.c, and fire.c is not needed under Windows, either.)

Dmitri

[Gusev]

However, having back-ported the major changes (read copied from your Github master) to Firenzina-2_3-xTreme everything runs fine.

Go figure.

In GitHub, there's a feature that shows to me (I am running Windows) if my local Firenzina is in sync with the master (or another branch, and we currently have just one other, if I select that one). Everything runs, that's good. But is your code in sync with the current master? Please take a look. This is a way to check if we have reached Linux portability yet.