ANSI C & perfect decimal<-> fp conversions

[Tim Peters]

>  > [tim p, wondering whether the ansi c & nceg stds/proposals are
>  >  aiming to constrain just compile-time decimal<->fp conversions
>  >  or runtime stuff too]
>  > ...
>  [david hough]
>  It was always the intent of IEEE 754 that compile-time and run-time
>  expression evaluation (including base conversion) yield the same
>  results.

Yet both 754 and 854 address these issues explicitly-- it's not a
question of divining intent --and say "should", not "shall".  Either
the 754 authors said what they meant or they didn't -- if the latter,
I assume the 854 authors would have taken their opportunity to
clarify, as they did in many other areas.  I personally *wish* the std
had said "shall" here, but so it goes ...

>  It's somewhat contentious whether compile-time expression
>  evaluation should honor rounding modes and generate exceptions just
>  as if the expression were evaluated at run time.

Ideally, assemblers and tools etc too would all work under the same
conventions and yield the same results.  It's hard for an established
vendor to sell the idea of changing "everything" at once; I imagine
the contentiousness here will diminish in time as more new vendors do
it all right from the start.

>  It is certainly the intent of NCEG to ratify the non-contentious
>  part of that requirement; whether X3J11 requires that as well (in
>  the normal mode of compiling in the execution environment), I leave
>  to the X3J11 members to opine.

If it doesn't say "shall", it ain't a requirement.

>  > [tim wondering whether "networking benefits" arguments should
>  >  carry much weight in the context of nceg]
>  > ...
>  [dgh]
>  This is like saying that NCEG shouldn't think about vector or
>  multiprocessor systems, and there should be another group to worry
>  about those (at least for multiprocessor there are too many
>  already; same for vector if you count Fortran-90 as including
>  vector (array) processing).

Agree it's like saying NCEG shouldn't be fiddling with parallelism
issues:  that's still a limited-interest area (perhaps like
networking), and is properly the concern of X3H5 (which obtained an
ANSI charter to create a C binding for a parallel programming model).

Disagree it's like saying NCEG shouldn't be fiddling with vector/array
syntax:  NCEG is trying to make C more attractive to scientific
programmers, and array operations are ubiquitous in numeric
algorithms; array notations in languages (e.g., BASIC, early Fortran,
APL) long predate vector hardware.  Users on all kinds of platforms
want the expressive convenience & power it provides.

Agree that NCEG should worry about the impact of its demands on *all*
platforms (whether networked, parallel, vector, serial, whatever).
That's in fact the basis of my concern:  NCEG shouldn't mandate stuff
specifically intended to help networked platforms *if* that stuff
imposes unreasonable costs on other platforms.  If someone could
demonstrate that, e.g., vector notation in C would impose new &
excessive costs on a networked platform, that would be a strong
argument in favor of NCEG dropping vector notation, or shuffling it
into an optional appendix.

>  > No argument, but think the proper place to fix 754 problems is in
>  > revisions to 754; it's not really a *C* issue.
>
>  Everybody has a finite amount of time and energy for standards
>  work.  One of the main problems with IEEE 754 and 854 is that no
>  bindings to standard languages were specified.  The bindings
>  between C and 754 are a legitimate C issue, judging by the size of
>  this mailing list (130 people not counting Sun employees).  X3J11
>  decided a long time ago that libraries were part of its language
>  standard, since you don't have any useful portability otherwise.

Strongly agree that C bindings for 754 are a legitimate NCEG activity.
It's *going beyond* 754 that's dubious, precisely *because* there's only
a finite amount of time for stds work.  E.g., suppose you get perfect
conversions into NCEG -- what does that accomplish?  Maybe networking
will be easier for IEEE shops all of whose vendors have adopted NCEG C,
but it leaves everyone else running an IEEE box out in the cold.  To
make it generally helpful you'll have to spend the next N years trying
to ram the same kind of 754 extensions thru an IEEE Fortran committee,
and an IEEE Modula-3 committee, etc etc etc.  The *problem* here seems
to be that 754 was too permissive, not that there's not a language
binding -- change 754 instead and the problem goes away for every
new-&-improved-754X vendor, under all languages, at one stroke.  Really
think it would save you oodles of time.

>  The machine-independent base conversion that accompanied 4.2 BSD
>  wasn't so hot; it last appeared in SunOS 2.0.  4.4 BSD should be
>  better.

Gonna trash it in any case -- just don't want to sign up for something
impractically slow <grin -- have I said that before?>.

>  By the way, I should mention that the "machine independent" code that
>  I intend to adapt for public distribution is only independent among
>  machines for which
>  	short = 16 bits
>  	int = long = pointer = 32 bits
>  What I distribute will have float pack/unpack routines for IEEE 754
>  single, double, quad, and extended, but adapting to other
>  floating-point formats should be relatively simple - and will be left
>  as an exercise for the student.

They still make machines that feeble <grin>?  Seriously, I'm very glad
Sun is willing to underwrite this effort (and, of course, that you're
willing to undertake it!).

>  > ... think the appalling state of fp arithmetic these days is a
>  > consequence of putting accuracy at the bottom of the design list.
>  [dgh]
>  More likely a consequence of putting time to market at the top of the
>  list.

At first, yes.  "Upward compatibility" is the real culprit -- keeps the
arithmetic in its initial compromised state forever more.

>  > [tim saying the 8847 fdiv design doesn't pipeline, ergo unsuitable
>  >  for a supercomputer]
>  [dgh]
>  This may be a red herring - the 8847 uses Newton algorithms with a
>  correction step at the end.  The instructions could probably be
>  pipelined if it were worth the trouble.  IBM has demonstrated that if
>  you can issue a multiply-add every cycle along with the necessary
>  loads and stores, you can do pretty well on many problems that
>  supercomputers do well on.  This just means that the supercomputer
>  niche will continue to shrink as a fraction of the total market.

I'll pass on the marketing questions (nothing to say -- don't think
anyone really knows yet, & certainly not me <0.1 grin>).

I hope my point *is* a red herring, but that will have to wait for a
vendor to actually pipeline the sucker.  TI isn't the only vendor with a
Newton/Goldschmidt-plus-correction method out or in the works, and far
as I know none of 'em pipeline (or even allow a plain multiply to issue
during most of the divide shadow) -- not enough chip space.  We'll see.

>  At far as underflow goes, there was no demonstrable advantage to
>  mandating one of the various permitted options over the others, and
>  good implementation reasons to permit more than one approach.  Time
>  has demonstrated that this wasn't such a good idea for other reasons
>  than we considered at the time.

Think the most effective way to correct that is to revise 754.

>  > Honest -- I'm not against it [correctly rounded results for double
>  > transcendentals].  But I have yet to hear anyone *ask* for it.
>
>  Just yesterday I marked a bug report "not going to fix".  The
>  customer wanted identical numerical results on Sun-3's with software
>  floating point, 68881's, and FPA's.  I've gotten similar requests
>  from other people who should know better, at Mathematica for
>  instance.  Anyway if the customer had wanted to know about Sun-4's, I
>  could have answered "on the agenda - to be implemented some day".

"The identical" is more often the enemy of "the correct" than the
friend.  I.e., I bet if you went back to your customer and said "OK,
we'll give you the same answers everywhere, but we're picking the worst
of the lot across the board" they'd reply "good enough!  just so long as
all these *differences* go away".  Every time Cray introduces a new
model it gets to ask its customers whether they want better arithmetic;
that a Y-MP yields results bit-for-bit identical to a Cray-1's isn't
because CRI's hardware designers *can't* make better arithmetic
acceptably fast.

>  > [tim still futilely insisting that cri's addition drew the most
>  >  complaints]
>  [dgh]
>  Probably because the addition anomaly was easier to see and
>  understand.
>  > ...
>  If you don't know the error, then you don't know the answer.  Most
>  customers don't want to know:

When running a massive physical simulation (e.g., of the weather, a wing
design, circuit, car crash, bomb, ...), the only way to know whether the
program "worked" is to check the results against the real-world
phenomenon being studied.  I.e., "right" & "wrong" are empirical in this
field, not analytical -- and maybe that's why good-to-the-last-bit
accuracy doesn't seem so essential in this field (most often some of the
crucial input parameters are known to only a few digits, the code
implements a model that's a more or less gross simplification of the
true physics, ... 2 ulp errors may be the least of the problems).  When
a simulation code doesn't work (outputs don't jibe with the real world),
but does work (jibes with the real world) after fiddling with some
subroutine's use of addition, the presumption has to favor addition as
being the true culprit.  I don't know that CRI's truncation was the
*true* problem, only that that's what was complained about the most.
Most of the "addition problems" *I* tracked down amounted to massive
cancellation in a naive algorithm -- and even 754 quality wouldn't have
saved them from that.

>  > [tim trotting out the int(6./3.).eq.1 fortran example]
> [dgh]
>  That this sort of thing happens in general is nothing to get excited
>  about; (int) 3.0*(2.0/3.0) or equivalent is going to get you on any
>  kind of computer.  That 6.0/3.0 is not exactly 2.0 is more irritating
>  but only because you know the answer and hence the error.

Think it goes deeper than that, David.  Fortran has been around a long
time, and some programs have run successfully unchanged on every crazy
platform that's come along in the last 20 years.  Some machines
truncated, some rounded to nearest (or one of the variations thereof),
some even unconditionally lit the last bit for "rounding".  But on *all*
these platforms, 6.0/3.0 was never *less* than 2.0, so int(6./3.) was
always exactly 2.  No experienced Fortran programmer would expect
3.*(2./3.) to be exact, but all their experience told them that
int(6./3.)  was safe.  Then consider that on many scientific machines:
(1) no integer type was directly supported (e.g., most recently I'd lump
the ETA machine in that category), or (2) floating operations are much
faster than integer operations (e.g., mul or div on a Cray).  These have
both acted as strong pressures to cause many speed-conscious Fortran
programmers to do their integer arithmetic *using* floating-point
operations.  They're in for a real surprise if an exact quotient can
come out less than the true value.

There's another reason this is especially irksome in Fortran:  Fortran
*defines* the trip count of

      do 666 x = 0., 3., 3.
     (somewhat like C's for (x = 0.; x <= 3.0; x += 3.0) { ... })

to be INT((hi-lo+stride)/stride) = INT((3.-0.+3.)/3.) = INT(6./3.) =
quite possibly a big surprise.  And it defines AMOD(x,y) to be
x - INT(x/y)*y, which may lead to the surprising AMOD(6.,3.) = 3..

But for all that, they still griped more about addition <grin>.

>  > >  Our routines, which are accurate over the full range, take 860 cycles
>  > >  to do
>  > >  	ecvt (value, 17, &decpt, &sign);
>  > >  and 903 to do
>  > >  	atof (s);
>  > >  using 64-bit integer arithmetic.  About half the time in the atof call
>  > >  is parsing, and not conversion.  The ecvt time is mostly conversion.
>  Independent of the data?  That's sort of amazing.

na-just-change-Sun's-routines-to-look-at-512-characters-every-time-
   regardless-of-the-input-string's-length<grin>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
timaksr.com, ksr!timaharvard.harvard.edu