Author: Uri Blass
Date: 00:01:50 02/23/05
Go up one level in this thread
On February 22, 2005 at 20:15:23, Scott Gasch wrote: >>>I do not understand assembler so I do not care about it. >>>I think that you take too serious the comparison in lines >>> >>>The fact that you can write things in one line mean nothing. >>>I compare codes that I understand and Tim foden's was the best that I found. >>> >>>I was interesting in the question because I may write something more general and >>>not because I am interested in exact comparison of length. >>> >>>30 lines is better than 50 lines when there is no effort to do it artificially >>>short but 30 lines is not necessaraly better than 32 lines. >>> >>>Uri >> >> >>Note that I understand also stefan's code but ideas that are used in Tim's code >>are better for solving more complicated problems. >> >>The question was what code is best. >> >>length is only an estimate. >>I want code to be clear to me and not to be too long to write(I do not care >>about length in lines and length in lines is only an estimate). >> >>Maybe better estimate is number of chars in the code in case that you use one >>letter for every variable(to prevent clearer code to be bigger because of longer >>names). >> >>Uri > >I think best = shortest and fastest. Programming puzzles rarely award points >for readability. I do not care about it. I plan to implement something more complex(generating all fen with 4 pieces) I want to have a loop on all the possible combination of 4 pieces and for every combination to have function that generate all the possible fen. Tim's code seems to be the most productive that I saw for that purpose. > >I find it strange that you consider the number of chars in the code as a >suitable measurement but not the number of lines of asm it produces. The number of chars is important because I do not want to write a long code. number of asm is irrelevant because I never read assembler and never understood it. If >"shortest" is indeed a goal I think lines of asm with the same compiler settings >is a good way to measure it. I think that it is irrelevant. The question is how you do things faster. Normal shorter code is less time to read so it is usually better and easier to understand. using the number of chars is of course only approximation and I cannot give exact mathematical condition for what is better. > >As for speed, average execution time on the same machine would be a good >estimate. speed is not relevant for me. speed is relevant for other programming task but when I think about debugging tablebases it is not relevant unless the code is very slow. It seems that we disagree about the target. target of less assembler lines or less time are not important for me here. 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.