Meeting the Scope and Purpose of P754

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

Guillaume Melquiond wrote:
> You are right, it is possible to write an algorithm that takes
> into account bugs of the low-level floating-point architecture.

I was not talking about that kind of defensive programming.  I am
assuming that all primitives are strictly-conforming, and that there
is a way to control their sequence so that algorithms like Knuth's
two-sum, three-sum and beyond can be used.  Given that we are talking
about 754R I'm even assuming that fma is supported.  Of course, in a
traditional high-level language one needs to be able to control the
compiler's generation thereof (even if only via inline __FMA() calls).

I am in full agreement that THIS type of reproducibility must be available.

What I'm disagreeing with is that there should be (can be, in fact) a magic
"reproducible" attribute that can be attached to a block so that *any* code
within that block is guaranteed to generate reproducible results.

So I repeat:

  The net of this is:  yes, control over reproducibility is desirable, but
  both user and provider have to cooperate to achieve it:  the provider, by
  means of control options and documentation of idioms that can or cannot
  guarantee reproducibility, and the user by programming in the subset for
  which reproducibility CAN be guaranteed.

To be specific:  I doubt that the Ar©naire code depends on details of NaN
propagation, or whether optional exceptions are reflected -- i.e. the few
things that 754R in its current form leaves undefined, and hence trigger
the ire of those who want strict reproducibility.

Michel.

P.S.  I have to admit that my perspective is clouded by the fact that I
      program in assembler, and when I program in C, my style reflects
      this.  I only trust C programs when I have seen the generated code,
      so C does not give me any great portability advantage over assembler.
      I do write C for multiple platforms (even big vs little-endian, or
      with different "long"  and "long double" interpretations), so I am
      aware of portability issues -- but I cannot claim "portable", only
      "ported", programs.

      I'm talking about programs where reproducibility is critical, like
      my binary/decimal conversion programs, not about run-of-the-mill
      applications, of course.

      I have great admiration for people who routinely write code for
      multiple platforms, but I'm pretty sure they pay *explicit* attention
      to portability and reproducibility, and don't expect compilers to
      provide that portability without any special effort on their part.
      In the end, they too really only produce "ported" programs, though
      when a new platform shows up, they may have a reasonable expectation
      that it will work with only a few (perhaps even NO) tweaks.
Sent: 2007-07-15 11:05:36 UTC