Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: speed question

Author: Dezhi Zhao

Date: 12:28:06 02/22/03

Go up one level in this thread


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



This page took 0.01 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.