31 bit hash values. How often will it fail?

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Fortran

Post by bob »

Dann Corbit wrote:
michiguel wrote:
sje wrote: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
actually aliasing is still a problem. F90 added pointers, which introduce messiness.
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Fortran

Post by sje »

bob wrote:actually aliasing is still a problem. F90 added pointers, which introduce messiness.
Oh, there was already plenty of messiness. Like the EQUIVALENCE declaration, for one example.

And also:

Code: Select all

      SUBROUTINE MODLIT(I, J)
      J = I*I
      RETURN

      PROGRAM MAIN
      CALL MODLIT(3, 4)
      WRITE (5, 100) 4
  100 FORMAT(5H 4 = I5)
      CALL EXIT
      END
Which on more than one system will print:

Code: Select all

4 = 6
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Fortran

Post by bob »

sje wrote:
bob wrote:actually aliasing is still a problem. F90 added pointers, which introduce messiness.
Oh, there was already plenty of messiness. Like the EQUIVALENCE declaration, for one example.

And also:

Code: Select all

      SUBROUTINE MODLIT(I, J)
      J = I*I
      RETURN

      PROGRAM MAIN
      CALL MODLIT(3, 4)
      WRITE (5, 100) 4
  100 FORMAT(5H 4 = I5)
      CALL EXIT
      END
Which on more than one system will print:

Code: Select all

4 = 6
Right. Or the more common:
x=8
call sub(4)
x=x/4
print 100, x
100 format(1x,"x=",i4)
stop
end

subroutine sub(i)
i=2
return
end

and when you run that you get 4 for the answer, because the constant "4" was turned into a "2" by the subroutine call. More commonly i was set to zero and the program would crash and students could not figure out how x=x/4 could get a "divide-by-zero" error.

The good old days.
User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 7:43 pm

Re: Fortran

Post by sje »

bob wrote:Right. Or the more common:
x=8
call sub(4)
x=x/4
print 100, x
100 format(1x,"x=",i4)
stop
end

subroutine sub(i)
i=2
return
end

and when you run that you get 4 for the answer, because the constant "4" was turned into a "2" by the subroutine call. More commonly i was set to zero and the program would crash and students could not figure out how x=x/4 could get a "divide-by-zero" error.

The good old days.
On a CDC it was even worse, as the there was no run time exception generated for division by zero. Instead, there was a calculation exception raised when the result of a division by zero was used in a later calculation. When that later calculation was many pages and many cycles separated from the division, it could be tough to find.

A similar and more common problem on the CDC occurred when using an uninitialized scalar. This was a big pain in a language that didn't require declaration of variables.

That lack of a declaration requirement was seen as a beneficial feature by some. It's also why the Venus-bound Mariner 1 spacecraft is currently resting at the bottom of the Atlantic Ocean.

I regret that I used to teach this stuff no matter how long ago it was.