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: a07f3367d7,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,BIG5 X-Received: by 10.180.76.115 with SMTP id j19mr4600366wiw.2.1369279542808; Wed, 22 May 2013 20:25:42 -0700 (PDT) Path: hv6ni10057wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Thu, 16 May 2013 15:54:13 +0200 Organization: cbb software GmbH Message-ID: References: <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> <1oy5rmprgawqs.1jz36okze0xju$.dlg@40tude.net> <1q2ql1e4rcgko.diszzq1mhaq8$.dlg@40tude.net> <518dedd4$0$6581$9b4e6d93@newsspool3.arcor-online.net> <1um7tijeo609b$.1gtdijp0acfmn$.dlg@40tude.net> <1nkyb845dehcu.1sd90udwsrpdu.dlg@40tude.net> <1mg9eepp12ood$.14lj7s8a7eygd$.dlg@40tude.net> <1cj8b5amtua30.1foe0rdpldt2.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit Date: 2013-05-16T15:54:13+02:00 List-Id: On Thu, 16 May 2013 09:10:11 -0400, Peter C. Chapin wrote: > On Thu, 16 May 2013, Dmitry A. Kazakov wrote: > >>>> So, >>>> >>>> X, Y : Driver; >>>> >>>> have same values? >>> >>> Yes, I would say so. >> >> Really? X is an *equivalent* of Y? > > Sure. If it were allowed the expression 'X = Y' should return True. If X��Y, you don't need two instances of. > I realize that equivalence of functions is a difficult concept in general There is nothing difficult in that. A function is a set of pairs. Two sets are equal when contain same elements. > X and Y above of course may contain different state information as they > run but that's all related to the operation of execution; it doesn't > distinguish their "task values." Of course it does. For example: it can happen that X'Terminated /= Y'Terminated. >> Because the literal 2 [of type Integer] denotes the same value in all >> contexts. But X, Y : Driver clearly do not do that. If X and Y are not >> equivalent how they could have the same value? > > I guess this is where we disagree. To me X and Y do denote the same value > in all contexts; they are equivalent. They are evidently not, which can be easily demonstrated by presenting a program which would yield different results depending on whether X or Y is used. >> Either the values are different or else you need to bring some other >> stuff beyond types, values and operations into the picture. > > Are you referring to the execution state here? It is your concept, I am only giving you enough rope to hang yourselves... > To my mind that dynamic > information is just part of the operation of execution. It's necessary to > make that operation work but, yes, I agree that it is a separate matter > from the types and values, etc. Which means that your model is inadequate to describe the way programs work, and more generally to programming. >>>> e : constant := >>>> 2.71828_18284_59045_23536_02874_71352_66249_77572_47093_69996; >>> >>> As I understand it, 'e' has type Universal_Float and the 2.718... is a >>> value inhabiting that type. I guess I don't understand what point you are >>> making here. >> >> The point is about the value of e. You said that when declared as I did, it >> has no significance, just a random pattern of bits. Do I interpret you >> correctly? Does this same logic apply to e of Ada.Numerics? If not where is >> a difference? > > We're talking about two different 'e's here. In the first case 'e' was an > enumeration literal. The type in that example was suggestively named > Transcendental_Constants (or something like that... I forget exactly), but > any connection between 'e' and the mathematical value of e was purely in > the mind of the programmer. How Universal_Integer is different? > In Ada terms 'e' was a value of that type but > nothing beyond that. That's what I meant by it not having any > significance. > > In the second case 'e' is a named number bound to a value in the > Universal_Float type that is clearly intended to be the mathematical e... How it is more "clearly intended" than enumeration 'e'? Note that neither is mathematical e. They *model* e = as you said "purely in the mind of the programmer." This is what value is, an idea behind a computational state. > at least to the closest degree permitted by the available values in that > type (I guess in this case it's really limited by the amount of space the > implementer wants to use when writing the declaration. Am I correct in > saying that Universal_Float has infinite precision?) It has an indefinite precision. > I suppose I don't understand the point you were trying to make originally > with the enumeration type. There 'e' was a value of the specified type. > Was that it? The value of e was meant to represent the transcendental number e. The type was meant to model real numbers. Similarly Ada.Numerics e is meant to represent e. And Universal_Real is meant to model real numbers. e is not Ada term. It is a term of mathematical analysis. Neither type is real, they are only models of. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de