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.0 required=5.0 tests=BAYES_00,FORGED_HOTMAIL_RCVD2, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,506514dbbd4d1672 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.224.105.205 with SMTP id u13mr7594852qao.6.1354997835413; Sat, 08 Dec 2012 12:17:15 -0800 (PST) Received: by 10.49.18.231 with SMTP id z7mr2184464qed.25.1354997835376; Sat, 08 Dec 2012 12:17:15 -0800 (PST) Path: gf5ni48613681qab.0!nntp.google.com!c8no2099495qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 8 Dec 2012 12:17:15 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=188.61.3.53; posting-account=gRqrnQkAAAAC_02ynnhqGk1VRQlve6ZG NNTP-Posting-Host: 188.61.3.53 References: <87c30a6b-cd6b-4f96-b6ea-3358f40c1a54@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <4530e142-cd98-49e2-9aa3-fea7fbb84b26@googlegroups.com> Subject: Re: Q: type matching with IEEE 754 double and Intel endianess From: gautier_niouzes@hotmail.com Injection-Date: Sat, 08 Dec 2012 20:17:15 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-12-08T12:17:15-08:00 List-Id: Le samedi 8 d=E9cembre 2012 07:31:27 UTC+1, J-P. Rosen a =E9crit=A0: > Le 07/12/2012 09:54, gautier_niouzes@hotmail.com a =E9crit : >=20 > > Now, assume the program is running on a machine where Long_Float is act= ually IEEE_754, and endianess is the Intel one. >=20 > > Is there a "solid" way to prove with some check that it is the case ? >=20 > Uncheck_Convert it to an array of bits, and compare against the expected >=20 > pattern. Unchecked_Conversion is precisely for that: getting at the >=20 > underlying representation Thanks. Now the question becomes (hence the "solid"): how to eliminate fals= e postives and false negatives ? Say my test looks like: x: constant Long_Float:=3D 1234.0e56; Can_use_native: constant Boolean:=3D IEEE_Double_Intel_Portable(x) =3D IEEE_Double_Intel_Native(x); For eliminating false negatives it is easy since I'm developing on Intel x8= 6 or x64 machines (there are probably borderline cases with more than one b= inary representation for one decimal one, but it simply is a question of tr= ying another value for the constant x). Now for false positives, it is probably a question of avoiding some very un= likely cases, e.g. an ieee number with a palindromic byte sequence (where t= he endianess would be fooled). Perhaps 2 or 3 constants are better for testing: Can_use_native: constant Boolean:=3D IEEE_Double_Intel_Portable(x) =3D IEEE_Double_Intel_Native(x) and IEEE_Double_Intel_Portable(y) =3D IEEE_Double_Intel_Native(y) and IEEE_Double_Intel_Portable(z) =3D IEEE_Double_Intel_Native(z); Any thought about good choices of constant(s) is welcome :-) _________________________ Gautier's Ada programming http://gautiersblog.blogspot.com/search/label/Ada NB: follow the above link for a valid e-mail address