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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Received: by 10.180.107.167 with SMTP id hd7mr2025874wib.0.1345487995558; Mon, 20 Aug 2012 11:39:55 -0700 (PDT) Path: q11ni229694061wiw.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!94.232.116.11.MISMATCH!feed.xsnews.nl!border-1.ams.xsnews.nl!plix.pl!newsfeed2.plix.pl!news.mi.ras.ru!goblin3!goblin1!goblin.stu.neva.ru!noris.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 17 Aug 2012 20:41:10 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <44bb5c96-a158-41c1-8e7d-ae83b2c0aca1@googlegroups.com> <1mchat48i3fos.1ksbz02nuzf5f$.dlg@40tude.net> <502b832f$0$6579$9b4e6d93@newsspool3.arcor-online.net> <502bc4df$0$6574$9b4e6d93@newsspool3.arcor-online.net> <502bd3e6$0$6574$9b4e6d93@newsspool3.arcor-online.net> <17qgsq5y7or0v.16z18fmcew1lt$.dlg@40tude.net> <502c149e$0$6579$9b4e6d93@newsspool3.arcor-online.net> <502cd701$0$6568$9b4e6d93@newsspool3.arcor-online.net> <502d3c68$0$6572$9b4e6d93@newsspool3.arcor-online.net> In-Reply-To: Message-ID: <502e9039$0$6557$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 17 Aug 2012 20:40:57 CEST NNTP-Posting-Host: ea91a43d.newsspool4.arcor-online.net X-Trace: DXC=Mjh_Sldb>hDgj[ZPFj7ehO4IUKJLh>_cHTX3jMA804I?DQO0H X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2012-08-17T20:40:57+02:00 List-Id: On 16.08.12 21:58, Dmitry A. Kazakov wrote: >>> 1. state the problem >> >> Heterogeneous sources of data. (E.g. Teletext there + XML there) > > If sources of data is a problem, then the data format cannot be a solution. OK, that's a different if. > Problems with sources are solved by choosing other sources or other means > applied to the sources. "Problems with the distance Earth:Mars or problems with the temperature on Mars are solved by choosing others planets or other means applied to the planets." No. Problems with sources are actually solved by the sources becoming different from what they were before. It's a market effect. Customers make suppliers make different sources. >>> 2. present relevant criteria to evaluate a solution >> >> Situational, given, as mentioned, e.g. integration of data. > > Sources are selected using criteria describing these sources, e.g. > relevance, trustworthiness, independence, accuracy, extent, availability, > QoS, etc. > > [ Criteria of choice are always immanent to the thing in question ] The thing in question is a situation. It is characterized by several variables. One variable measures the qualities of the data sources. >>> 3. present competing solutions > 1 (proving them solving the problem) >> >> Given. (E.g., what has been done a few times: move from Teletext >> to CSV to XML) > > No. Yes. XML can be quite an enhancement when the problem is heterogeneity of sources. This is how people *have* solved problems of integrating data. If you cannot present a good reason to sell your data in some standard form, as a result creating work for others, you're out. > Sources of data in a car are sensors. Yes. BTW, even though there are many types of sensors I'm sure, they all are sensors; depending on distance, then, the observer will place them on a scale between homogeneous ("Hey, everything is a sensor here!") and heterogeneous ("Dude. This one works with gas and heat, but that one uses pressure!") >>> You seem to imply that fuzzy logic (in its scientific meaning) acts >>> differently from crisp logic by allowing any sorts of non sequitur. >> >> No. There is a point when switching data formats to something >> general like XML is considered by some programming projects. >> This point is found in [0, 1] ⊂ R. A Yes (1) or No (0) is really >> the consequence of a final preference and this preference's value >> need not be 0 or 1. > > It does not make any sense to me, but since it seems irrelevant anyway, be > it so. It is the important bit. The situation (let me call it "a programmers' situation", because it is observed from the point of view of the programmers) is characterized by inputs and outcomes. An outcome is a decision, in this case, viz whether or not time should be spent on XML. Some inputs are technical: - this device has an 8bit wide output port and it spits 13+1 octects and then 2, on request. It does nothing else. Others are domain specific: - "We must have something to send to the publisher. They want..." Others are economical: - The high speed RDMS style data collection will cost $$$$$$. Others are "people driven": - Pointy head boss speaking. Etc. These and other variable characteristics of a programmers' situation all create inputs that find more or less appreciation during the decision process. Then, finally, the pointy head boss says "We shoud do XYZ." Consequently, Choice(XYZ) = 1 as the outcome of the situation, for everyone, even when pointy head boss is not fully convinced. He may privately value Choice(XYZ) at somewhere < 1. > What is "heterogeneity of data" and why should it be tackled? Data of different kinds, different along several axes as seen by the respective "data processors". An algorithm computes results from several inputs. If "processors" need to process many differences, if higher order "processors" need many "processor hands" to get compatible inputs, then this complicates the coordinated processing. It also costs more time and money. > Are you talking about "tackling" documents? What sort of documents? The > time diagram of the ignition impulses at the degree angles of the driving > shaft? GPS maps of the navigation system? Traffic rules and regulation? More generally, if an algorithm needs to find information in "documents" emitted from diverse sources, searching requires assigning meaning to messages contained therein. The processes of isolating messages may differ greatly, at several stages of processing. >> Its bits and pieces were partially documented. This was enough >> to write a crude scanner. With XML, I can at just read >> the stuff and see some familiar vocabulary being used. Done. > > Nothing is done. Compare ....B..... to ....123.4567.... > I gather the case for car electronics is closed now? >From my point of view, we didn't have a case since XML would not be needed in any way I could imagine (other that this small customer car info server thingy). >>> B) methodic of its evaluation >> >> Multivariate analysis of those variables of the programming situation >> that lead to a decision about data formats. > > No, the methodic of evaluation a measure of similarity of the "motivating > factors." Methods? Here are two simple methods that do not always work: - [all equals] Majority vote. - [consultation among equals] For each pair (Pi, Pj) of people who contribute to the decision, two things are of the same kind if Pi and Pj find them to be of the same kind. If i,j ∈ {1, ..., N}, then let similarity of things be the proportion of agreements in (N choose 2). The P could be experts from different fields. (Note: for triples (Pi, Pj, Pk), science has found that if Pi and Pj agree, but Pk does not, then in most cases Pk will not uphold disagreement if pressured by Pi and Pj.) Whether or not Pi and Pj agree might be influenced by unalterable properties of the things in question if found. Note in particular that---a priori---there is no way to say that two things are equal, or similar, or of the same kind before they have been shown to be, and in which way. Are the balls of a bearing equal? Are they homogeneous/heterogeneous? The answer to the latter question may depend on the identities of the bearings involved, if you ask a technician, I think, and possibly on who you ask. For more, and for more realistic function procedures resulting in decisions, see the description of the programmers' situation above. >>> D) comparison to competing solutions >> >> See above, and everything said so far. > > No, you should show that for XML "motivating factors" are more similar or > dissimilar I see. A misunderstanding, I think. Dissimilarity has motivated preferring, and possibly choosing XML, in order to tackle dissimilarities. Like heterogeneity has motivated establishing the HOWLG at least in one way, I think.