Author: Russell Reagan
Date: 11:21:32 02/22/04
Go up one level in this thread
On February 22, 2004 at 13:51:01, Christophe Theron wrote: >Wasting a resource is inefficient programming. I could store a move in two bytes >efficiently and it even made differenciating between regular moves and special >moves like castling, promotion and en passant capture easier. So why would I use >4 bytes when I can use 2 bytes with no loss of performance? > >And yes, I always program with modest hardware in mind. Using 2 bytes for a move >is also good for a PDA program or on 16 bits hardware. Do you use this philosophy throughout your program, or are there exceptions? For instance, one thing I currently do that I would think is an exception is that I represent my board as an array of pointers to piece structs. The piece struct has color, type, square, and a status field (whether it has been removed from the board or not), each of which are ints, so the piece struct totals 16 bytes, even though only 4 bytes would do, and possibly less if I packed the data into an unsigned value instead of using a struct. From what you say, it sounds like you would choose to just have a board of actual pieces packed into unsigned values instead of pointers to piece structs. The reason I do it the way I do is because it seems more efficient to be able to quickly loop through the piece lists and have that information about color, type, and square. Board scanning really isn't much slower since the vast majority of the time I just test whether the square is empty (null pointer), which is something else I learned from you :) This is something I've gone back and forth on. Is it better to use a board of pieces, and a list of squares of occupied pieces? Or is it better to use a board of piece pointers into a list (or lists) or pieces? In addition, is it better to use a struct or pack the data into an unsigned value? Any advice?
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.