I expected this to be about Plankalkül or something devised by Babbage.
I was expecting a system like Leibniz notation, Boolean Algebra, Begriffsschrift, or the notation system in Principia Mathematica
Learning Fortran (2024)
11–20 of 85 posts
Re: Learning Fortran (2024)
#12This makes me feel old. I learned Fortran on the Dartmouth Time-Sharing System back in 1980. While I think of Fortran now and again and think about re-learning, I haven't thought of DTSS in years.
Re: Learning Fortran (2024)
#13Why not COBOL?
Re: Learning Fortran (2024)
#14Why not COBOL?
COBOL is some five years newer than Fortran. You could try FLOW-MATIC.
Re: Learning Fortran (2024)
#15I'm not sure one line of that would compile in FORTRAN 66, even if you indented it properly. Been so long I'm not sure...
Re: Learning Fortran (2024)
#16If you're interested in safer code when working with older versions of Fortran, add 'implicit none' at the top. This will eliminate the integer vs. float automatic assignment and make variable definition much tighter. Back when I mucked about with Fortran (previous century really), we tried to do the memory allocation and I/O in C and the compute in Fortran. That would play well with both superscalar and vector machi…
You didn’t read the article?
Re: Learning Fortran (2024)
#17Why not COBOL?
Plankalkül or bust.
Re: Learning Fortran (2024)
#18If you're interested in safer code when working with older versions of Fortran, add 'implicit none' at the top. This will eliminate the integer vs. float automatic assignment and make variable definition much tighter. Back when I mucked about with Fortran (previous century really), we tried to do the memory allocation and I/O in C and the compute in Fortran. That would play well with both superscalar and vector machi…
You didn’t read the article?
All of it, no. But I never used Fortran 90 yet used implicit none. Might have been an extension from SGI or a mini super but I recall using it.
Re: Learning Fortran (2024)
#19I actually had a fantastic experience with Fortran lately. I ported a compute kernel from python/numpy to Fortran 2018, partially due to the GIL and partly so I could use Intel's compiler. The performance improvement was tremendous. Several times faster per core, then multiplying further because I could take advantage of threading. In all, the 3 day project increased actual throughput 450x.
(I considered JAX, but the code in question was not amenable to a compute graph. Another option was to thread by fork, and use IPC.)
I liked the language itself more than expected. You have something like "generics" with tensors. Suppose you pass a parameter, N, and you also would like to pass a tensor, and you would like to specify the tensor's shape (N, N). You can do this; the parameter type constraints can reference other parameters.
Tensors and various operations are first-class types, so the compiler can optimise operations easily for the system you're building on. In my case, I got 80% improvement from ifx over gfortran.
Invocation from Python was basically the same as a C library. Both Python and Fortran have facilities for C interop, and Numpy can be asked to lay out tensors in a Fortran compatible way.
Part of what eased the port was that Numpy seems to be a kind of "Fortran wrapper". The ergonomics on tensor addressing, slicing and views is identical.
Re: Learning Fortran (2024)
#20The article did not discuss this, but to me, one of the bigger differences between Fortran and more modern languages is the difference between functions and subroutines. Yes, they are not synonyms in Fortran and serve different purposes. I think this would trip up more people initially than the clunky syntax. It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when…
Spaces don't matter in fixed-form Fortran source files, so I don't get that at all. And case doesn't matter in either source form.
Yes, sorry for the confusion. To be clear, the quote is directly about spaces not being significant in the source code in general, but I was commenting more about how this mindset affects variable names in practice. At least in my experience, many codes would benefit from variables names that use underscores.