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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f6c360ce344b2364 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.129.81 with SMTP id n17mr1218738bks.3.1341281152370; Mon, 02 Jul 2012 19:05:52 -0700 (PDT) MIME-Version: 1.0 Path: y28ni10722bky.0!nntp.google.com!news2.google.com!goblin3!goblin.stu.neva.ru!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: My Invention of "Bug Sort". Date: Mon, 2 Jul 2012 21:05:44 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3852c348-a728-44ed-b065-c8a596c1e235@googlegroups.com><698085ff-6ca3-4a0e-b963-11bdcf11e6b5@googlegroups.com> <1u9ig9nnen59q$.ajozwlsekr7l.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1341281149 10112 69.95.181.76 (3 Jul 2012 02:05:49 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 3 Jul 2012 02:05:49 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-07-02T21:05:44-05:00 List-Id: "Niklas Holsti" wrote in message news:a53o7tF6gfU1@mid.individual.net... > On 12-06-27 01:29 , Randy Brukardt wrote: >> "Simon Wright" wrote in message >> news:m2sjdnyrlh.fsf@pushface.org... >> ... >>> I notice http://www.ada-auth.org/standards/12rm/html/RM-A-18.html#p5 - >>> the last part of this is very terse. Wikipedia suggests that "(or both)" >>> should be added. But I'm still baffled; and this paragraph appears to >>> be >>> for users, not implementers! >> >> This is the definition of "strict weak ordering", it is described as >> precisely as possible. There's nothing really here for users; > > A user (programmer) using Ada.Containers and providing an actual Boolean > function for "<" must make sure that this actual function obeys this rule; > otherwise the container may not work as intended (as Randy said). So *in > principle* users need to understand this. > > The first three rules (with names, even more terse) are simple to > understand, because they are familiar properties from the usual complete > ordering of numbers and strings: > > - irreflexive: x < x must be False for all values x. > - asymmetric: if x < y is True, then y < x must be False. > - transitive: if x < y is True, and y < z is True, then x < z must be True > also. > > It is the fourth rule that is tricky, because it is important only when > there are incomparable (but different) values x and y for which neither x > < y nor y < x is True. If we use the symbol x # y for this > "incomparability" relation between x and y, the fourth rule can be stated > as: the relation # is an equivalence relation (a reflexive and transitive > relation). > > The reflexivity of # follows directly from the irreflexivity assumed for > "<"; the transitivity follows from the fourth rule for "<". > > For me, the rule "incomparability is an equivalence" is more intuitively > understandable than the formulation in the RM. The RM rule is easier to > state directly, however. That incomparability is an equivalence relation > comes out in the name of the function > Ada.Containers.Ordered_Maps.Equivalent_Keys. > > In practice, the fourth rule comes into play when the programmer-supplied > actual "<" function depends on only a part of the compared values, for > example, on only one "key" component of a record type. If two record > values x and y have the same key, x.key = y.key, then neither is "<" than > the other, but they can still be different if they have different values > in their other components. > > *In practice* I expect most programmer-supplied "<" functions will compare > one or a few "key" components of the operands. As long as each invocation > of "<" compares the same components of the operands, in the same way, > giving a complete ordering of these component values, the fourth rule > holds and the container should work. So perhaps most users can get away > with ignoring this rule. Thanks for the detailed and complete explanation given above. For the rest of you, Niklas was the person who reported that the rule given in the Ada 2005 RM was insufficient. Thus we had to add the "strict weak ordering" rule (and definition) given in the Ada 2012 RM. It shouldn't be surprising that he understands it better than I do. ;-) Randy.