Re: Newbie question about double precision

From: Richard Edgar (rge21_at_astro.su.se)
Date: 12/04/03 

Date: Thu, 04 Dec 2003 17:56:27 +0100

Michael Metcalf wrote:
> "Richard Edgar" <rge21@astro.su.se> wrote in message
> news:bqnj3v$dpc$1@news.su.se...
>
>>One related nasty is the following:
>>
>>REAL (KIND=QP):: third = 1_QP/3_QP
>>
>>isn't what you think it is, either. This sets the variable 'third' to be
>>equal to zero (probably.....). The reason? In Fortran, KINDs are
>>specified using integers, and so there is a good chance (although not a
>>certainty) that QP can also represent a valid _integer_ KIND. So the
>>compiler does 1/3 (integer divide), gets the answer zero, and then
>>stores this in the quad precision variable 'third'
>
> I'm not clear why you think this is any different to writing, for default
> real third, = 1/3 rather than = 1./3., also an error that is easy to make.

Because, when I've gone to the trouble of typing those extra '_QP's, I'd
like them to have an effect (I do appreciate that I was _unlucky_ that
QP was also a valid INTEGER type)! When this one first bit me, I was
very fortunate that the zeros thereby produced meant that the subroutine
in question immediately started producing garbage. Otherwise, the bug
could have stayed for a very long time (indeed, I might not even be
aware of it now).

Or put another way, I'd added the '_QP' tags _because_ I was aware of
the 1/3 vs 1./3. problem, and I expected them to protect me from it.

>>Whether your original problem is an error in the standard is very much a
>>matter of opinion. It would be nice if variables didn't have to be
>>tagged, but they do.
>
> It's not an error in the standard as it would otherwise have to be a
> special-case exception to the general rules governing expressions and
> assignments. It was realised at the time that there might be a backwards
> incompatibility with the way some F77 compilers had dealt with it in DATA
> statements, and that was duly noted in the new standard and the books
> describing it.

Mea culpa - 'Error' was too strong a word. This was what I was alluding
to when I mentioned 'special cases' and the like. I should have been
clearer. I believe that it would be _possible_ to specify a language
such that the required types could be deduced, but the established rules
of Fortran do not allow it.

Richard

Relevant Pages

  • Re: Finding roots of non-linear equations in Excel
    ... Where's the 'Numeric Recipes in BASIC' book? ... > it's no big deal to find the zero. ... > secant method could all be used (binary search is slowest but also ... Also, you are correct, the Numerical Recipes book is Fortran and C. ...
    (microsoft.public.excel.worksheet.functions)
  • Re: RfD: Ambiguity in FATAN2
    ... flag e.g. NEGATIVE-REAL-ZERO or similar. ... > for systems with and without negative zero. ... the Fortran document forbids having both ATAN2 ... I see Fortran doesn't specify the behavior of FATAN2 for NaN, ...
    (comp.lang.forth)
  • Re: Ideas for finding blank data fields in user records?
    ... trick all tested for negative zero using assembler and the SIGN ... The code itself says it was written in Fortran II. ... But if you are testing for a negative zero, there has to be a way to ... tape of the programs and several boxes of cards which turned out to be ...
    (comp.lang.fortran)
  • Re: writing negative zero
    ... >> the Fortran and Fortran 95 standards, ... >> be written using a minus sign by a standard conforming Fortran 95 ... >write negative zeros with a leading minus sign, ... SZ (where Z stands for zero) to force - when outputting negative zero. ...
    (comp.lang.fortran)
  • Re: Was there a negative real zero possibility in early Fortran?
    ... There is some possibility that negative fixed point zero ... I don't see anything in Fortran I ... Floating point negative zero is very common, ... (It is now standard, at least as of Fortran 2003, for machines ...
    (comp.lang.fortran)