Function philosophy

Tim Peters uunet!ksr.com!tim
Thu Dec 2 23:49:31 PST 1993


I don't see how this:

> < 1 ulp can not reasonably be requested.  You *must* allow for deficient
> hardware and implementation in an HOL.

meshes with this:

> But so does it [Ada] require that 3.0/3.0 = 1.0, which some (non-IEEE
> obviously) machines can not meet.

unless Ada is not an HOL <wink>.  After all, the relative speed penalty
for faking correct division on a machine without good HW support is much
higher than the relative speed penalty for faking a little extra
precision in libm functions (and having never worked for a company that
_did_ have good HW support for correct division, it would be very hard to
convince me that's wrong:  "even Cray" manages a < 1 ulp libm, and they
don't even have HW addition that works <0.1 grin>).

 From there I'm afraid we'd just argue about the standards process, and
I'll skip that cuz I haven't heard a new argument in 10 years.  Vendors
dominate at least the American version of that system, hence most
incentives are toward accommodating the least common denominator.

I agree that the best chance for adopting a < 1 ulp libm std would be for
an IEEE 754 binding, and maybe NCEG's reincarnation will tackle that.

As to the Ada work, I studied some last year and would like to see a
summary of where it stands today -- other interest out there?  But I
can't help but sigh that, good as this work may be, it leaves
approximately 99% of working numeric programmers unaffected.

> > eternally-surprised-that-users-put-up-with-exactly-the-wrong-things-
> >    ly y'rs  - tim
>
> But there are always those hardware vendors that let them put up with
> exactly the wrong things.

In a buyer's market, users can write just about anything they want in to
a contract.  Yet I've never seen an accuracy requirement written in to a
contract, except for sloppy paraphrasing from a favored vendor's own HW
manuals <grin/sigh>.

integers-shall-be-64-bits-and-verily-verily-shall-thine-division-be-
   good-to-50.14-bits-ly y'rs  - tim

Tim Peters   timaksr.com
not speaking for Kendall Square Research Corp



More information about the Numeric-interest mailing list