Re: inlining + optimization = nuisance bugs

> However, you can have "too much" precision if you can't have it
> universally.


It seems that people have been upset when the compiler emitted code
counter to whatever dirty tricks they were expecting.


The job of a compiler is to do the dirty work. Some of the floating
point dirty work is to keep track of machine precision. If the
compiler was to provide some kind of precision information, it could
tell us what is really happening, and relieve apps programmers of
trying to outguess the compiler programmers.


The compiler could provide pseudofunctions, like sizeof(), which would
tell us what precision (at compile time) or error range (at run time)
is actually available. Something like -


sizeof(x) gives 8
precision(x) gives 15 number of accurate digits
precision(x*y) gives 14
pluserror(x) gives 1e-14 + part of +/- range
minuserror(x) gives 3e-15 - part of +/- range


We could expand this by telling the compiler the precision of input
data, and let it do all the dirty work.


read(......, x, y)
precision(x) = 8 tell compiler actual precision
precision(y) = 6
x = x * y
precision(x) now gives 6


Alternatively, floating point types could include actual precision
data, which could be optimised out if never used.


type double = record
value: machinedouble;
precision: integer;
end;


I am not aware of compilers which provide these kind of facilities.
Has anything along these lines been done?


Andrew Fry
[PL/I let you specify the number of bits of precision, but the compilers
just round up to the next largest convenient hardware format. -John]






--

Return to the comp.compilers page.
Search the comp.compilers archives again.