Re: Weird problem on Lahey lf95 v6.2b

From: glen herrmannsfeldt (gah_at_ugcs.caltech.edu)
Date: 06/07/04 

Date: Mon, 07 Jun 2004 19:28:31 GMT

Richard Maine wrote:

> Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:

>>Can anyone suggest what is happening here? My initial guess is that
>>b(i_b) is being held in an extended-precision register in the first
>>print statement, but in the second and third has been truncated down
>>to a real. But why is this happening?

> Seems like a likely explanation. The I/O will presumably involve plenty
> of register usage - enough to flush most anything. The initial
> subtraction is likely done before the I/O process "gets going"
> enough to flush the registers.

There are two different problems to consider. One is the
use of extended precision for intermediate results, the other
is the possible use of double precision for single precision
results.

The x87 processor has the ability to truncate the fraction
to reduce precision, but it isn't easy or convenient to change
those flags in the middle of expressions.

>>Surely, the compiler is required
>>to perform the truncation on the register b(i_b) when it is referenced
>>in the first statement,

> That's actually a point of some controversy, which I might
> summarize as saying that surely it is not that sure. :-)

(big snip)

It has been suggested that a C implementation that returned
42 for all floating point operations would be standard conforming,
though certainly a low quality implementation. It might be
that Fortran isn't that loose on its floating point.

As many people want speed in Fortran programs, and doing the
truncation may require store/load (hopefully through cache),
one can see that it might not be very fast.

I started a discussion some time ago on the result of
single precision multiply, which many processors generate
a double precision result for, and the code may or may
not truncate it.

-- glen

Relevant Pages

  • Re: MicroBlaze floating point precision issues
    ... implementation is presenting *supposedly* single-precision floating ... precision is 0x4036000000000000. ... So, truncate the double-precision ... cycles doing wasteful double to float conversions. ...
    (comp.arch.fpga)
  • Re: TRUNC Function
    ... them into degrees minutes and seconds (i.e truncate the ... then the 5th one rounds to 30 instead of 29. ... I have tested it using a calculator and I can see how it ... not held to its full precision in the calculator memory. ...
    (microsoft.public.excel.misc)
  • RE: truncate
    ... Tools>Options>Calculation - tick the precision as displayed check box. ... This setting applies to all cells in the workbook. ... > How do I truncate my numbers so that $54.2223456 is changed to $54.22? ... > of total characters, but that doesn't help since $54.22 has fewer characters ...
    (microsoft.public.excel.worksheet.functions)
  • Re: TRUNC Function
    ... significant figures in you input data ... >them into degrees minutes and seconds (i.e truncate the ... >I have tested it using a calculator and I can see how it ... >not held to its full precision in the calculator memory. ...
    (microsoft.public.excel.misc)