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,5c89acd494ea9116 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!62.111.101.3.MISMATCH!news.germany.com!news.belwue.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Self pointer in limited record Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.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: <1183577468.034566.57830@n60g2000hse.googlegroups.com> <1188578849.187422.280620@50g2000hsm.googlegroups.com> <9fy1xoukz1e3$.h574sqmiauri$.dlg@40tude.net> <46d968ee$0$30368$9b4e6d93@newsspool4.arcor-online.net> <137iu0lr82dtb$.wqy3zjz2vr9q.dlg@40tude.net> <46d972e8$0$30384$9b4e6d93@newsspool4.arcor-online.net> <1alyfwaig93sk$.99oy269uon$.dlg@40tude.net> <46d9c138$0$4531$9b4e6d93@newsspool3.arcor-online.net> <1rt8kdcrj6tf.1qgvycc6vh357$.dlg@40tude.net> <46db2bf4$0$7699$9b4e6d93@newsspool2.arcor-online.net> <1188816674.2630.25.camel@kartoffel.vocalweb.de> <9cdmw7k85sey.85sb2t1bjefy$.dlg@40tude.net> <1mbajw59c3eir.jyl8bdp6qvj8.dlg@40tude.net> <1188850449.2630.60.camel@kartoffel.vocalweb.de> <1aza6nzawgcnm.sf76q4dvzw4n$.dlg@40tude.net> <46de8897$0$16115$9b4e6d93@newsspool1.arcor-online.net> <15hzyyy3soem0.12hn79bwy27zt$.dlg@40tude.net> <1189017071.2630.246.camel@kartoffel.vocalweb.de> Date: Wed, 5 Sep 2007 21:52:34 +0200 Message-ID: NNTP-Posting-Date: 05 Sep 2007 21:52:04 CEST NNTP-Posting-Host: 0de02c24.newsspool3.arcor-online.net X-Trace: DXC=V3^hMcF=Q^Z^V384Fo<]lROoR1^;5]aA^R6>2kEV?<[ On Wed, 05 Sep 2007 20:31:11 +0200, Georg Bauhaus wrote: > On Wed, 2007-09-05 at 14:04 +0200, Dmitry A. Kazakov wrote: >> and you have to fix the point of view before you start to talk about >> *an* abstraction. The abstraction can be "dog" or it can be "named thing," >> but it cannot be Spike. > > I fail to see why Spike the dog cannot become an abstract entity > of a program. > My perception of Spike can be that of a "named thing" > with some details abstracted away as I see fit. > Assuming a name doesn't turn a thing into atomic information > without properties and without behavior. There exist no information without "behavior." Information is meaningless in absence of receivers. If Spike barks there is at least a tree here to be barked at. Barking in vacuum does not work. >>> Abstraction as a process can be fuzzy, I known you are familiar >>> with that? >> >> If you want to refer to fuzziness and other measures of uncertainty, then >> carefully observe that these always brings multiple concurrent choices >> with. > > For example the programmer's choice could include alternative > points of view, suggested by the problem description. Each viewpoint > can yield a slightly different abstraction when the resulting > interfaces, say, are a consequence of more or less emphasis on > some of the dog's characteristics. Yes you can have a set of abstractions and some confidence measure attached to each. The idea of probability et all theories is that all these outcomes, events, "focal elements" etc coexist. You cannot prefer any of them for certain, as you cannot say odd or even before the coin falls. This cannot be trivialized to certainty. So any model and whatever it predicts, always boils down to a distribution of confidences and stops there. >> You simply cannot define either probability or possibility or >> whatever else measure on a singleton substrate without trivializing it to >> the crisp case. This is non-starter. > > I have to ask whether by singleton substrate you mean > something in the problem description that states one and only > one possible quality of a thing. That'll beg the question, of course. If you have only one elementary outcome then its probability is trivially 1. You need a surface to smear uncertainty on... (:-)) >>> There are other sources, not dealing with Ada specifically, >>> but mentioning the use of Ada packages for this. >> >> So what? I don't see any connection. How using ASM as an adjective to the >> word "package" could define either? > > Why define Ada packages in terms of ASMs or vice versa? I didn't do that, not my idea. >> The point was "to have one instance" and "to be a FSM" are unrelated. > > There is a point of view from which the concept "to have one instance" > and "to be a FSM" are unrelated. When writing an Ada program, you may > have a point of view from which the concept "to have one instance" and > "to be a FSM" coincide on a suitable conceptual level. It is the level > on which an abstract state machine package is explained. Can I take a protected object or a task to implement either? (I have no respect to singletons. They might have some sacral meaning for some OO proponents, but that was always beyond my understanding.) >>>>>> But an *abstract* state >>>>>> machine is definitely a type that generalizes many concrete state machines. >>>>> By what definition of type is an ASM a type that generalizes many >>>>> concrete state machines (=what, in Ada terms?)? >>>> >>>> type State is (...); >>>> type Transition_Relation is array (State, State) of Boolean; >>>> type ASM is private; >>>> function Create (Initial : State; Wiring : Transition_Relation) >>>> return ASM; >>>> procedure Step (Machine : in out ASM; Input : State); >>>> >>>> This machine is abstract because its wiring is a parameter (abstracted). >>> >>> Hm. A singular parameter as a source of abstraction ... not a plural ... >> >> Plural is addressed to the set of values of that type. > > So abstraction is all about starting at some type and then > saying the thing using parameters of the type is abstract > because each parameter will be of a yet unknown concrete kind? > Seems like a narrowed view of abstraction. It is not the whole view, just a necessary component of: "one for many." You can have it with variable vs. values, type vs. values+operations, sets of types vs. types (classes/generics). I don't object when "many" is in the problem domain and "one" is in the solution one. It is an abstraction too, but not so interesting as others. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de