Cray Blitz source (Carey)

[Carey]

I haven't gotten the source yet, and it may take a day or two after I get it before I post it (I may try running it through f2c, so I can provide a portable C version everybody can use), but I'll be sure and let people know when its ready.

Carey

If you do that (f2c) send me the result. I can probably come a _lot_ closer to making pondering and parallel search work there than I can with the FORTRAN limitations and differences across platforms.

Will do, but it may not be the next few days.

I'm still in the middle of debugging that other classic chess program. I've been at it for weeks and have made so little progress. I want to get this done as soon as I can so I don't have to look at it anymore. (I know how bad that sounds, but the reality is I'm just tired of debugging.)

This can't be the version that was used in tournaments. There had to be some 'minor' changes that's causing all these problems.

I might have made a breakthrough though.... The last two days it's played a lot of automatic games and there haven't been any errors like before. Even many of the built in warning messages haven't shown up.... But it might still not be making the right moves.

For the early versions (#1 played its first move in 1968 by the way) the "renumbering" only happened on major changes. 1-5 were very selective. version 6 was patterned after chess 4.x with a full-width search and such.

Thanks for the info. I remember seeing in Blitz 6.9 source that it had been selective search but I didn't know when it had been switched over.


So I guess it's safe to say that the final version of CrayBlitz can be traced all the way back to 1968.... That's a long time for a chess program.

Later Harry went ape-sh** with versions and every last change, even one line, got a new version number with him. It was good for record-keeping, but led to a _lot_ of versions. We started numbering them cray blitz AAD

I guess he wasn't a believer in DIFF's then. Short of a real versioning control system, they are great for easily extracting minor changes so you can easily keep track of what's being done.

where AA was a 2 digit version number that was incremented when something "interesting" was done (any change that affected a hundred lines or more or something similar). the "D" was a single letter that was incremented on any change of any kind, so that we always had all older versions at hand.

According to my paper file, we got as far as 59p by the end of 1994 when we stopped working on it. The version here is 49h. Looks like 49j played in the ACM that year for reference, but none of those more recent versions exist.

The paper versions you sent me were 43g and 47a.

It's possible that just maybe there are enough similaries between those and this 49h version that we could recreate working versions of those older ones.

The big problems with those were the poor OCR that was done. Even when looking at a blow-up of the page scans, it was still often impossible to tell the difference between ell and one, oh and zero, etc.

version 52 started the singular extension versions and I'd love to have that back just to study as it was complicated and I might be convinced to try that again if I had the old code to look at, but barring yet another miracle, that won't happen...

At least you have some versions of your old programs.

A lot of authors can't say that....

[bob]

I haven't gotten the source yet, and it may take a day or two after I get it before I post it (I may try running it through f2c, so I can provide a portable C version everybody can use), but I'll be sure and let people know when its ready.

Carey

If you do that (f2c) send me the result. I can probably come a _lot_ closer to making pondering and parallel search work there than I can with the FORTRAN limitations and differences across platforms.

Will do, but it may not be the next few days.

I'm still in the middle of debugging that other classic chess program. I've been at it for weeks and have made so little progress. I want to get this done as soon as I can so I don't have to look at it anymore. (I know how bad that sounds, but the reality is I'm just tired of debugging.)

This can't be the version that was used in tournaments. There had to be some 'minor' changes that's causing all these problems.

I might have made a breakthrough though.... The last two days it's played a lot of automatic games and there haven't been any errors like before. Even many of the built in warning messages haven't shown up.... But it might still not be making the right moves.

For the early versions (#1 played its first move in 1968 by the way) the "renumbering" only happened on major changes. 1-5 were very selective. version 6 was patterned after chess 4.x with a full-width search and such.

Thanks for the info. I remember seeing in Blitz 6.9 source that it had been selective search but I didn't know when it had been switched over.


So I guess it's safe to say that the final version of CrayBlitz can be traced all the way back to 1968.... That's a long time for a chess program.

Later Harry went ape-sh** with versions and every last change, even one line, got a new version number with him. It was good for record-keeping, but led to a _lot_ of versions. We started numbering them cray blitz AAD

I guess he wasn't a believer in DIFF's then. Short of a real versioning control system, they are great for easily extracting minor changes so you can easily keep track of what's being done.

where AA was a 2 digit version number that was incremented when something "interesting" was done (any change that affected a hundred lines or more or something similar). the "D" was a single letter that was incremented on any change of any kind, so that we always had all older versions at hand.

According to my paper file, we got as far as 59p by the end of 1994 when we stopped working on it. The version here is 49h. Looks like 49j played in the ACM that year for reference, but none of those more recent versions exist.

The paper versions you sent me were 43g and 47a.

It's possible that just maybe there are enough similaries between those and this 49h version that we could recreate working versions of those older ones.

The big problems with those were the poor OCR that was done. Even when looking at a blow-up of the page scans, it was still often impossible to tell the difference between ell and one, oh and zero, etc.

version 52 started the singular extension versions and I'd love to have that back just to study as it was complicated and I might be convinced to try that again if I had the old code to look at, but barring yet another miracle, that won't happen...

At least you have some versions of your old programs.

A lot of authors can't say that....

I did not realize that the hard copy was older. Those might be interesting to compare against the 1991 version I have put on the ftp box, but anything coming thru OCR is pretty hopeless as far as actually getting it to run. I've tried in the past.

Also I am not sure there is a lot of benefit in resurrecting the older version since this is later than either of those printouts. 6.9 was very small, around 10K lines. Version 5 was over 100K lines with all the selective stuff it did.

[Carey]

I did not realize that the hard copy was older. Those might be interesting to compare against the 1991 version I have put on the ftp box, but anything coming thru OCR is pretty hopeless as far as actually getting it to run. I've tried in the past.

Yeah, but the key here is that the odds are good there are only a few hundred lines different between the hard copy versions and the electronic version which does compile & run. (Under 1000 lines, I'd bet.)

Way back then I compared the two hardcopy versions and the vast majority of them were the same. In fact, that's how I did some text checking was by comparing the two to see what was different.

If nothing else, when I get time, I can at least put the OCR'ed copies online with a clear warning they aren't usable. That way people could at least see the general structure.

Also I am not sure there is a lot of benefit in resurrecting the older version since this is later than either of those printouts. 6.9 was very small, around 10K lines.

Blitz 6.9 was fairly small. It was hard to scan & OCR though due to the age & the colored paper. And that logo in the center sure didn't help!

As to the benefit... I don't know... Admittedly there's nothing special about Blitz 6.9 itself. A not untypical brute force program of the time. But there aren't many programs left from the 70s.

Realistically, it's just because it is an ancestor of CrayBlitz. Who knows, now Blitz 6.9 might be stronger than CrayBlitz because of the vector stuff running so poorly on modern processors....

Version 5 was over 100K lines with all the selective stuff it did.

I can imagine. It takes a lot of effort to be try and be smart enough to be selective enough to avoid the major blunders.

[Zach Wegner]

Damn, this is harder than I thought. I've been fiddling around with g77 and f2c for a while, but neither worked. The f2c option seems closer to working. I will warn you though that the f2c output is _hideous_, so I wouldn't bet on the C version being any easier to get to work. I think most library calls aren't translated to C anyways, but rather handled by a library.

Anyways, for f2c, it appears that there are a bunch of library functions missing, as the linker goes crazy with undefined reference errors like these:

Code: Select all

asyncio.c:(.text+0xa): undefined reference to `s_rsfe'
asyncio.c:(.text+0x1e): undefined reference to `do_fio'
asyncio.c:(.text+0x23): undefined reference to `e_rsfe'
asyncio.c:(.text+0x44): undefined reference to `s_stop

Right now I'm going to try out the Intel fortran compiler. I don't have Linux, but I hope my Linux emulation is up to the task...

[Carey]

Damn, this is harder than I thought. I've been fiddling around with g77 and f2c for a while, but neither worked. The f2c option seems closer to working.

Thanks for making an effort on this... Better you than me!

I had some idea how much time it'd take, which is why I told him it'd be at least a couple days before I could even try.

I will warn you though that the f2c output is _hideous_, so I wouldn't bet on the C version being any easier to get to work. I think most library calls aren't translated to C anyways, but rather handled by a library.

I've seen the kind of output f2c produces. Along with Pascal to C converters and other '-to-c' converters.

Hideous is definetly the right word.

Anyways, for f2c, it appears that there are a bunch of library functions missing, as the linker goes crazy with undefined reference errors like these:

Code: Select all

asyncio.c:(.text+0xa): undefined reference to `s_rsfe'
asyncio.c:(.text+0x1e): undefined reference to `do_fio'
asyncio.c:(.text+0x23): undefined reference to `e_rsfe'
asyncio.c:(.text+0x44): undefined reference to `s_stop

Right now I'm going to try out the Intel fortran compiler. I don't have Linux, but I hope my Linux emulation is up to the task...

Hmmm.... Odd.

I would certainly expect it to include all the library files it'd need. Maybe the current build has some Windows issues.

[Dann Corbit]

Damn, this is harder than I thought. I've been fiddling around with g77 and f2c for a while, but neither worked. The f2c option seems closer to working.

Thanks for making an effort on this... Better you than me!

I had some idea how much time it'd take, which is why I told him it'd be at least a couple days before I could even try.

I will warn you though that the f2c output is _hideous_, so I wouldn't bet on the C version being any easier to get to work. I think most library calls aren't translated to C anyways, but rather handled by a library.

I've seen the kind of output f2c produces. Along with Pascal to C converters and other '-to-c' converters.

Hideous is definetly the right word.

Anyways, for f2c, it appears that there are a bunch of library functions missing, as the linker goes crazy with undefined reference errors like these:

Code: Select all

asyncio.c:(.text+0xa): undefined reference to `s_rsfe'
asyncio.c:(.text+0x1e): undefined reference to `do_fio'
asyncio.c:(.text+0x23): undefined reference to `e_rsfe'
asyncio.c:(.text+0x44): undefined reference to `s_stop

Right now I'm going to try out the Intel fortran compiler. I don't have Linux, but I hope my Linux emulation is up to the task...

Hmmm.... Odd.

I would certainly expect it to include all the library files it'd need. Maybe the current build has some Windows issues.

F2c needs the Fortran I/O libraries.
You get it here:
http://www.netlib.org/f2c/
Get file http://www.netlib.org/f2c/libf2c.zip
Don't just get the binaries because you might want to do 64 bit builds and the binaries only have 32 bit libraries.

[sje]

I will try to get both that and my dissertation scanned. My dissertation was written using "interleaf" and before I knew it, the electronic version was unusable due to changes to interleaf over the years. Be nice to have that back in a text form as well...

There's a lot to be said for plain ASCII text.

Perhaps today's students are using HTML for their papers. There's so much communal inertia in the basic HTML text and diagram features that I expect the format to be readable a half century from now.

PDF is another format that I expect to have a long life. It's certainly taken hold in the Mac community and also with Linux users. It's the standard export format for material produced with Pages; that's the semi-pro document processor application on the Macintosh. I use it when I have to have embedded tables or images.

In earlier days, and there were many of these earlier days before mice and bitmapped displays, I used good old Emacs and nroff/troff.

[bob]

I did not realize that the hard copy was older. Those might be interesting to compare against the 1991 version I have put on the ftp box, but anything coming thru OCR is pretty hopeless as far as actually getting it to run. I've tried in the past.

Yeah, but the key here is that the odds are good there are only a few hundred lines different between the hard copy versions and the electronic version which does compile & run. (Under 1000 lines, I'd bet.)

Way back then I compared the two hardcopy versions and the vast majority of them were the same. In fact, that's how I did some text checking was by comparing the two to see what was different.

If nothing else, when I get time, I can at least put the OCR'ed copies online with a clear warning they aren't usable. That way people could at least see the general structure.

Also I am not sure there is a lot of benefit in resurrecting the older version since this is later than either of those printouts. 6.9 was very small, around 10K lines.

Blitz 6.9 was fairly small. It was hard to scan & OCR though due to the age & the colored paper. And that logo in the center sure didn't help!

As to the benefit... I don't know... Admittedly there's nothing special about Blitz 6.9 itself. A not untypical brute force program of the time. But there aren't many programs left from the 70s.

Realistically, it's just because it is an ancestor of CrayBlitz. Who knows, now Blitz 6.9 might be stronger than CrayBlitz because of the vector stuff running so poorly on modern processors....

It is a world apart from Cray Blitz. No null-move. Minimal search extensions. Etc. But it would be interesting to get it running as it was very "vanilla fortran" to say the least...

Version 5 was over 100K lines with all the selective stuff it did.

I can imagine. It takes a lot of effort to be try and be smart enough to be selective enough to avoid the major blunders.

[bob]

Damn, this is harder than I thought. I've been fiddling around with g77 and f2c for a while, but neither worked. The f2c option seems closer to working.

Thanks for making an effort on this... Better you than me!

I had some idea how much time it'd take, which is why I told him it'd be at least a couple days before I could even try.

I will warn you though that the f2c output is _hideous_, so I wouldn't bet on the C version being any easier to get to work. I think most library calls aren't translated to C anyways, but rather handled by a library.

I've seen the kind of output f2c produces. Along with Pascal to C converters and other '-to-c' converters.

Hideous is definetly the right word.

Anyways, for f2c, it appears that there are a bunch of library functions missing, as the linker goes crazy with undefined reference errors like these:

Code: Select all

asyncio.c:(.text+0xa): undefined reference to `s_rsfe'
asyncio.c:(.text+0x1e): undefined reference to `do_fio'
asyncio.c:(.text+0x23): undefined reference to `e_rsfe'
asyncio.c:(.text+0x44): undefined reference to `s_stop

Right now I'm going to try out the Intel fortran compiler. I don't have Linux, but I hope my Linux emulation is up to the task...

Hmmm.... Odd.

I would certainly expect it to include all the library files it'd need. Maybe the current build has some Windows issues.

back in the early 90's, I bought a commercial fortran-to-c translator. I think made by Zortech. But it produced code so damned ugly, and it kept all the "fortranisms" such as array subscripts starting at 1, wasting an array element, and such, that I decided to forget the whole thing. By then Cray had a good C compiler (probably not as good at optimizing as the Cray fortran compiler (but then again, _nobody_ has ever beaten that compiler to my knowledge) and I wanted something more portable with respect to dymamic memory allocation, multiple threads, and such...

[bob]

Damn, this is harder than I thought. I've been fiddling around with g77 and f2c for a while, but neither worked. The f2c option seems closer to working.

Thanks for making an effort on this... Better you than me!

I had some idea how much time it'd take, which is why I told him it'd be at least a couple days before I could even try.

I will warn you though that the f2c output is _hideous_, so I wouldn't bet on the C version being any easier to get to work. I think most library calls aren't translated to C anyways, but rather handled by a library.

I've seen the kind of output f2c produces. Along with Pascal to C converters and other '-to-c' converters.

Hideous is definetly the right word.

Anyways, for f2c, it appears that there are a bunch of library functions missing, as the linker goes crazy with undefined reference errors like these:

Code: Select all

asyncio.c:(.text+0xa): undefined reference to `s_rsfe'
asyncio.c:(.text+0x1e): undefined reference to `do_fio'
asyncio.c:(.text+0x23): undefined reference to `e_rsfe'
asyncio.c:(.text+0x44): undefined reference to `s_stop

Right now I'm going to try out the Intel fortran compiler. I don't have Linux, but I hope my Linux emulation is up to the task...

Hmmm.... Odd.

I would certainly expect it to include all the library files it'd need. Maybe the current build has some Windows issues.

F2c needs the Fortran I/O libraries.
You get it here:
http://www.netlib.org/f2c/
Get file http://www.netlib.org/f2c/libf2c.zip
Don't just get the binaries because you might want to do 64 bit builds and the binaries only have 32 bit libraries.

The main issue is that the internal assumption is that integer == 64 bits. If the compiler can deal with that in a 32 bit machine, it will work. Otherwise, this will be a problem. The intel C compiler for linux is free and works just fine, and the included make file will compile cleanly...