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,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 Date: Thu, 08 Sep 2005 20:18:26 +0200 From: Georg Bauhaus User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Surprise in array concatenation References: <1125544603.561847.32140@g47g2000cwa.googlegroups.com> <4318486f$0$24154$9b4e6d93@newsread4.arcor-online.net> <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> In-Reply-To: <36f5y9ptjia3$.1onymsey119zw.dlg@40tude.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4320803b$0$24163$9b4e6d93@newsread4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 08 Sep 2005 20:17:32 MEST NNTP-Posting-Host: 4c55a5fc.newsread4.arcor-online.net X-Trace: DXC=gh\QLa?n?D>MXCiXZcgNO?:ejgIfPPld4jW\KbG]kaM8ea\9g\;7Nm52TNehM@Y0W5hP3YJKgE\j<>`G7FJk;8R4 X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:4534 Date: 2005-09-08T20:17:32+02:00 List-Id: 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 addresses a cell that is 000000000 at the start of the program, and the program sets it to 000000001 just once during the program's run, then, assuming regular operation, I know what happened. > I don't care about representations as long as they aren't the part of the > problem space (like in communication protocols.) Finiteness of computers happens to be one of the problems we are discussing. >>> type Unordered_Index is (A, B, C, D); >>> function "<" (Left, Right : Unordered_Index) >>> return Boolean is abstract; > > > if A < B then -- Compile error! What else you need? "Ordered" as per Ada's requirements for enumerations. For arrays (Ada arrays), I'd rather not have to think about *user* *defined* order of the index type when it comes to element change. > 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. >>>(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? >>Try to make this pass Ada compilation, >> >>type Unordered_Index is (A, B, C, D); >>for Unordered_Index use (A => 1, B => 3, C => 2, D => 4); > > > This has little to do with the order of Unordered_Index. It has a lot to do with Ada's notion of the order of enumeration literals (increasing). > 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.. Why should I impose *any* order on (Red, Green) when this type lists the colors of apples in my garden? I can very well construct my arrays using the predifined order. Incidentally, Haskell permits user defined sorting order (<) for types that are instances of type class Enum. Yet at the same time, you can request a default order by stating "derives Enum". Why should I redefine the order of Positive when using Ada.Strings.Fixed? >>>3. Note that (1) is wrong for modular types. >> >>And? > > > and you could not write a generic array algorithm both relying on (1) and > usable for modular types. My definition of "generic array algorithm" has limitations. Some are imposed by Ada. I'm awaiting your abstract array data type, same efficiency as Ada arrays, capable of making empty array objects using a one-enumeral index type, permitting compile time data layouts, safe indexing after index computations, perhaps dynamically changing their length, ... > 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. I'm trying to point out the *you* are talking evasively about special cases. Cases when there is a finite subset of mathematical items that can be represented inside a computer, element-wise or not. And this works in the special cases just because the problem to solve is really about finite sets, inside a computer. Whatever the finite sets represent in our interpretations, they are finite. If we need all umpteenth decimal digits in the expansion of Pi, we might or might not get them, depending on what umpteenth is, because any storage is finite. > There is no > class X'(42) for mod 10. Yet 42, now as an element of Z, is one of X'(2) > because 42=2(mod 10). Not "is", but "is represented" in an algorithm which is about equivalence classes, not about counting. "Package number 245345=5(mod 10) is malformed. So please look at package number 5." Huh? >>Belonging and congruence are not the same thing. > > > They are exactly same. It is how the set is defined. It's time for me to study Lewis Carrol's stories, to that I can legitimately refer to Humpty Dumpty. If there are 4 trees in a garden, there is really 1 tree in the garden, because of modulo 3. 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... > 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, e.g. storage. Therefore there exists a corresponding set, for each compiler + computer, outside the domain of pure math-think and inside the domain of computer- math-think. > (Taking too much C++ might be dangerous for your health! (:-)) What has C++ got to do with this? (Except that C++ programmers might be more aware of the limitations of the computer, because they have to take care of limits themselves? Because template recursion is usually limited to a certain depth, but OTOH template recursion becomes highly visible in error messages?)