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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.252.6 with SMTP id zo6mr24186965pac.40.1411845691662; Sat, 27 Sep 2014 12:21:31 -0700 (PDT) X-Received: by 10.140.33.161 with SMTP id j30mr253956qgj.4.1411845691313; Sat, 27 Sep 2014 12:21:31 -0700 (PDT) Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!a13no4581999igq.0!news-out.google.com!i10ni40qaf.0!nntp.google.com!v10no46130qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 27 Sep 2014 12:21:31 -0700 (PDT) In-Reply-To: <3489504a-f82b-4fec-8a6c-7cb91854dd1e@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=91.55.247.18; posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf NNTP-Posting-Host: 91.55.247.18 References: <98f0066e-4b5c-4b00-b811-dcbb13ed0fcf@googlegroups.com> <3489504a-f82b-4fec-8a6c-7cb91854dd1e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <767f35d1-20ed-4726-8adc-742f5f15671d@googlegroups.com> Subject: Re: Integers and Mathematical Correctness From: AdaMagica Injection-Date: Sat, 27 Sep 2014 19:21:31 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: number.nntp.dca.giganews.com comp.lang.ada:189194 Date: 2014-09-27T12:21:31-07:00 List-Id: On Saturday, September 27, 2014 8:20:32 PM UTC+2, Adam Beneschan wrote: > It may choose it for *one* of the operands, depending on whether these functions are directly visible: > > function "+" (Left : Rational; Right : Integer) return Rational; > function "+" (Left : Integer; Right : Rational) return Rational; > > Actually, if either of those is visible, then there is more than one way to > choose the meanings of "+" and "/" to form an acceptable interpretation. > Because of this, the expression would be treated as ambiguous, and the > compiler would reject it. Exactly that's my point, the compiler will reject it. (You're right, the result is not 0, the compiler rejects the code. My error!) With Integer, there's always visible with preference function "/" (Left, Right: Integer) return Integer; which will ruin 1/2 + 2/3, because your two functions above are there. Thus these interpretations are possible, which the compiler cannot resolve: Rational + Rational = Rational Integer + Rational = Rational Rational + Integer = Rational So you have to remove the integer division, which is only possible for a new type Whole: overriding function "/" (Left, Right: Whole) return Whole is abstract; Now everything can work. There is of course no function "+" (Left, Right: Whole) return Rational; So in short: The crux is not rational numbers combined with themselves, but mixed arithmetics (i.e. rational and whole). So I still do not believe that you can do mixed arithmetics with rationals constructed from Integer: function "+" (Left: Rational; Right: Integer ) return Rational; function "+" (Left: Integer ; Right: Rational) return Rational; function "+" (Left: Rational; Right: Rational) return Rational; "/" (Left, Right: Integer) return Rational; -- constructor "/" (Left, Right: Integer) return Integer; -- from Standard You cannot hide the last function! [OK, you can make 1/2 + 1/3 work by qualifying the functions, but that's not the point (and extremely ugly.]