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,efbcb7a47025db16 X-Google-Attributes: gid103376,public From: kst@sd.aonix.com (Keith Thompson) Subject: Re: Effort to Port TSG to Ada-95 and How Fast it Ran in Gnat Date: 1997/02/21 Message-ID: #1/1 X-Deja-AN: 220352390 Sender: news@thomsoft.com (USENET News Admin @flash) X-Nntp-Posting-Host: pulsar References: <5efjta$jlm@top.mitre.org> Organization: Aonix, San Diego, CA, USA Keywords: Ada-95, gnat, port, conversion, optimization, program_error Newsgroups: comp.lang.ada Originator: kst@pulsar Date: 1997-02-21T00:00:00+00:00 List-Id: In dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Some comments on Michael's porting experience [...] > (9) A floating point assertion failed (an impossible error) in which > a particular number was both > and <= another number at the same time. > This only happened on the Sparc, not in the same code on a pc, nor on > the same code on the Verdix/Sparc Ada-83 compiler. It required an extra > epsilon comparison to be made instead of using the built-in <= operator. > > --> If two floating point numbers A and B are both non-model numbers > if is perfectly possible for all of > > A = B > A < B > A <= B > A > B > A >= B > > to be true. Code that assumes otherwise is flawed. This is possible according to the Ada language definition, but it seems unlikely to happen in real life. Typically, Ada floating-point comparisons are implemented simply by generating the appropriate hardware compare instructions. These instructions don't know anything about Ada's concept of model numbers, they just operate on the bits. It's possible that one or both operands are NaNs (IEEE Not-a-Number), special non-numeric floating-point values that can result from operations like 0.0/0.0. Try printing the values you're trying to compare. Note that the compiler's runtime routines may or may not handle NaNs (the language definition doesn't say much about them), so you may have to do something like an Unchecked_Conversion to an integer type of the same size to figure out exactly what the values are. The SPARC processor manual specifies the layout of the floating-point types, including the representation of NaN, Infinity, signed zero, denorms, and so forth. It may also be that the comparison is being done with values in registers that are stored with different precision than the values in memory, though I'm not sure how that would lead to the results you describe. I'd be interested in seeing a small example of this. -- Keith Thompson (The_Other_Keith) kst@sd.aonix.com <*> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706 Antimatter is not a condiment.