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!newspeer.monmouth.com!news-FFM2.ecrc.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Wed, 07 Sep 2005 20:20:56 +0200 From: Georg Bauhaus Organization: future apps GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050718 Debian/1.7.8-1sarge1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Surprise in array concatenation References: <1125544603.561847.32140@g47g2000cwa.googlegroups.com> <14muavojz308w.1ouv7xin79rqu$.dlg@40tude.net> <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> In-Reply-To: <1b8825x3b8wn3.24qm946raz3d$.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <431f2f4f$0$2102$9b4e6d93@newsread2.arcor-online.net> NNTP-Posting-Date: 07 Sep 2005 20:19:59 MEST NNTP-Posting-Host: 36f2d167.newsread2.arcor-online.net X-Trace: DXC=Z1MmS4C]\Mc<_V8dMIHdjhQ5U85hF6f;djW\KbG]kaMhQ>n?D9BSA]lIcZEZ5TEUQnljUVjRQ60?bVmnOeiOY3@ng[50F7T5IOb X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:4504 Date: 2005-09-07T20:19:59+02:00 List-Id: Dmitry A. Kazakov wrote: > On Tue, 06 Sep 2005 17:51:11 +0200, Georg Bauhaus wrote: >> How does this violate Ada's >>contracts? >>A contract is not necessarily simple, nor without deliberately >>chosen limitations. > > Arbitrary limitations you mean. I won't accuse the designers of Ada to have placed arbitrary limitations on things. > Nope. You confuse sets and elements. Any infinite subset of R (and R > itself) cannot be represented by *specifying its members*, because they > aren't countable. > But any real Almost no real number can be represented in a computer. > and any finite real subset can. Only a small subset of the subset of finite subsets of R can be represented in a computer. > The domain set of a type need not to be countable. A computer type needs to be countable, otherwise you will run into computability trouble. > Did you ever use all > possible values of Integer? Yes. And if this hadn't happened before there were no wrap-around stories. [more integers] > Would it change anything for you? Not in a well designed program! That's true of well designed A'First-based algorithms, too. > Note an important point of Ada design, as opposed to may other languages. > In Ada you specify what kind of values you are going to use. You say: > > My_Integer is range 0..100; > -- I don't care about other integers > My_Float is digits 8 range 0.0..100.0; > -- I don't care about reals outside and in between > > This is the right way to handle uncountable things without inventing any > new "computer" mathematics, This is *precisely* where newly invented computing mathematics is at work! The theory of floating point computations covers finite approximations. It doesn't matter whether computations are done on paper, or inside a computing machine. Computer mathematics provides the theoretical tools for reasoning about numbers that are not reals, but are used in computations that people would like to be performed in R, but that cannot be performed in R. Once again, if you think you can get by with a finite subset of R, I suggest that you try the fly-hits-windshield example. One value of the computation will be very, very small. The other value will be comparatively large. Still you have to use both in the same "formula". There is a good chance that both together simply won't fit inside our computing machines. (Whether or not this matters in practice is a different issue; here a finite approximation suffices. But forget about real numbers.) >>>LOL! Any program represents anything symbolically. >> >>No, an executing program has an interpretation. >>This makes "representing" have a meaning. > > > And meaning is represented by what? (:-)) As I said, HALT is the limit, and we have to agree on something. You can of course argue that operational semantics is useless. >>>Do you really believe >>>that 1 is *the* 1? Did you see a label "made in Heaven" on it? (:-)) >> >>Type Positive starts at 1 and ends with Positive'Last. > ... and it does this not symbolically, but physically yes. > by attaching a tiny > rubber thread to the Platonic number 1. Right? (:-)) no. > You are trying to formulate some generic algorithm which does not work for > all index types. My algorithm should work for arrays, using properties of arrays. A'First .. A'Last, where A'First > A'Last works well in loops. When are you interested in computing the value half-way between the ends of a (non-numeric) enumeration type, attempting to use A'Length / 2? > This is why it is so important to have a consistent model > of indexing and arrays. It is important to be consistently using the proper type of arrays in algorithms made for this type of arrays. > For an unordered [index] type X it is wrong to > assume that: Can there be an index type in Ada that isn't ordered? > 1. If L in X and U in X then there is always M in X between L and U > 2. That M can be computed as (L+U)/2 You can't usually compute M when X is an enumeration type. Otherwise, if A'Length <= 1, then (L+U)/2 = 0 = M. Thus, M can be computed but is not necessarily between L and U. Anyone who thinks like Ada suggest (and Eiffel, and C++, and ...), and who isn't mislead by DK's incessant subservience to some field of mathematics, is _not_ surprised. */2 can be found in just about and textbook on algorithms. I'll concede that your ideas might be interesting for use in a data structure that is not an array as people know it around the globe. > Examples: hash map, variable length string map etc. Aha!