Is "accuracy" defined anywhere on that page?

From https://github.com/niklas-heer/speed-comparison/blob/master/...

  // [I removed the error checking]
  def pi_accuracy(value_str):
      """Calculate accuracy of computed pi value.
      Returns the number of correct decimal places (higher is better).
      """
      value = float(value_str)
      # math.pi is available in MicroPython
      accuracy = 1 - (value / math.pi)
      return -math.log10(abs(accuracy))

This is complete misinformation and you should stop posting it.

One can explicitly declare a function (or subroutine) to be PURE in Fortran, but it is not the default and never has been.

> Fortran functions correspond to "pure" functions in C/C++ and other languages, i.e. idempotent functions that do not modify arguments or global variables.

This is nonsense. Fortran functions aren't pure. They can have side effects.

HPF/Fortran '95 added the PURE attribute for subprograms, but it's not the default.

Functions are called only within the context of expression evaluation, and Fortran allows a compiler to perform algebraic transformations on expressions. If you write X=Y*F(Z) and we can determine that Y is zero, the function call can be deleted. So side effects in functions are somewhat risky.

I suspect that nearly all of the Fortran code that will exist ten years from now already exists today, so knowing the language is a skill that is more likely to be useful to you for performance testing and code porting than for new development.

The trickiest part of really learning Fortran today is that it is hard to define what the language is, apart from the practical definition imposed by what its seven or so surviving compilers accept and how they interpret it. There are near-universally portable features that are not part of the ISO standard; there are standard features that are not at all portable, or not available at all anywhere. So what one should know as “Fortran” is its reasonably portable intersection of features across multiple compilers, and there isn’t a good practical book that will teach you that.

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.

Table-driven parsers with custom per-statement tokenizers are still common in surviving Fortran compilers, with the exception of flang-new in LLVM. I used a custom parser combinator library there, inspired by a prototype in Haskell's Parsec, to implement a recursive descent algorithm with backtracking on failure. I'm still happy with the results, especially with the fact that it's all very strongly typed and coupled with the parse tree definition.

It goes back to the CDC 6600 at least, and is most often seen as part of Hamming distance computation (pop(xor(x,y))). But it turns out to be really useful for other things (trailing zero count), and worth having in hardware since the software sequence is a ~dozen instructions for 64 bits.

Universally distinct would seem more correct than unique, at least mathematically speaking, unless there's only ever going to be just one of them.

Fortran compilers were historically implemented by hardware vendors in order to sell their hardware, and this still largely holds true across the surviving implementations with the exceptions of GNU Fortran (obviously) and nagfor (commercial s/w product). There's a good reason that Cray Research's software group was initially part of its marketing department.

The compilers were, but Fortran wasn't invented so that hardware manufacturers could sell their wares to scientists.

It was invented so that IBM could sell more gear to the institutions that employed them.