I have learned to think about this problem thus: there's reality, and then there's perceptions, and communication is a task of persuading somebody else's perception to somehow align with yours. When you both view reality clearly, it's best to present simple facts and their implications. The other three cases are education, bullshitting, and nonsense, and it's best to involve a professional.

I think that Feynman was talking about preparing a freshman-level lecture for Caltech-standard freshmen, but maybe you have somebody else in mind.

I would say: You either don't understand your subject, or don't understand your audience, if you can't explain your subject to your audience, at the highest level they can understand, coherently.

The average person can understand anything ... at some level. Being able to match that level is positive evidence (but not proof) of competence.

Duality: Being unable to match that level is positive evidence (but not proof) of incompetence.

I suspect Feynman actually haven't been to the world of the middle-to-bottom sections of the bell curve, where that thinking becomes toxic. It only works because there's collective illusion that minority theorizations can be more correct. Absent that, or that inverted, majority becoming assumed likely more correct, not only one's explanations will be interpreted biased as likely more wrong, but acts leading to majority groups following your round-Earth hypothesis can be seen as manipulative and/or fraudulent. That kind of people(which exist) abusing versions of those lines get annoying fast.

I think if you understand something really well (anything: the law of gravity, the Curry-Howard isomorphism, electrolytic dissociation, general relativity,...), you can find a bunch of comparisons, or metaphors, or other ways to explain it so that an interested five-years-old will get a rough idea. A very rough idea indeed, but one that could allow them to ask qualitatively reasonable questions, and that forms an intuition which helps during a real study.

The "interested" part does a lot of lifting though. It's really hard to explain things to uninterested people.

If the person you are explaining your project to is not interested in the technical side, presumably under the rather confused but popular theory that technical aspects are not relevant to technology ventures, you'll not be making headway. It's much better to just make up some dollar numbers and run with that.

Where exactly does K&R specify the buddy system?

Fortran requires compilers to “honor the integrity of parentheses” but otherwise doesn’t restrict compilers from rearranging expressions. Want a specific order of operations and rounding? Use parentheses to force them. This is why you’ll sometimes see parens around operations that already have arithmetic precedence, like `(x times x)-(y times y)`, to prevent the use of FMA for one of the multiplications but not the other.

Let’s hope that they don’t also replicate ISO Fortran’s design flaws with lower array bounds, which contain enough pitfalls and portability problems that I don’t recommend their use.

I haven't used either language much myself and I thought the feature looked brilliant so I'd be very curious to know what sort of issues you ran into in practice.

How does this bug concern aliasing?

In old school FORTRAN (I only recall WATFOR/F77, my uni's computers were quite ancient) subroutine (aka "subprogram") parameters are call-by-reference. If you passed a literal constant it would be treated as a variable in order to be aliased/passed by reference. Due to "constant pooling", modifications to a variable that aliased a constant could then propagate throughout the rest of the program where that constant[sic] was used.

"Passing constants to a subprogram" https://www.ibiblio.org/pub/languages/fortran/ch1-8.html

It's literally in the description? Because of aliasing, a variable that should've been zero became four.

It wasn't a variable.

It wasn't intended to be a variable, but it did become one. Its value varied, it's in the name.

But this is just Fortran's call-by-reference in action. It's not aliasing.

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.