Author: Dieter Buerssner
Date: 13:28:10 03/22/04
Go up one level in this thread
On March 22, 2004 at 10:18:25, Heiner Marxen wrote:
>On March 20, 2004 at 16:22:57, Dieter Buerssner wrote:
>
>>On March 20, 2004 at 15:53:42, Heiner Marxen wrote:
>>
>>>Yes, exactly. I've had the exact same problem, and not yet found a really
>>>satisfactory solution. One idea here is to write a conversion function
>>>
>>> const char* counter2str(COUNTER c);
>>>
>>>returning a pointer into a circular collection of sufficiently large
>>>string buffers, allocated statically. If I use (say) 16 such buffers,
>>>I can use up to 16 such conversion result simultaneously in one printf,
>>>while avoiding all problems that appear with dynamic allocation.
>>>
>>> printf("Tried %s, hits=%s\n", counter2str(tried), counter2str(hits));
>>>
>>>With a sufficiently short name for the conversion function this might
>>>work ok. When the typedef changes, we only have to adjust the conversion
>>>function body, but not any uses of it.
>>
>>I thought of the same thing. It will still need a lot of changes in the source
>>(that cannot be done in a semi autmatic way).
>
>While true, once done, the resulting code will be easily adopted to yet
>another 64-bit type.
Yes. For example one could easily try to use double or even long double for the
counters. BTW. In a small experiment of mine (I only converted one counter
manually) the engine ran reproducably slightly faster by either using unsigned
long long or double for the counter, instead of the old unsigned long ...
>Any "semi automatic" method will have to rely on some coding convention,
>as far as I can see. Any practical method available in your mind?
No, not at all. I thought about the following hack. Use C99 printf format. Use
your own printf function with a different name (by calling vprintf - writing it
from scratch, seems overkill and very prone to errors). Many engines will do
this already, to easily implement logging. I from the start didn't use any
literal calls to printf (to be able to "hook in" a simple graphical UI). In your
own printf function, look at the format string. For %llu and %ll only change to
the method supported by the compiler - IIRC it is I64l/u for MSVC, gcc libs
typically support the C99 method). This might have the slight advantage, that
you only need to change the format string in the original call, while other
methods need you to change both, the format string and the argument list. Some
grep in the source tree might find all occurences of %[digs]lu, and only those
need to be changed.
Of course another alternative would be to have a
#define COUNTER_FORMAT_SPECIFIER "llu"
And
printf("Tried %12" COUNTER_FORMAT_SPECIFIER ", hits: %12"
COUNTER_FORMAT_SPECIFIER "\n", tried, hits);
But that would make the format strings rather unreadable.
>> Also, practically, the
>>couter2str() function will need more arguments. printf("%8d", ...); etc. There
>>are many "flags" for the printf conversions (align to the left, add zeroes in
>>the front, etc.). So, having a function for counter2str does not seem to buy
>>much IMHO.
>
>That occured to me, too. First, i.e., because the most important formatting
>attributes (field width and left/right adjustment) work just fine with
>the "%s": "%8s" or "%-8s".
>
>Practically, I very rarely see any other flag at decimal conversions.
>It appears to be a not so bad solution, IMHO.
I agree, it will be practically enough. Didn't really think of it, when I wrote
my followup.
Yet another solution might be to format counters as doubles or long doubles. If
the bin->dec routines of the library are decent, double will be good until 2^53
on almost all modern computers, and print the exact integer. g-format might have
even more advantages (can print smaller numbers like integers, so for
debugging/porting purposes one can compare exact node counts, and still makes it
possible to have aligned tables easily, that do not need too much horizontal
space, by using scientific notation for larger numbers).
Your counter2str function would then be a macro, that casts the argument to
double (or long double). Again many changes in the source ...
Cheers,
Dieter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.