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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,db88d0444fafe8eb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!news-xfer.newsread.com!news-out2.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!newsfeed.freenet.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Surprise in array concatenation Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1125544603.561847.32140@g47g2000cwa.googlegroups.com> <43187a50$0$24162$9b4e6d93@newsread4.arcor-online.net> <11p5i525v2q5d$.17ayuwvqhazo1.dlg@40tude.net> <431a00cb$0$2113$9b4e6d93@newsread2.arcor-online.net> <9s72daxfzb4f.1k7noh1qr5qpg.dlg@40tude.net> <431c465d$0$24150$9b4e6d93@newsread4.arcor-online.net> <79fcfodixv3k$.1m7d28joczncs$.dlg@40tude.net> <431c8c35$0$2101$9b4e6d93@newsread2.arcor-online.net> <3ufj318nkubi.a5j4dbvaofhc.dlg@40tude.net> <431d82e3$0$24147$9b4e6d93@newsread4.arcor-online.net> <431dbabc$0$24153$9b4e6d93@newsread4.arcor-online.net> <1b8825x3b8wn3.24qm946raz3d$.dlg@40tude.net> <431f2f4f$0$2102$9b4e6d93@newsread2.arcor-online.net> <3sa7ilukre24.15c984skqvm9c$.dlg@40tude.net> <432011f0$0$24147$9b4e6d93@newsread4.arcor-online.net> <36f5y9ptjia3$.1onymsey119zw.dlg@40tude.net> <4320803b$0$24163$9b4e6d93@newsread4.arcor-online.net> Date: Fri, 9 Sep 2005 12:06:02 +0200 Message-ID: <1b3z0hyoyma05.ptmdp4uq8e3j$.dlg@40tude.net> NNTP-Posting-Date: 09 Sep 2005 12:06:06 MEST NNTP-Posting-Host: 3fb8148c.newsread2.arcor-online.net X-Trace: DXC=BD\BD^U?1mWfnCoe<@CEZ^Q5U85hF6f;TjW\KbG]kaMXQ>n?D9BSA]\K=fR<:5ghhPWRXZ37ga[7Zn919Q4_`VjYB8=X\UUgbkT X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:4550 Date: 2005-09-09T12:06:06+02:00 List-Id: On Thu, 08 Sep 2005 20:18:26 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > >> Note that A=1 from the problem state is not a bit pattern. It is a set of >> computational states for which A is considered be 1. So when you make a >> memory dump and discover a bit pattern 000000001 at the address FF07712CA0 >> that tells absolutely nothing. > > A dump might tell me a lot provided I know what kind of dump it is and when > it happened. Depending on the algorithm, for example, if FF07712CA0 ^^^^^^^^^^^^^^^^^! >> If some day Ada will >> have abstract arrays, then "for I in A loop" should iterate it in the order >> of the Index, and not in the arbitrary one of Index'Pos. > > Please, could you stop naming this ADT an array? It has so many > more assumptions that it deserves a distinguishing name! > For example, you could have holes in your index type, IIUC. Try to define "hole" in terms of ADT, maybe then you'll understand the problem better. >>>>(For generalizations on unordered cases see "convex hull") >>> >>>I'm trying to see arrays, and possible improvements. If a convex hull >>>offers something useful >> >> Believe me, convex sets (whether (1-t)a + tb belongs to the same set forall >> 0<=t<=1) are extremely important for countless numeric methods, >> computational geometry etc. > > I'm curious. How does this relate to array indexing? The index ranges need to be convex if you want to have your "length / 2". The above is the definition of a convex set. >> The representation >> clause defines representation. You should never mix: >> >> 1. The user-defined order and other operations (like +, -) and literals >> from the problem space; >> 2. The positions of discrete values; >> 3. The representations of discrete values. >> >> These all are different things. I hope it is clear that algorithms should >> be written in terms of (1)? > > I can't imagine non-DK-array algorithms are usually written in terms > of (1) (*user-defined* sorting order of the index types). > These are Ada arrays, rock solid low level stuff, based on preexisting > contracts inherent in enumeration order or Positive's order, etc.. Ada was designed as a higher level programming. If you want an assembly language, there are plenty of them... >> You again mixing sets and elements of. 42 is a literal. In the case of >> equivalence classes it denotes not a number (Z) but a class of. > > I'm not mixing sets and elements, I'm pointing out that symbol manipulation > and counting are sometimes different. Care to show a difference? > It's time for me to study Lewis Carrol's stories, to that I can > legitimately refer to Humpty Dumpty. It is always a good reading. Though any introductory book on modern algebra could also help. > If there are 4 trees in a garden, there is really 1 tree in the > garden, because of modulo 3. You still missing the point, and still mixing apples and oranges. It is not 1 tree, it is a class of equivalence: { 1 tree, 4 trees, 7 trees, ...}. 4 trees (a set!) is in this class (a set of sets!) which you have denoted as 1 (a number!) > BTW, was that modulo number the class > representative 3 or the number three or the symbol 3? Oh well... > Meanwhile the apples and plums below the 3 other trees start to rot. > Time for a depressing garbage collection... Those are philosophical questions. As a follower of Plato, you should address them to his philosophy. In the philosophy I adhere they are just meaningless. >> The type of the >> cardinal numbers in Ada is defined as Universal_Integer. >> It is not the type of the elements in a set! > > Universal_Integer is subject to capacity constraints, And what's the point? This or that way, but Universal_Integer is a type different from one of array index. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de