Re: compilation problem with module function interface definition



bv wrote:
....
> Let's hope they'll do a better job than a mangled mess that is a
> fattened, no, obese Fortran d'jour. In the meantime, here's a sample
> number purification system (sans KINDling perversions),
>
> real*8 a,w
> data x/1.23/
> print*, x
> a = w(x)
> print*, a
>
> 1.230000
> 1.23000000000000

That's worse than KIND numbers. It's certainly as verbose.

And what, *precisely*, is the definition of the operation that
function W performs? How can it tell the case that its argument
is to be rounded to a nearby decimal from the case where it
originated from a sequence of calculations and its nearness to
a short decimal number is pure coincidence (a rhetorical question,
since it's impossible for W to know any such thing)? And, how
long a decimal value is it promgrammed to look for? If I write
x = 1023.99995 (because I happen to know that gets converted
to an internal value that's one ULP less than 1024 on my compiler
of choice) will it convert that to double as 1024.00000000000
on the assumption that the last bits were erroneous? How far
from 1024 must I be to guarantee that W won't mangle the values?

Trying to second-guess the meaning of a numerical value is not
a very good approach to preserving information. The best approach
is to avoid losing the information in the first place. KIND is a
fairly clumsy attempt to provide for that. Changing the default
type or KIND of literals is a cleaner approach. The use of
float decimal as the default KIND for REALs would even be
backward compatible with existing Fortran rules. That's not to
say it wouldn't cause problems to programs that people thought
were standard compliant, but that really depended on binary in
some subtle way (for example, assuming X less than Y, binary
allows you to count on (X+Y)/2.0 being in the closed interval [X, Y]).

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


.