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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c3a7c1845ec5caf9 X-Google-Attributes: gid103376,public From: Mats Weber Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/29 Message-ID: <3365C5E0.57A1@elca-matrix.ch>#1/1 X-Deja-AN: 238141947 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335E0B1F.12C9@elca-matrix.ch> <335F5971.6375@elca-matrix.ch> <33671d9c.5046069@news.airmail.net> <3360BFA8.5A4A@elca-matrix.ch> Organization: ELCA Matrix SA Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada Date: 1997-04-29T00:00:00+00:00 List-Id: Robert Dewar wrote: > > Mats said > > < a < b not equivalent to b > a > or > a <= b not equivalent to a < b or a = b>> > > Well equivalent is a tricky word, Mats I certainly hope you realize that > with standard Ada floating-point semantics, you are not guaranteed that > these pairs of possibilities wll generate identical boolean results! Yes, I do. But given good definitions of "=" and "<" for a floating point type, applying my definitions will yield ">", "<=" and "<=" that are just as good. Defining "good" here is tricky, e.g. you are not supposed to use "=" for floating point, but rather something like abs (a - b) < epsilon * (abs a + abs b) > I can also easily see someone defining > or <= to mean something completely > different from comparison on a type for which comparisons make no sense > (For example <= looks a bit like an assignment ..._ ... if opertors could be procedures, or functions could have parameter modes other than in, but that happens not to be the case. Ada has quite a conservative philosophy on operator redefinition, why not stick to it ?