Re: Is it time to legitimise REAL*8 etc?

Paul van Delst <Paul.vanDelst@xxxxxxxx> wrote:

Could someone explain to me the cumbersomeness of
SELECTED_REAL(INT)_KIND() ??

I agree the syntax is a bit wordy,

Yes, that's one thing - one that I think is more important than you make
it out to be. Another is that it just doesn't match the way most people
want/need to specify things. Decimal digits of precision might seem fine
in theory, but that just isn't a good match the reality of programming.
When what you want to do is select between the 32-, 84- and 128-bit
options for real, it is cumbersome to translate that into numbers of
decimal digits.

Quick now, would 15 decimal digits be the 64-bit or 128-bit option?
Maybe you happen to know, but if so, that's an obscure piece of
knowledge... and one that is in danger of being wrong on machines that
use slightly different representations. And when you see two different
programs, where one asks for 12 decimal digits and the other asks for
13, what's the difference? Maybe they seem the same to you, but I've had
people ask.

If selected_real_kind asked about binary instead of decimal precision,
that would be an improvement. (I've proposed an option for that, and I
think a variant of that might also be in, but I haven't kept up). But I
think the best option would be that which most closely matched the way
people most naturally ask. That's not in terms of digits of precision,
be they decimal or binary digits. People most commonly ask in terms of
the size of the representation - i.e. they might ask for the 64-bit (or
8-byte) option.

but doesn't one define these things (i.e. different kind types) once in a
module and then use that module where I need anything other than default
REALs/INTs? And then forget about it?

I would hope so, but I sure wish that people would stop giving examples
of the "wrong" way to do it. I think I've even seen those examples in
textbooks. Others see those examples and then think that's actually
normal practice.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: about c to fortran
    ... > more than 16 significant figures of precision. ... Where d is the number of decimal digits you write and ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Is it time to legitimise REAL*8 etc?
    ... want/need to specify things. ... Decimal digits of precision might seem fine ... but that just isn't a good match the reality of programming. ...
    (comp.lang.fortran)
  • Re: Diophantine matters
    ... precision, say thirty decimal digits. ... the PSLQ algorithm is more recent, and therefore likely to be better ... Integer Relation Algorithm; RNR Technical Report RNR-91-032, July 14, ...
    (sci.math.symbolic)
  • Re: double is integer?
    ... decimal digits of precision, and every implementation I've seen is exact ... integer type in question) or fractions that it becomes imprecise. ... range of int/long while relieving you of overflow worries. ...
    (microsoft.public.vc.mfc)
  • Re: Ceil double problem
    ... power of 2; base 16 FP maths would be reasonable on some systems. ... DBL_DIG doesn't mandate an exact representation, ... all numbers to that precision be uniquely representable. ...
    (comp.lang.c)