TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version: 1.0
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To: Lamar Harris <[log in to unmask]>
Date: Wed, 12 Feb 1997 11:45:01 -0500
Reply-To: David Wheeler <[log in to unmask]>
From: David Wheeler <[log in to unmask]>
In-Reply-To: Lamar Harris <[log in to unmask]> "Floating point problems in GNAT" (Feb 12, 10:57am)
Content-Type: text/plain; charset=us-ascii
Parts/Attachments: text/plain (33 lines)
Here are my two cents.  You'd be better off sending to comp.lang.ada;
this kind of question isn't really in team-ada's charter.

This isn't specific to Ada;
comparisons involving floating point (FP) can be tricky!
In particular, testing equality of floating point values is best avoided
if possible.

It may be that the FP numbers are
different but happen to print out as the same number when printed
in base 10 using the built-in fp-to-string routine;
printing more digits might not help.
To test this theory, print out the hexadecimal representations of your
FP numbers.

Another even worse problem: some systems with floating point acceleration
logic (inc. the 486 and Pentium) use separate stacks for FP computation
that have more precision than can be stored in
variables, and they can do comparisons on those results (I don't
know what kind of code GNAT generates for FP).
Printing won't help in this case, since the numbers being used for
comparison are NOT the ones you can store or print, they're
just temporary values on a floating point accelerator stack.

You can build a procedure to print the hex representation using
unchecked_conversion; you can even use My_Float'size to make
the implementation "portable".

--

--- David A. Wheeler
    [log in to unmask]

ATOM RSS1 RSS2