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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,4b26cf620424a3ff X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!b21g2000vbh.googlegroups.com!not-for-mail From: Gene Newsgroups: comp.lang.ada Subject: Re: Language Revision : "/" and "div" Date: Sun, 2 May 2010 14:33:14 -0700 (PDT) Organization: http://groups.google.com Message-ID: <9b002584-3f26-4bc0-bfb6-d8aac0aa9902@b21g2000vbh.googlegroups.com> References: <8aa58be8-a9b2-4653-8234-e5b6a70f310f@k41g2000yqb.googlegroups.com> NNTP-Posting-Host: 173.87.194.68 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1272835994 23568 127.0.0.1 (2 May 2010 21:33:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 2 May 2010 21:33:14 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: b21g2000vbh.googlegroups.com; posting-host=173.87.194.68; posting-account=-BkjswoAAACC3NU8b6V8c50JQ2JBOs04 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB0.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:11296 Date: 2010-05-02T14:33:14-07:00 List-Id: On May 1, 2:52=A0am, "vincent.diemun...@gmail.com" wrote: > Hi everybody, > > I wonder why Ada uses "/" to express the integer division and not > "div". > This leads to the fact that an expression like 4/3*6 that any decent > calculator > would evaluate as 8 is in Ada evaluated as 6 !!! That is a shame :-). > > Therefore, I propose the following, for a new revision of the > language : > - discard the function "/" (left, right : Integer) return Integer and > replace it by the operator "div", > that sounds quite logical with the existing "rem" and "mod". > - add a fraction package with a function "/" (left, right : > Integer'base) return Fraction; as constructor. > > Then when compiling "n : integer :=3D 4/3*6;" an error will occur, > because the result will be the fraction > 8/1 and not an integer. The sentence could then be changed in > EITHER=A0"n : integer :=3D (4 div 3)*6" that explicitly states that the > result will be 6. > OR =A0 =A0 =A0 =A0"n : integer :=3D Rounding (4/3*6); > > I think this solution is safe and will add simplicity and precision to > integer operations. > Moreover, this correct handling of integer computation will allow > compilers to make optimizations > like for instance simplifying expressions like "2/3 * n * 6 * i" -> > "4*n*i" > > Do you think I could summit this to the next revision of the > language ? > If yes, how ? > > Vincent [snip] I tend to agree that "div" would be better than "/" as a matter of truth in advertising. When Ada 83 was designed, many languages in common use would evaluate 2/3 as integer zero (FORTRAN, C, C++, later Java, ...). Pascal was alone, AFAICR, in providing "div" (Modula?). The "div" seems better than "/" for the same reason I generally like Ada for teaching new programmers in other aspects: it provides a clue that the most common meaning of "/", division over Real numbers, which people learn from from a very early age, does not apply here. Consequently it decreases by some small amount the probability that a second's inattention will produce a program bug, such as writing 2 / 3 * n instead of 2 * n / 3. It's harder, at lease for me, to write 2 div 3 * n without noticing the mistake. This aligns with Ada's consistency in id-as-value, in/out parameters, and other clean, orthagonal features that also reduce the cognitive leap between program text and semantics. OTOH, your suggestion probably can't be implemented because it invalidates so much existing code. Additionally, your version of Fraction isn't generally useful because 32- or even 64-bit N/D rationals overflow quickly under multiplication in most realistic settings, even if lowest terms are maintained by factoring out gcds. In practice, you'd need to use a numerics tower including bignums, such as Common Lisp does. Cheers.