4 ms·

I’ve done computational physics and used Fortran. There are some warts, like line length requirements. But for actual math, Fortran takes the cake

milancurcic 3y ago
And the line length limit will soon (with Fortran 2023 later this year) practically go away--a hard limit of 10,000 characters.
- pklausler 3y ago
  Changes to the standard don't instantly, or even eventually, cause corresponding changes in implementations. Code that needs to be portable to many implementations will need to worry about line length limits for a long time into the future. The Venn diagram of Fortran feature availability in the various actively maintained Fortran compilers is very messy, and the ISO standard is definitely not a subset of any of them. Standard-conforming code is not necessarily portable, and highly portable code is not necessarily standard-conforming, especially since Fortran '95.
- TheRealKing 3y ago
  The hard line limit length is at 1,000,000 characters not 10,000. Also, all major compilers currently have flags to significantly extend the line limit length.
  - milancurcic 3y ago
    You're correct about the compiler flags. 10K will be the line length limit; the 1M limit is for a statement length that can span any number of lines.
waveBidder 3y ago
having used both FORTRAN and Julia, Julia generally had less friction and comparable speed. JIT is great for having a very short programming loop. I definitely prefer Fortran to Python though for math programming.
- noobermin 3y ago
  The insistence of using dot operators for nonsensical purity ruined julia for me. A good example of computer scientists ruining things.
  - kstrauser 3y ago
    Can you give an example? I haven’t used Julia and I’m curious to hear what you mean by that.
    - porridgeraisin 3y ago
      Normally, languages implement SIMD compilation for a specific set of data types/structures and even then you have to really make sure to ask the compiler nicely. Julia is able to vectorize any generic, user-defined data types/operators/functions. This comes at the cost of pretty horrid syntax. It needs extra syntax to give the compiler the information, for sure, but you can argue that it could have been chosen better. X .= f.(2 .* X.^2 .+ 6 .* X.^3 .- sqrt.(X))
      - kwertzzz 3y ago
        Or just use @. julia> X = [1.,2.,3.]; f=sin; julia> @. X = f(2 * X^2 + 6 * X^3 - sqrt(X))
    - noobermin 3y ago
      In fortran 90, an example I have sitting around: c_y = (qmr*ey_sub*dtsq + c_y*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1*gminv ey_sub, c_y, c_ym1 are N long arrays with the same shape, and in this case, the operation is elementwise, so indexing isn't needed, and I do not need an explicit do-loop (for loop in C languages) so it fits on a single line that is readable to a scientist in the field. The julia equivalent, I think is the same with a period on every operator c_y .= (qmr.*ey_sub.*dtsq .+ c_y.*(2 .- omsq_b.*dtsq))./gmdto2p1 .- c_ym1.*gminv The assignment was already verbose as it is, and I at the time tried to make it terser but still marginally readable by using variables that are named for...scientists I guess (e.g., gmdto2p1 means "gamma * dt / 2 + 1" dto2 thoughout the codes I read and use is "dt over 2") and adding 10 characters makes a little more cumbersome. While I think the visuals can be acclimated to, it is tedious to write, especially when you translate a formula from vectorised form to non vectorised or vice-versa and have to insert or delete periods. Mind you this is one of the simpler formulae in the code in question. You can imagine it quickly gets worse when the number of terms exceeds 6 or so. If you can't rely on implicit-do or terse assignment statements, then the good alternative in terms of readability then for the formula is just to do an explicit do-loop (for loop for julia). ! fortran 90, `integer i` above do i=1,size(c_y) c_y(i) = (qmr*ey_sub(i)*dtsq + c_y(i)*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1(i)*gminv end do # julia for i=1:length(c_y) c_y[i] = (qmr*ey_sub[i]*dtsq + c_y[i]*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1[i]*gminv end The problem is then I have made more extraneous bits to worry about. This gets even more hard to parse when the shape of the arrays exceeds more than 3 dimensions. I've read C style codes that are 7 levels deep with different indices, god is it painfully unclear and easy to get lost reading that, it's best to hide extraneous loops with syntactical sugar where possible such as to keep the algorithm as clear as possible, especially when it's a simple elementwise operation. It isn't like you can hide complexity all the time (or that it's even a good idea to do so), but this was a code for just two figures in a paper that needed a bit more oomf than numpy could, so given the time constraint for me, the size of the problem and everything, fortran fit much better. If you want to know more about the dot macro in julia, here is a nice blogpost about them[0]. The line above is from work I did for a paper that I initially thought "hey, it's been a few years, why not see if julia has stabilised by now" only to find out this was a decisive change they made. I mean they might deserve praise having made this macro a very general thing and apply widely to things that aren't just syntactical sugar for broadcasting, but after being frustrated trying to write my code, googling, and then finding this post, I basically dropped the julia learning effort and got the code written in fortran and made my figures. I can learn things in my spare time to a limit but at the end of the day I have a job to do. I still want to give julia a chance because the idea does seem cool. I complain about computer scientists a little tongue-in-cheek but really I find the metaprogramming in julia pretty interesting. I'm just not sure I can use it in my day job as a scientist without some effort in learning and time on my part which is at a premium right now. [0] https://julialang.org/blog/2017/01/moredots/ https://julialang.org/blog/2017/01/moredots/
noobermin 3y ago
I once noticed the thing is people balk at the line length in fortran as if it is some archaic hold off (which it is somewhat) that proves its obsolescence but in the next breath berate everyone for not using a formatter that will chunk lines into 100 characters in their favorite "modern" language. I guess the problem is fortran chose 80 as the line length and not 100.
- Koshkin 3y ago
  > as if it is some archaic hold off (which it is somewhat) Indeed it is! The standard IBM punch card had 80 columns. > and not 100 The standard IBM printer models had 120 print positions.
- pklausler 3y ago
  It is 80 for "fixed form" (card image) source files. It is 132 for free form modern source, but adjustable on the compiler command line. LLVM Flang uses the line length only for emitting optional portability warnings.
- dboreham 3y ago
  100?? Obviously 132 is the correct line length.
- actinium226 3y ago
  But mah punch cards!
queuebert 3y ago
As weird as it may sound, I prefer the old fixed-form source with continuation characters and mandated 7-character indent. Like Python, it made for consistent code formatting across people and libraries.

milancurcic 3y ago

And the line length limit will soon (with Fortran 2023 later this year) practically go away--a hard limit of 10,000 characters.

pklausler 3y ago
Changes to the standard don't instantly, or even eventually, cause corresponding changes in implementations. Code that needs to be portable to many implementations will need to worry about line length limits for a long time into the future. The Venn diagram of Fortran feature availability in the various actively maintained Fortran compilers is very messy, and the ISO standard is definitely not a subset of any of them. Standard-conforming code is not necessarily portable, and highly portable code is not necessarily standard-conforming, especially since Fortran '95.
TheRealKing 3y ago
The hard line limit length is at 1,000,000 characters not 10,000. Also, all major compilers currently have flags to significantly extend the line limit length.
- milancurcic 3y ago
  You're correct about the compiler flags. 10K will be the line length limit; the 1M limit is for a statement length that can span any number of lines.

waveBidder 3y ago

having used both FORTRAN and Julia, Julia generally had less friction and comparable speed. JIT is great for having a very short programming loop. I definitely prefer Fortran to Python though for math programming.

noobermin 3y ago
The insistence of using dot operators for nonsensical purity ruined julia for me. A good example of computer scientists ruining things.
- kstrauser 3y ago
  Can you give an example? I haven’t used Julia and I’m curious to hear what you mean by that.
  - porridgeraisin 3y ago
    Normally, languages implement SIMD compilation for a specific set of data types/structures and even then you have to really make sure to ask the compiler nicely. Julia is able to vectorize any generic, user-defined data types/operators/functions. This comes at the cost of pretty horrid syntax. It needs extra syntax to give the compiler the information, for sure, but you can argue that it could have been chosen better. X .= f.(2 .* X.^2 .+ 6 .* X.^3 .- sqrt.(X))
    - kwertzzz 3y ago
      Or just use @. julia> X = [1.,2.,3.]; f=sin; julia> @. X = f(2 * X^2 + 6 * X^3 - sqrt(X))
  - noobermin 3y ago
    In fortran 90, an example I have sitting around: c_y = (qmr*ey_sub*dtsq + c_y*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1*gminv ey_sub, c_y, c_ym1 are N long arrays with the same shape, and in this case, the operation is elementwise, so indexing isn't needed, and I do not need an explicit do-loop (for loop in C languages) so it fits on a single line that is readable to a scientist in the field. The julia equivalent, I think is the same with a period on every operator c_y .= (qmr.*ey_sub.*dtsq .+ c_y.*(2 .- omsq_b.*dtsq))./gmdto2p1 .- c_ym1.*gminv The assignment was already verbose as it is, and I at the time tried to make it terser but still marginally readable by using variables that are named for...scientists I guess (e.g., gmdto2p1 means "gamma * dt / 2 + 1" dto2 thoughout the codes I read and use is "dt over 2") and adding 10 characters makes a little more cumbersome. While I think the visuals can be acclimated to, it is tedious to write, especially when you translate a formula from vectorised form to non vectorised or vice-versa and have to insert or delete periods. Mind you this is one of the simpler formulae in the code in question. You can imagine it quickly gets worse when the number of terms exceeds 6 or so. If you can't rely on implicit-do or terse assignment statements, then the good alternative in terms of readability then for the formula is just to do an explicit do-loop (for loop for julia). ! fortran 90, `integer i` above do i=1,size(c_y) c_y(i) = (qmr*ey_sub(i)*dtsq + c_y(i)*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1(i)*gminv end do # julia for i=1:length(c_y) c_y[i] = (qmr*ey_sub[i]*dtsq + c_y[i]*(2 - omsq_b*dtsq))/gmdto2p1 - c_ym1[i]*gminv end The problem is then I have made more extraneous bits to worry about. This gets even more hard to parse when the shape of the arrays exceeds more than 3 dimensions. I've read C style codes that are 7 levels deep with different indices, god is it painfully unclear and easy to get lost reading that, it's best to hide extraneous loops with syntactical sugar where possible such as to keep the algorithm as clear as possible, especially when it's a simple elementwise operation. It isn't like you can hide complexity all the time (or that it's even a good idea to do so), but this was a code for just two figures in a paper that needed a bit more oomf than numpy could, so given the time constraint for me, the size of the problem and everything, fortran fit much better. If you want to know more about the dot macro in julia, here is a nice blogpost about them[0]. The line above is from work I did for a paper that I initially thought "hey, it's been a few years, why not see if julia has stabilised by now" only to find out this was a decisive change they made. I mean they might deserve praise having made this macro a very general thing and apply widely to things that aren't just syntactical sugar for broadcasting, but after being frustrated trying to write my code, googling, and then finding this post, I basically dropped the julia learning effort and got the code written in fortran and made my figures. I can learn things in my spare time to a limit but at the end of the day I have a job to do. I still want to give julia a chance because the idea does seem cool. I complain about computer scientists a little tongue-in-cheek but really I find the metaprogramming in julia pretty interesting. I'm just not sure I can use it in my day job as a scientist without some effort in learning and time on my part which is at a premium right now. [0] https://julialang.org/blog/2017/01/moredots/ https://julialang.org/blog/2017/01/moredots/

noobermin 3y ago

I once noticed the thing is people balk at the line length in fortran as if it is some archaic hold off (which it is somewhat) that proves its obsolescence but in the next breath berate everyone for not using a formatter that will chunk lines into 100 characters in their favorite "modern" language. I guess the problem is fortran chose 80 as the line length and not 100.

Koshkin 3y ago
> as if it is some archaic hold off (which it is somewhat) Indeed it is! The standard IBM punch card had 80 columns. > and not 100 The standard IBM printer models had 120 print positions.
pklausler 3y ago
It is 80 for "fixed form" (card image) source files. It is 132 for free form modern source, but adjustable on the compiler command line. LLVM Flang uses the line length only for emitting optional portability warnings.
dboreham 3y ago
100?? Obviously 132 is the correct line length.
actinium226 3y ago
But mah punch cards!

queuebert 3y ago

As weird as it may sound, I prefer the old fixed-form source with continuation characters and mandated 7-character indent. Like Python, it made for consistent code formatting across people and libraries.