Author: Dezhi Zhao
Date: 14:14:35 02/22/03
Go up one level in this thread
On February 22, 2003 at 16:00:00, Uri Blass wrote:
>On February 22, 2003 at 15:28:06, Dezhi Zhao wrote:
>
>>On February 22, 2003 at 02:54:40, Uri Blass wrote:
>>
>>>On February 21, 2003 at 15:59:25, Dezhi Zhao wrote:
>>>
>>>>On February 21, 2003 at 13:31:50, Uri Blass wrote:
>>>>
>>>>>On February 21, 2003 at 13:10:27, Dezhi Zhao wrote:
>>>>>
>>>>>>On February 21, 2003 at 12:48:45, Uri Blass wrote:
>>>>>>
>>>>>>>On February 21, 2003 at 11:15:24, Dezhi Zhao wrote:
>>>>>>>
>>>>>>>>On February 21, 2003 at 04:14:49, Uri Blass wrote:
>>>>>>>>
>>>>>>>>>On February 20, 2003 at 13:51:37, Filip Tvrzsky wrote:
>>>>>>>>>
>>>>>>>>>>On February 20, 2003 at 12:49:39, Uri Blass wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>I guess that you mean
>>>>>>>>>>>#define gen_dat_i_mpromote (gen_dat[i].m & (63 << 16))
>>>>>>>>>>>
>>>>>>>>>>>I guess that the laternative that I tried
>>>>>>>>>>>
>>>>>>>>>>>#define to(x) (((x)>>8)&255) was also bad
>>>>>>>>>>>and better was
>>>>>>>>>>>#define to(x) (((x)&255<<8)
>>>>>>>>>>>
>>>>>>>>>>>I guess that in that case I need to change some more code
>>>>>>>>>>>
>>>>>>>>>>>For example
>>>>>>>>>>>
>>>>>>>>>>>I have today some cases when I have
>>>>>>>>>>>switch(m.bits)
>>>>>>>>>>>case 1:
>>>>>>>>>>>case 17:
>>>>>>>>>>>...
>>>>>>>>>>>
>>>>>>>>>>>in that case I need to say case 1<<24 and in order not to have an ugly code
>>>>>>>>>>>I need to have more constants for 2^24,2^24*17,...
>>>>>>>>>>>
>>>>>>>>>>>I can use
>>>>>>>>>>>enum
>>>>>>>>>>>{
>>>>>>>>>>> bits1=16777216
>>>>>>>>>>> bits17=
>>>>>>>>>>>...
>>>>>>>>>>>}
>>>>>>>>>>>
>>>>>>>>>>>Uri
>>>>>>>>>>
>>>>>>>>>>#define to(x) (((x)>>8)&255) is definitely worse than #define to(x)
>>>>>>>>>>(((x)&255<<8) because in the first case the shifting is done in run-time and in
>>>>>>>>>>the second during compilation. Note also that the result of both macros is
>>>>>>>>>>different.
>>>>>>>>>
>>>>>>>>>Yes
>>>>>>>>>
>>>>>>>>>This is an important note.
>>>>>>>>>
>>>>>>>>>I did not do the mistake of assuming that they are the same but I see that I
>>>>>>>>>have problems.
>>>>>>>>>
>>>>>>>>>I cannot use my usual macros after that translate
>>>>>>>>>
>>>>>>>>>for example
>>>>>>>>>
>>>>>>>>>I had if (piece(m.b.to))=PAWN) in my code
>>>>>>>>>I cannot transalate it to
>>>>>>>>>if (piece(to(m))==PAWN) because to(m) does not get something between 0 and 63
>>>>>>>>>after the change and it seem that I cannot do it faster in this case.
>>>>>>>>>
>>>>>>>>
>>>>>>>>you probabaly need another inline function or micro here:
>>>>>>>>
>>>>>>>>#define IsPawn(move) (piece(move.b.to) == PAWN)
>>>>>>>
>>>>>>>note that piece() is not a function and it is in my defines
>>>>>>>
>>>>>>>#define piece(square) ((info[square])&7)
>>>>>>>
>>>>>>>The point is that info[64] include for every square both the color and both the
>>>>>>>piece and the piece can be accesed by the array info[64] that is an array of
>>>>>>>int.
>>>>>>>
>>>>>>
>>>>>>nested macroes are OK.
>>>>>>
>>>>>>>>
>>>>>>>>If you are using VC, inline functions are prefered. You can easily browse these
>>>>>>>>inline fuctions. And the compiler does type checking that is certainly helpful.
>>>>>>>
>>>>>>>I do not see a function that I should inline in that case because there is no
>>>>>>>function in the code that I posted(only macros).
>>>>>>>
>>>>>>
>>>>>>You missed the point that a inline function is the same in effect as a macro.
>>>>>>A inline function _is_ a much better macro.
>>>>>
>>>>>Thanks for the advice.
>>>>>I use visual C++ but
>>>>>I saved the files in my project as .c
>>>>>I guess that inline functions mean that I need to change the .c to .cpp first
>>>>
>>>>yes. a simple rename
>>>
>>>It is not so simple because I get errors from doing it
>>>
>>>hash_table = calloc(TableSize, sizeof( HASHE ));
>>>
>>>: error C2440: '=' : cannot convert from 'void *' to 'struct tagHASHE *'
>>> Conversion from 'void*' to pointer to non-'void' requires an explicit
>>>cast
>>>evaluate.cpp
>>>
>>>I get also warnings that I did not get in C
>>>
>>>warning C4390: ';' : empty controlled statement found; is this the intent?
>>>
>>>My reply Yes it is
>>>I ignore opponent time but I may use it in the future so I told my program to do
>>>nothing when it gets the opponent time from winboard.
>>>
>>>warning C4551: function call missing argument list
>>>
>>>At least I could fix that warning by changing
>>>
>>>input_available
>>>to
>>>input_available()
>>>
>>>Strange that I did not get the same warning in C.
>>>
>>>Uri
>>
>>These added warnings are good things in fact. C++ has some more tight type
>>checking. So you may consider changing those generating warnings, like this:
>>
>>hash_table = (tagHASHE*) calloc(TableSize, sizeof(HASHE));
>>
>>or the C style:
>>
>>hash_table = (struct tagHASHE *) calloc(TableSize, sizeof(HASHE));
>>
>>dzhao
>
>Thanks but I still have problems.
>
>I tried in my C files(I renamed them back to C) and got the following warnings
>
>warning C4047: 'function' : 'unsigned int ' differs in levels of indirection
>from 'struct tagHASHE *'
this warning must come from somewhere else. you can double-click at the warning
to see which line it is complainng about.
>warning C4024: 'calloc' : different types for formal and actual parameter 1
>
>
>Note that TableSize is an integer and here is the relvant defintion in my
>program.
parameter 1 of calloc is an unsigned. so you may define TableSize as unsigned.
>
>typedef struct tagHASHE
>{
> __int64 key;
> unsigned int depth:7;
> unsigned int flags:2;
> signed int value:16;
> move best;
>} HASHE;
>
>Uri
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.