If you wuold rewrite crafty yourself assuming you don't get informed of newer developments where others profitted from:
You seriously underestimate the positive things that others have brought to you into crafty.
a) it would take 10 years
b) it would play 500 elo weaker at the same hardware
c) it would be 2x slower in nps
d) you would again have a testing problem as someone needs to write that code to automatically test. We are still awaiting the 'few scripts' that you use to automatically test crafty and modify its parameters with those scripts.
When you used to edit in crafty source code yourself, 2 bytes got changed, boom new version. No serious testing. Your current helpdesk moves forward so fast that others in CCC, such as Uri Blass, must explain to you, very painful, what the current crafty is actually doing.
Doing a simple compare of version 22.x with 23.x shows the huge number of changes done to crafty.
You wouldn't manage those changes yourself in a 100 years.
Vincent
Sorry, but 99.9% of the changes made in the past 10 years were done by me, and me alone. So I do not know where you are getting your info. We didn't do any 2 byte = new version changes either. Each version represented either a significant change, or a bug fix of any time if it was deemed an important bug (mostly dealing with xboard protocol or perhaps in the early SMP days of Crafty, a significant SMP bug).
The only code changes Tracy has made were in the evaluation. Generally he tries different scores. Or new terms. Or new ways of computing old terms. If it looks promising, I end up looking at the code from a pure efficiency point of view and modifying it as needed to restore performance. The rest of the program (excluding just eval) has been solely my editing. And in the eval, we are probably 50-50 as to who changed what...
Your numbers are off by orders of magnitude...
bob wrote:
Dann Corbit wrote:
bob wrote:
Dann Corbit wrote:
Don wrote:
Houdini wrote:
Don wrote:I think you are correct. I personally AM a fan of rewrites but I think there are many chess authors that don't ever rewrite, or have only done so once in years.
Rewriting for the sake of rewriting doesn't serve any purpose at all.
Software with a good architecture will survive many years and many changes.
Robert
I don't rewrite just for the sake of it.
Don
Typical reasons for rewriting:
1. Change of language (e.g. C to C++)
2. Change of underlying data structures (e.g. mailbox to bitboard)
3. Increased programming ability (every decade, my programming skills increase quite a bit, so the code I wrote 20 years ago will benefit considerably from a rewrite).
4. Lost code (yes, it does happen -- I have sent code back to chess authors who lost their original code and who had also sent their code to me on several occasions, for instance).
I don't agree with those.
(1) can be solved via translation. A good program can be translated to a new language without rewriting a thing...
Basic to C++?
Pascal to Java?
Fortran to C?
I have seen the latter two. And Zortech used to sell the Fortran to C translator. I probably still have a copy in my office. I used it to make the original translation of the CB source to C back in 1994. The code was not very clean looking, because it was just a one-for-one translation to C. And since FORTRAN didn't have pointers in the f77 standard, the resulting C code did not use pointers. So it needed a lot of cleaning up to become "decent C". But the output of the translator would compile and run and produce identical results to the original FORTRAN program.
I think there is even a GNU fortran to C translator. I have not used it, but have noticed it in installing several different Linux distros. Something like f2c or something. But no info on how well it works...
(2) I did the mailbox-to-bitboard translation with Crafty. It only affects a part of the code. Search is unchanged. Move ordering is unchanged. Several other things are completely board representation independent.
Crafty is a giant machine with nearly 40K lines of code. At ten lines per hour and $100/hour that would translate to $400,000 worth of work. It would be a titanic effort, therefore, to rewrite crafty. Smaller programs of a few hundred lines would be far more likely candidates for such an effort.
I can't speak for everyone, but I produce a lot more than 10 lines per hour. Don't forget, half of those 40K + lines of code are simply comments that don't need translation, and also help in understanding... I would suspect it would take a year of solid work to rewrite Crafty from scratch, assuming I could access the comments but not the source instructions, to get it back to something close to the current state. Might take longer to get the speed back to where it is...
(3) I don't think is that common. One does not rewrite _everything_ just because they are a better programmer now than 10 years ago. you might rewrite _parts_. But not the whole thing. That is a huge waste of time and effort.
I have done it, but typically with small projects. TSCP needs a complete rewrite, for instance.
(4) Never had that happen to the current version of code since I always keep duplicates and backups scattered around.
It is the result of carelessness when code is lost, but it does happen. I suspect that you have lost at least one or more snapshot of a released version of Cray Blitz or Crafty (at least in the early stages) because with hobby projects that are not producing revenue we sometimes are not quite as careful as when a big pile of money is at stake.
I lost about 80% of everything in 1995. Not the current version as it is always kept in multiple locations such as my office box, my laptop, and a central NFS file server on top of that. But old versions I kept only on my office box and a disk crash and later discovery that all backups were unreadable lost a lot of old stuff. I now have everything stored in three places, with a simple mechanism to scatter the duplicates to the right places after a change is made...
If you wuold rewrite crafty yourself assuming you don't get informed of newer developments where others profitted from:
You seriously underestimate the positive things that others have brought to you into crafty.
a) it would take 10 years
b) it would play 500 elo weaker at the same hardware
c) it would be 2x slower in nps
d) you would again have a testing problem as someone needs to write that code to automatically test. We are still awaiting the 'few scripts' that you use to automatically test crafty and modify its parameters with those scripts.
When you used to edit in crafty source code yourself, 2 bytes got changed, boom new version. No serious testing. Your current helpdesk moves forward so fast that others in CCC, such as Uri Blass, must explain to you, very painful, what the current crafty is actually doing.
Doing a simple compare of version 22.x with 23.x shows the huge number of changes done to crafty.
You wouldn't manage those changes yourself in a 100 years.
Vincent
Sorry, but 99.9% of the changes made in the past 10 years were done by me, and me alone.
then looking at the source code where starting from version 23, now the huge changes to the evaluation function show some typical mathematical personality, one that loves matrix calculations, someone who has no clue about chess; further some very atypical speedups here and there elsewhere in the code, done by someone who is more pragmatic than the devil. So 2 different programming styles got added to crafty 23+. 2 styles not seen before in the crafty coding.
Did your personality change recently Bob?
So I do not know where you are getting your info. We didn't do any 2 byte = new version changes either. Each version represented either a significant change, or a bug fix of any time if it was deemed an important bug (mostly dealing with xboard protocol or perhaps in the early SMP days of Crafty, a significant SMP bug).
The only code changes Tracy has made were in the evaluation. Generally he tries different scores. Or new terms. Or new ways of computing old terms. If it looks promising, I end up looking at the code from a pure efficiency point of view and modifying it as needed to restore performance. The rest of the program (excluding just eval) has been solely my editing. And in the eval, we are probably 50-50 as to who changed what...
Your numbers are off by orders of magnitude...
bob wrote:
Dann Corbit wrote:
bob wrote:
Dann Corbit wrote:
Don wrote:
Houdini wrote:
Don wrote:I think you are correct. I personally AM a fan of rewrites but I think there are many chess authors that don't ever rewrite, or have only done so once in years.
Rewriting for the sake of rewriting doesn't serve any purpose at all.
Software with a good architecture will survive many years and many changes.
Robert
I don't rewrite just for the sake of it.
Don
Typical reasons for rewriting:
1. Change of language (e.g. C to C++)
2. Change of underlying data structures (e.g. mailbox to bitboard)
3. Increased programming ability (every decade, my programming skills increase quite a bit, so the code I wrote 20 years ago will benefit considerably from a rewrite).
4. Lost code (yes, it does happen -- I have sent code back to chess authors who lost their original code and who had also sent their code to me on several occasions, for instance).
I don't agree with those.
(1) can be solved via translation. A good program can be translated to a new language without rewriting a thing...
Basic to C++?
Pascal to Java?
Fortran to C?
I have seen the latter two. And Zortech used to sell the Fortran to C translator. I probably still have a copy in my office. I used it to make the original translation of the CB source to C back in 1994. The code was not very clean looking, because it was just a one-for-one translation to C. And since FORTRAN didn't have pointers in the f77 standard, the resulting C code did not use pointers. So it needed a lot of cleaning up to become "decent C". But the output of the translator would compile and run and produce identical results to the original FORTRAN program.
I think there is even a GNU fortran to C translator. I have not used it, but have noticed it in installing several different Linux distros. Something like f2c or something. But no info on how well it works...
(2) I did the mailbox-to-bitboard translation with Crafty. It only affects a part of the code. Search is unchanged. Move ordering is unchanged. Several other things are completely board representation independent.
Crafty is a giant machine with nearly 40K lines of code. At ten lines per hour and $100/hour that would translate to $400,000 worth of work. It would be a titanic effort, therefore, to rewrite crafty. Smaller programs of a few hundred lines would be far more likely candidates for such an effort.
I can't speak for everyone, but I produce a lot more than 10 lines per hour. Don't forget, half of those 40K + lines of code are simply comments that don't need translation, and also help in understanding... I would suspect it would take a year of solid work to rewrite Crafty from scratch, assuming I could access the comments but not the source instructions, to get it back to something close to the current state. Might take longer to get the speed back to where it is...
(3) I don't think is that common. One does not rewrite _everything_ just because they are a better programmer now than 10 years ago. you might rewrite _parts_. But not the whole thing. That is a huge waste of time and effort.
I have done it, but typically with small projects. TSCP needs a complete rewrite, for instance.
(4) Never had that happen to the current version of code since I always keep duplicates and backups scattered around.
It is the result of carelessness when code is lost, but it does happen. I suspect that you have lost at least one or more snapshot of a released version of Cray Blitz or Crafty (at least in the early stages) because with hobby projects that are not producing revenue we sometimes are not quite as careful as when a big pile of money is at stake.
I lost about 80% of everything in 1995. Not the current version as it is always kept in multiple locations such as my office box, my laptop, and a central NFS file server on top of that. But old versions I kept only on my office box and a disk crash and later discovery that all backups were unreadable lost a lot of old stuff. I now have everything stored in three places, with a simple mechanism to scatter the duplicates to the right places after a change is made...
LucenaTheLucid wrote:I think since the since the Fruit->Rybka issue is basically agreed upon, then the next obvious thing would be to decide what exactly Ippo is? Then once Ippo is decided upon then possibly Houdini.
This is complex. Fruit is open source. R1 beta is not. The ip* was open source. And houdini is not. So every other hop in that suspected family of programs is a difficult one to deal with...
If you wuold rewrite crafty yourself assuming you don't get informed of newer developments where others profitted from:
You seriously underestimate the positive things that others have brought to you into crafty.
a) it would take 10 years
b) it would play 500 elo weaker at the same hardware
c) it would be 2x slower in nps
d) you would again have a testing problem as someone needs to write that code to automatically test. We are still awaiting the 'few scripts' that you use to automatically test crafty and modify its parameters with those scripts.
When you used to edit in crafty source code yourself, 2 bytes got changed, boom new version. No serious testing. Your current helpdesk moves forward so fast that others in CCC, such as Uri Blass, must explain to you, very painful, what the current crafty is actually doing.
Doing a simple compare of version 22.x with 23.x shows the huge number of changes done to crafty.
You wouldn't manage those changes yourself in a 100 years.
Vincent
Sorry, but 99.9% of the changes made in the past 10 years were done by me, and me alone.
then looking at the source code where starting from version 23, now the huge changes to the evaluation function show some typical mathematical personality, one that loves matrix calculations, someone who has no clue about chess; further some very atypical speedups here and there elsewhere in the code, done by someone who is more pragmatic than the devil. So 2 different programming styles got added to crafty 23+. 2 styles not seen before in the crafty coding.
Did your personality change recently Bob?
No, and there is no "matrix mathematical personality" involved. Just Tracy and myself. And I have already explained who has done what. If you want to ask about a specific piece of code, feel free and I can tell you exactly how it was derived.
The "pragmatic code" is certainly mine, however. I've only been doing optimization work for 40+ years now. And there is pragmatic code everywhere in Crafty, so I am not sure why you think there are three different people involved. There are only two and almost all of the code comes thru my fingers, the only exception being pieces of eval here and there that don't require any optimization work because they are straightforward to begin with.
So I do not know where you are getting your info. We didn't do any 2 byte = new version changes either. Each version represented either a significant change, or a bug fix of any time if it was deemed an important bug (mostly dealing with xboard protocol or perhaps in the early SMP days of Crafty, a significant SMP bug).
The only code changes Tracy has made were in the evaluation. Generally he tries different scores. Or new terms. Or new ways of computing old terms. If it looks promising, I end up looking at the code from a pure efficiency point of view and modifying it as needed to restore performance. The rest of the program (excluding just eval) has been solely my editing. And in the eval, we are probably 50-50 as to who changed what...
Your numbers are off by orders of magnitude...
bob wrote:
Dann Corbit wrote:
bob wrote:
Dann Corbit wrote:
Don wrote:
Houdini wrote:
Don wrote:I think you are correct. I personally AM a fan of rewrites but I think there are many chess authors that don't ever rewrite, or have only done so once in years.
Rewriting for the sake of rewriting doesn't serve any purpose at all.
Software with a good architecture will survive many years and many changes.
Robert
I don't rewrite just for the sake of it.
Don
Typical reasons for rewriting:
1. Change of language (e.g. C to C++)
2. Change of underlying data structures (e.g. mailbox to bitboard)
3. Increased programming ability (every decade, my programming skills increase quite a bit, so the code I wrote 20 years ago will benefit considerably from a rewrite).
4. Lost code (yes, it does happen -- I have sent code back to chess authors who lost their original code and who had also sent their code to me on several occasions, for instance).
I don't agree with those.
(1) can be solved via translation. A good program can be translated to a new language without rewriting a thing...
Basic to C++?
Pascal to Java?
Fortran to C?
I have seen the latter two. And Zortech used to sell the Fortran to C translator. I probably still have a copy in my office. I used it to make the original translation of the CB source to C back in 1994. The code was not very clean looking, because it was just a one-for-one translation to C. And since FORTRAN didn't have pointers in the f77 standard, the resulting C code did not use pointers. So it needed a lot of cleaning up to become "decent C". But the output of the translator would compile and run and produce identical results to the original FORTRAN program.
I think there is even a GNU fortran to C translator. I have not used it, but have noticed it in installing several different Linux distros. Something like f2c or something. But no info on how well it works...
(2) I did the mailbox-to-bitboard translation with Crafty. It only affects a part of the code. Search is unchanged. Move ordering is unchanged. Several other things are completely board representation independent.
Crafty is a giant machine with nearly 40K lines of code. At ten lines per hour and $100/hour that would translate to $400,000 worth of work. It would be a titanic effort, therefore, to rewrite crafty. Smaller programs of a few hundred lines would be far more likely candidates for such an effort.
I can't speak for everyone, but I produce a lot more than 10 lines per hour. Don't forget, half of those 40K + lines of code are simply comments that don't need translation, and also help in understanding... I would suspect it would take a year of solid work to rewrite Crafty from scratch, assuming I could access the comments but not the source instructions, to get it back to something close to the current state. Might take longer to get the speed back to where it is...
(3) I don't think is that common. One does not rewrite _everything_ just because they are a better programmer now than 10 years ago. you might rewrite _parts_. But not the whole thing. That is a huge waste of time and effort.
I have done it, but typically with small projects. TSCP needs a complete rewrite, for instance.
(4) Never had that happen to the current version of code since I always keep duplicates and backups scattered around.
It is the result of carelessness when code is lost, but it does happen. I suspect that you have lost at least one or more snapshot of a released version of Cray Blitz or Crafty (at least in the early stages) because with hobby projects that are not producing revenue we sometimes are not quite as careful as when a big pile of money is at stake.
I lost about 80% of everything in 1995. Not the current version as it is always kept in multiple locations such as my office box, my laptop, and a central NFS file server on top of that. But old versions I kept only on my office box and a disk crash and later discovery that all backups were unreadable lost a lot of old stuff. I now have everything stored in three places, with a simple mechanism to scatter the duplicates to the right places after a change is made...
