31 bit hash values. How often will it fail?

[Carey]

From time to time I've seen complete Cray machines with software up for sale on ebay.

Really? I've never looked.

I wouldn't want the whole thing, but I wouldn't mind having a couple pieces of one to use as book-ends etc.

A couple boards from an original Cray-1 or Cray-2...

The prices are unbelievably low, perhaps a thousandth of the original cost.

Well, considering the cost of shipping it to your front door....

And just try to plug that thing into your regular wall outlet...

Even if you somehow manage to get it running, the electrical cost will make you wish you hadn't.

The circular chair model sees to be popular. But where would one get the Freon needed for cooling?

There is (or was) at least one commercial Cray production class emulator available for the Apple Macintosh.

I don't know if there still is. Might be fun.

But CrayBlitz doesn't need it. Although much of it was in CAL (Cray Assembler Language), Bob always kept a plain FORTRAN version so he could do testing etc. on a VAX or whatever else system he had handy.


Also, a couple years ago, I think there was a place on the web where you could actually borrow time on a real Cray. Just for fun stuff for regular people. You didn't have to be a student etc.

I think it was something like once a week they'd power up an old Cray or other system and let people run programs on it.

I stumbled upon that site a couple years ago when Bob first sent me the listing printouts for Blitz & CrayBlitz.

If that place still exists, you might be able to get CrayBlitz running on there long enough to get a few benchmark numbers to satisfy people's comparisons to a regular PC.

Or Bob could supply those numbers already.... But that wouldn't be as much fun.

[bob]

woohoo... a breakthrough. Someone had emailed me a question about an old position from some Cray Blitz game and I was looking thru my chess problem file (a paper file, not disk) and lo ahd behold, I found a print-out of the book code. I will work on getting this entered and maybe we can release a complete functional version of 1991-era Cray Blitz. I will have to figure out if "define file(...)" is in the unix fortran, and if not, make some changes, but it ought to be workable with a little poking around...

More later...

EXCELLENT!!

If this version isn't too different from the other two (paper copies) you sent me, we might even be able to recreate those as well.

If the differences are too great, we can at least release the OCR'ed text and the jpg scans.

Carey


P.S.... Maybe you ought to poke around your paper archives a little more....?

Before, you managed to find a copy of Blitz and two copies of CrayBlitz that you thought had been lost. Now another part of CrayBlitz... Who knows, you might still have more stuff that you forgot about or thought was lost....

Maybe hidden in some box in your office or basement might even be the last surviving copy of the source for MacHack VI, Chess 3.6, Kotok-McCarthy and even the location of where Elvis & Jimmy Hoffa are hiding...

OK, status update.

1. I downloaded the intel fortran compiler (free for non-commercial linux). Bam, define file() works perfectly.

2. I have corrected some constants that were a problem in that on the cray, a constant like 1777b is a octal (why b?) constant. Correct in general is O1777 whre the O is Oh and not zero.

3. I am not going to worry with the parallel search stuff. That is somewhat problematic in that the cray had a special type of common (task common) that was local to each process, and our lock/unlock had to be done in cray assembler. I am going to leave all the code in place so it will be complete, but I am going to comment the lock/unlock calls out and leave that to someone that wants to get a multi-cpu version working...

I have now gotten a clean compile, and discovered all the lock calls that were bad, once I get those, it "might" run. More in a bit...

[sje]

1. I downloaded the intel fortran compiler (free for non-commercial linux). Bam, define file() works perfectly.

2. I have corrected some constants that were a problem in that on the cray, a constant like 1777b is a octal (why b?) constant. Correct in general is O1777 whre the O is Oh and not zero.

Let's see, your "file()" is a Fortran statement function, right? They looked exactly like assignment statements but were really a whole function definition on a single line, like "DEF FN*" in Basic. And in Fortran they only worked if they appeared before any non-specification statements in a routine. Gosh, I used to teach that stuff long ago.

The "B" suffix comes from the early CDC days and it was used in Compass. "O" for octal wasn't used in part because of: the confusion between "O" and "0", the usually crummy line printer output at CDC installations, and the fact that there were no lowercase characters in the CDC six bit display code character set.

[bob]

woohoo... a breakthrough. Someone had emailed me a question about an old position from some Cray Blitz game and I was looking thru my chess problem file (a paper file, not disk) and lo ahd behold, I found a print-out of the book code. I will work on getting this entered and maybe we can release a complete functional version of 1991-era Cray Blitz. I will have to figure out if "define file(...)" is in the unix fortran, and if not, make some changes, but it ought to be workable with a little poking around...

More later...

EXCELLENT!!

If this version isn't too different from the other two (paper copies) you sent me, we might even be able to recreate those as well.

If the differences are too great, we can at least release the OCR'ed text and the jpg scans.

Carey


P.S.... Maybe you ought to poke around your paper archives a little more....?

Before, you managed to find a copy of Blitz and two copies of CrayBlitz that you thought had been lost. Now another part of CrayBlitz... Who knows, you might still have more stuff that you forgot about or thought was lost....

Maybe hidden in some box in your office or basement might even be the last surviving copy of the source for MacHack VI, Chess 3.6, Kotok-McCarthy and even the location of where Elvis & Jimmy Hoffa are hiding...

This has been a pain, but I have something that barely works. No book (yet) and am working on measuring the time so that the search will function. I am not yet sure about pondering and that might take some twiddling. So maybe you will have a 1991-version of CB source that will actually compile and run soon enough...

[bob]

1. I downloaded the intel fortran compiler (free for non-commercial linux). Bam, define file() works perfectly.

2. I have corrected some constants that were a problem in that on the cray, a constant like 1777b is a octal (why b?) constant. Correct in general is O1777 whre the O is Oh and not zero.

Let's see, your "file()" is a Fortran statement function, right? They looked exactly like assignment statements but were really a whole function definition on a single line, like "DEF FN*" in Basic. And in Fortran they only worked if they appeared before any non-specification statements in a routine. Gosh, I used to teach that stuff long ago.

The "B" suffix comes from the early CDC days and it was used in Compass. "O" for octal wasn't used in part because of: the confusion between "O" and "0", the usually crummy line printer output at CDC installations, and the fact that there were no lowercase characters in the CDC six bit display code character set.

Actually it works just fine. It is define file (x,y,z,p) type definition. Had to do some work on the constants. O (oh) did not quite work. but o'octal-numbers' seems to work just fine so the bitboard attack detection now functions and doesn't think every move is a check.

Be interesting to see how this runs on my 64 bit laptop... it was written to vectorize on a Cray, so it is not going to be very fast on a PC unfortunately...

[sje]

Was Cray Fortran able to handle recursive routines? I ask because old CDC Fortran certainly couldn't.

The CDC architecture used an RJ (return jump) instruction to return from a routine. This instruction wasn't usually coded by a programmer; instead it was jammed into the starting address of a routine at run time by the call instruction! To return, the programmer instead coded a jump to the start of the routine. Yes, this was awful. And so no recursion with the standard calling sequence. This explains why recursion was not used in the Fortran versions of the early CDC based chess programs. It may also explain why the Chess 0.5 program, although coded in Pascal, didn't use recursion either although the language supported such -- it was too easy to copy the search from the earlier versions.

[bob]

Was Cray Fortran able to handle recursive routines? I ask because old CDC Fortran certainly couldn't.

The CDC architecture used an RJ (return jump) instruction to return from a routine. This instruction wasn't usually coded by a programmer; instead it was jammed into the starting address of a routine at run time by the call instruction! To return, the programmer instead coded a jump to the start of the routine. Yes, this was awful. And so no recursion with the standard calling sequence. This explains why recursion was not used in the Fortran versions of the early CDC based chess programs. It may also explain why the Chess 0.5 program, although coded in Pascal, didn't use recursion either although the language supported such -- it was too easy to copy the search from the earlier versions.

Early CFT's could not handle recursion. Since blitz was started in 1968, on an IBM /360 using fortran-e and then fortran-g, recursion was not an option. Eventually cft supported recursion, but that was _way_ after this was completed. I'd guess early 80's as I think fortran-77 was the first to specify this.

[sje]

I'm somewhat amazed that there is still Fortran programming. It's also a surprise of sorts to note that there are efforts to "modernize" the language every five years or so. It seems some people want to make it more and more like C/C++.

Why don't they just switch to C/C++ and save time and trouble? Probably because there's too much old Fortran source that's too cryptic to re-write.

Trying to fix Fortran is like using a trowel to apply make-up to a seventy year old hooker. Nice effort, but not justified by any likely outcome.

[michiguel]

I'm somewhat amazed that there is still Fortran programming. It's also a surprise of sorts to note that there are efforts to "modernize" the language every five years or so. It seems some people want to make it more and more like C/C++.

Why don't they just switch to C/C++ and save time and trouble? Probably because there's too much old Fortran source that's too cryptic to re-write.

Trying to fix Fortran is like using a trowel to apply make-up to a seventy year old hooker. Nice effort, but not justified by any likely outcome.

Many (Most?) computational chemists use FORTRAN _today_. Two researchers in our department use exclusively FORTRAN. Few months ago, someone from another good University (Northwestern?) gave a lecture and pride himself that he did not allow a graduate student to program in C++ and force him to do the job in FORTRAN. "That is the way to do it". I found the comment a bit extreme, but... hey, I am just a pragmatic experimentalist (programming is my hobby). Many times, this is almost like a fundamentalist argument, so I try to stay away from it. Are there not good numerical libraries in C++ that can replace the old myth that number crunching should be done in FORTRAN?

Miguel

[Dann Corbit]

I'm somewhat amazed that there is still Fortran programming. It's also a surprise of sorts to note that there are efforts to "modernize" the language every five years or so. It seems some people want to make it more and more like C/C++.

Why don't they just switch to C/C++ and save time and trouble? Probably because there's too much old Fortran source that's too cryptic to re-write.

Trying to fix Fortran is like using a trowel to apply make-up to a seventy year old hooker. Nice effort, but not justified by any likely outcome.

Many (Most?) computational chemists use FORTRAN _today_. Two researchers in our department use exclusively FORTRAN. Few months ago, someone from another good University (Northwestern?) gave a lecture and pride himself that he did not allow a graduate student to program in C++ and force him to do the job in FORTRAN. "That is the way to do it". I found the comment a bit extreme, but... hey, I am just a pragmatic experimentalist (programming is my hobby). Many times, this is almost like a fundamentalist argument, so I try to stay away from it. Are there not good numerical libraries in C++ that can replace the old myth that number crunching should be done in FORTRAN?

Miguel

There are clear advantages for both Fortran and C++.
In C++ you have templates, which allow inlining in a way that library calls cannot.
In Fortran you do not have to worry about aliasing and so the optimizer can do a better job.
Modern Fortran is an OO language, just like C++.


In reality, most major number crunching fascilities use a mixture of C, C++ and Fortran today.
See (for instance) NCAR
http://ngwww.ucar.edu/
Here is something used to paste modules together:
https://computation.llnl.gov/casc/award ... rd100.html

Various debates:
http://ubiety.uwaterloo.ca/~tveldhui/pa ... obbs2.html
http://heim.ifi.uio.no/~xingca/tpv_research/Scripting/
http://www.soton.ac.uk/~fangohr/randomn ... 2007_2.pdf