Author: Robert Hyatt
Date: 11:21:22 05/19/04
Go up one level in this thread
On May 19, 2004 at 11:46:38, Reinhard Scharnagl wrote: >On May 19, 2004 at 11:07:07, Vincent Diepeveen wrote: > >>On May 19, 2004 at 10:31:28, Reinhard Scharnagl wrote: >> >>the 'main algorithm' >> >>J.C. what kind of nonsense you post? > >Different people simetimes are using different words. > >>90% of my program is evaluation not algorithm. > >You must be a genius. I cannot imagine an evaluation function without >any sort of algorithm. And overmore you intuitivly have pointed to my >main algorithm - I do not know from where you get your values instead. >If this was not an algorithm, it for sure must be a kind of randomizer. > >So good luck for you in the coming competition. Vincent just doesn't use the same vocabulary the rest of the world uses. He makes up definitions to fit his agenda regardless of what literature says. See the "depth-first" idiocy he has posted elsewhere for but one example. > >Still wondering, what sort of problems you might have with me. Leave off the "with me" and you are much closer to the truth... just "a problem". > >Reinhard. > >>>On May 19, 2004 at 10:16:27, Vincent Diepeveen wrote: >>> >>>>On May 19, 2004 at 09:54:30, Reinhard Scharnagl wrote: >>> >>>>i hope you realize nalimov egtb code when used makes executable sizes quite some >>>>larger. >>>> >>>>default diep is like its latest version: >>>> 16-05-2004 23:05 335.872 diepm_16may2004.exe >>>> >>>>but when i compiled once with nalimov egtb code a few months ago : >>>> >>>> 21-02-2004 01:48 2.002.944 diepm_20feb04_wb.exe >>>> >>>>Only difference : >>>> >>>> egtb.cpp >>> >>>That is your decision. >>> >>>>I did compile without -O2 by the way for the c++ code. >>>> >>>>So anyone using C++ you are going to doom? >>> >>>That is your opinion. >>> >>>>>On May 19, 2004 at 09:33:19, Vincent Diepeveen wrote: >>>>> >>>>>>On May 19, 2004 at 08:38:55, Reinhard Scharnagl wrote: >>>>>> >>>>>>>On May 19, 2004 at 07:15:54, Vincent Diepeveen wrote: >>>>>>> >>>>>>>>On May 19, 2004 at 01:02:26, Reinhard Scharnagl wrote: >>>>>>>> >>>>>>>>You obviously never wrote a chessprogram writing such utter nonsense at your >>>>>>>>homepage about executable size. >>>>>>> >>>>>>>Vincent, please cool down. >>>>>>> >>>>>>>Obviously you know neither me nor my experiences with that theme. >>>>>>> >>>>>>>May be you have not noticed, that I am always talking of the size of the >>>>>>>persistent data and exe AFTER COMPRESSING it, e.g. by WinRar. >>>>>>> >>>>>>>Regards, Reinhard. >>>>> >>>>>>I'm not using winrar but RKC. >>>>>> >>>>>>See for example : http://www.maximumcompression.com/programs.php >>>>> >>>>>You can choose what you want, but a self decompressing version would >>>>>be best. WinRar simply has been an example. Compression should be >>>>>needed only for the measuring act, that is all. >>>> >>>>winrar is no realtime executable compressor. >>> >>>Does it matter? >>> >>>>>>So whatever your uncompressed size, mine will be up to 4 to 10 times smaller in >>>>>>size than your outdated compression standards. >>>>> >>>>>Great. Then 1/4 MB seems to be quite reachable for you. >>>> >>>>yes and when started after a few years with that 1/4 MB i can also generate a GB >>>>or 10 of egtb's (all 6 men). another few years and all 7 men are there too. >>> >>>egtb's are not relevant for the quality of the main algorithm. They are >>>of high relevance in analysing tasks. But implementing huge look up tables >>>are counterproductive to bring e.g. evaluation functions foreward. >>> >>>Therefore analysing and playing programs have to be distinguished. >>> >>>>>>If i want to compress fast i'm using 7-zip btw. >>>>>> >>>>>>Also a single compile option can matter 500KB in size easily. >>>>>> >>>>>>Further moving from x86 hardware to IPF hardware means executable size for same >>>>>>program with same compiler already grows a factor 2-3. >>>>>> >>>>>>That's without being optimized of course with PGO. >>>>>> >>>>>>When you optimize with PGO your executable at IPF grows bigtime in size. >>>>>> >>>>>>Now so far we still discussed just C software. >>>>>> >>>>>>How about C++ guys, or delphi guys? >>>>>> >>>>>>They make no chance in your definition.... >>>>> >>>>>You will notice that the higher the language level is, the more you are >>>>>able to compress the resulting exe. Therefore measuring the size of the >>>> >>>>What will be left after compression will still be considerable larger. >>> >>>This is no contradiction to what I have said. >>> >>>>>compressed files would make you more independent from the decision, which >>>>>language you have selected for development. Other criteria there will be >>>>>more important. >>>>>Regards, Reinhard. >>>> >>>>In short you have a lot of crap statements at your homepage. It's loaded with >>>>it. I didn't find anything intelligent at your homepage. >>> >>>Simply open up your eyes! What makes you having problems with me? >>> >>>>For example try to lookup the difference between a preprocessor in chess and non >>>>preprocessor. >>>> >>>>You invented a new name for it without realizing what you were looking for. >>> >>>I have lost interest continuing to talk with you on that. >>> >>>Reinhard. >>> >>>>>>>>>On May 19, 2004 at 00:29:42, Joshua Shriver wrote: >>>>>>>>> >>>>>>>>>>Are there any kind of hardware limitations in computer competitions? >>>>>>>>>> >>>>>>>>>>If not, I'd imagine people would just bring a small custom cluster. >>>>>>>>>> >>>>>>>>>>TSCP would beat Hiarcs or Shredder if tscp was parallelized and Hiarcs was on a >>>>>>>>>>486. >>>>>>>>>> >>>>>>>>>>Just an idea; perhaps there should be some kind of limitation. >>>>>>>>>>If not then you're not really testing the strength of the engines, but a >>>>>>>>>>combination of code and hardware. In that case, whoever has the most money has a >>>>>>>>>>huge advantage. Especially if clustering is allowed. >>>>>>>>>> >>>>>>>>>Just my $0.02, curious to your opinions. >>>>>>>>> >>>>>>>>>Have you ever seen my limitation proposal to that theme at: >>>>>>>>> >>>>>>>>>[http://homepages.compuserve.de/rescharn/Compu/schachfair_e.html] >>>>>>>>> >>>>>>>>>Regards, Reinhard.
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.