[J3] (SC22WG5.6120) [ukfortran] [EXTERNAL] Re: Two things from IFIP WG 2.5 meeting

[N.M. Maclaren]

On Jul 26 2019, Van Snyder wrote:
>>For binary128, 49,536 bits would be required, but it was not requested
>for IEEE 1788.

That's what I meant. Sorry about being confusing. Yes, I agree that it's 
affordable to implement under many circumstances, but a standard should NOT 
consider just the easy circumstances. And a specification that is feasible 
for 64 bits but not 128 bits is dubiously within the spirit of Fortran.

As a slight aside, there are other approaches that give most of the benefit
for much less cost.  One is (true) probabilistic rounding during the
accumulation, which may be heretical but has a lot of technical advantages.
The relevance is the question of whether it is reasonable to exclude other
approaches by mandating one particular one?

>If you want papers that describe the problem, I can get them.  Siegfried
>Rump gave very nice demonstrations of the problem at the WG 2.5 meeting
>in Sydney last year, and at ICIAM in Valencia last week (and many other
>times when I was not in attendance).

I should be interested if you have any that demonstrate it is a critical
issue in realistic analyses.  All of the ones I have seen were implausible,
to put it mildly.  Yes, some were of academic interest, but I never saw a
case that this makes the difference between a complete, practical analysis
being valid and not being.  As I tried to say, being perfectionist in one
respect rarely helps with complete problems, which are usual complex.

>This is a red herring.  We are discussing the Fortran standard, after
>all, not the C or C++ or 754 standard.  BTW, Kahan did discuss the
>80-bit vs. 64-bit problem in the paper attached to the original message.

Regrettably, it is not, as I can witness from way back when.  Intel is
neither the only nor the first system to have multiple arithmetics, and
I first encountered this problem before using either it or C.  I may have
missed something, but I believe that Fortran still allows an expression
to be calculated using any suitable method, subject to parentheses.  And
my point is that that is not enough!  You must constrain a compiler to
use exactly the same precision (and compatible arithmetic) in ALL places.

You will remember when I raised the issue of what IEEE 754 said about the
evaluation of expressions, and asked whether Fortran should honour that.
The vast majority of the meeting was adamantly against it.  To enable such
code to be conforming, reliable and portable, Fortran would have at least
to provide a mechanism for such an evaluation mode.  C does, in theory.

Regards,
Nick Maclaren.