From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,581a3d578f4cfea9,start
X-Google-Attributes: gid103376,public
From: michael@ifr.luftfahrt.uni-stuttgart.de
Subject: Floating point problem with GNAT -- Help needed !
Date: 1996/07/08
Message-ID: <4rrc2g$10mk@info4.rus.uni-stuttgart.de>#1/1
X-Deja-AN: 167208386
organization: Comp.Center (RUS), U of Stuttgart, FRG
newsgroups: comp.lang.ada
Date: 1996-07-08T00:00:00+00:00
List-Id: <comp.lang.ada>


Hi,

I am just trying to track down a severe problem with GNAT 3.05 when printing
floating point numbers. I have found that on an Intel machine running NeXTSTEP
I get incorrect figures, whereas on a Sun or on an SGI the results are correct.

I would now like to check out whether this problem also occurs on
some other platforms. Most interesting to know would be the behavior on
WinNT, OS/2, Linux and other operating systems for Intel machines. I have
attached a little test program at the end of this mail and I'd be very happy
if someone who has GNAT installed on such a system could send me the result
of a test run.

Here is what I got on NeXTSTEP Intel.

X should be   => 1.23456789012345679E+04
or
X should be   => 1.23456789012346E+04
depending on whether your machine uses 64 or 80 bits for LLF
X             => 1.23456789012344832E+04
X, Aft => 9   => 1.234567168E+04
X, Aft => 6   => 1.234943E+04
X, Aft => 3   => 2.047E+04
Truncation(X) => 1.22880000000000000E+04

As can be seen the output is always 3 to 4 digits less accurate than required.
I have tracked down the problem to the Truncation attribute which returns an
incorrect result and is used internally by Text_IO. As a side note, this
problem affects all floating point output because Text_IO internally converts
all numbers to Long_Long_Float. As far as I know this problem does not
occur on systems which only have 64 bit floats as maximum precision.

Many thanks for your help

Michael

--------------------------------------------------------------------------------

with Ada.Text_IO;                 use Ada.Text_IO;
with Ada.Long_Long_Float_Text_IO; use Ada.Long_Long_Float_Text_IO;

procedure Test_Truncation is

   X : Long_Long_Float := 12345.678901234567890;

begin

   Put ("X should be   =>"); Put (" 1.23456789012345679E+04"); New_Line;
   Put ("or"); New_Line;
   Put ("X should be   =>"); Put (" 1.23456789012346E+04"); New_Line;
   Put ("depending on whether your machine uses 64 or 80 bits for LLF"); New_Line;
   Put ("X             =>"); Put (X); New_Line;
   Put ("X, Aft => 9   =>"); Put (X, Aft => 9); New_Line;
   Put ("X, Aft => 6   =>"); Put (X, Aft => 6); New_Line;
   Put ("X, Aft => 3   =>"); Put (X, Aft => 3); New_Line;
   Put ("Truncation(X) =>"); Put (Long_Long_Float'Truncation(X)); New_Line;

end Test_Truncation;

-- 
------------------------------------------------------------------------
--Dipl.-Ing. Michael Paus   (Member: Team Ada)
--University of Stuttgart, Inst. of Flight Mechanics and Flight Control
--Forststrasse 86, 70176 Stuttgart, Germany
--Phone: (+49) 711-121-1434  FAX: (+49) 711-634856
--Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)