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,19924f2facf8443 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Larger matrices 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: <40ed91c2-3dab-4994-9a7b-4032058f0671@56g2000hsm.googlegroups.com> <96f76821-fc2a-4ec1-83e7-b7b9a5be0520@r66g2000hsg.googlegroups.com> <9cabee20-877a-4fdc-80f8-7746879331da@8g2000hse.googlegroups.com> <489a9675$0$20718$9b4e6d93@newsspool4.arcor-online.net> <75a339dd-969b-4c7a-8e89-7b640171bc2f@e53g2000hsa.googlegroups.com> <13426f2d-0060-47f0-8139-09506383f648@e53g2000hsa.googlegroups.com> <489c2f68$0$1060$9b4e6d93@newsspool3.arcor-online.net> <489c542e$0$12944$9b4e6d93@newsspool2.arcor-online.net> <1d0ueuhuo8z2e.ewzvifms2lau$.dlg@40tude.net> <489c68e1$0$12941$9b4e6d93@newsspool2.arcor-online.net> <1ernhelikct1f$.phk7n6xktz5h.dlg@40tude.net> <489c844b$0$12953$9b4e6d93@newsspool2.arcor-online.net> Date: Fri, 8 Aug 2008 21:51:49 +0200 Message-ID: <1xouarvkb0dop.d7igbk8rqak2.dlg@40tude.net> NNTP-Posting-Date: 08 Aug 2008 21:51:50 CEST NNTP-Posting-Host: 36731259.newsspool2.arcor-online.net X-Trace: DXC=W\Dc8af6=OXHigV@eW57PQA9EHlD;3YcR4Fo<]lROoRQ4nDHegD_]RU`4FTSWX=_^PDNcfSJ;bb[UIRnRBaCd On Fri, 08 Aug 2008 19:37:15 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov schrieb: > >>> A systems programming language must provide for the low >>> level. >> >> Nope, it must provide systems programming domain abstractions. Ada does >> this. This does not make it low-level. > > The systems programming domain abstractions are fairly > low level. Why? Low relatively to what? > But tasking is > far from describing the entirety of Ada. You can have the same > tasking offered with much higher level PLs. Synchronization mechanisms of higher level than Ada? I am excited. You mean semaphores, I bet. Please, show us that fancy language and also how tasking there is integrated into other "higher-level" language features. >> 1. Considering hardware as the environment. Ada running on an Ada-hardware >> (if such existed) [...] >> >> 2. Considering programming paradigms as the environment, i.e. the terms in >> which programs are thought an composed. Ada is again very high level, as it >> supports up to 3rd set abstractions: >> >> value -> type (sets of) -> class / generic (sets of) > > Wow, "value -> type (set of)" sorts assembly languages > just one tiny bit below a type safe generic O-O language: imul / fmul. Assembler does not have user-defined types. In the hierarchy above all elements are user-defined. Assembler has only user-defined values. I.e. it is only at 1st set abstraction. > There is no EVAL or COMPILE in Ada. Assembler has them. > There is no goal directed evaluation. I saw this term only in the context of low-level image processing primitives. Sorry, it rings wrong bells. > There is no function environment (no upward closures). Procedural composition is itself low-level. Ada need not to worry about that low-level stuff. > There are no generators with suspension. Hydropneumatic suspension? Sorry. > There are no comprehensions, no infinite data structurs. These structures are inconsistent. > There is no symbol manipulation, no expression macros, no inference. Symbol manipulation is text processing, no problem in Ada. Macros is low-level source text processing. We don't need that. Elaborated inference is inconsistent with maintainability if not low-level. Namely, if inferred things are understandable, they are trivial. If they are non-trivial (as in Prolog), then nobody can predict the program's behavior. My favorite example is AI. Healthy man and woman need no PhD degree in order to create an intelligent system. That is a case of "inference." And it does the job, alas with a totally unpredictable outcome. Why in your opinion do people write tons [of mostly useless] scientific articles on the AI issue? They want to have it imperative! Furthermore, complexity of inference is unrelated to the abstraction level. There exist both very complex and very low-level things. > There is no higher order anything. ? > There are no solvers. Because Ada programs solve non-trivial problems. Anyway, declarative is not a synonym of higher level. "Fly to Mars" is higher level than "I like cheese." > There are no graphics primitives etc.. Turtle graphics must be of an extremely high level... You are making an error equating domain-specific to high level. It is usually reverse. Domain-specific languages are of very low level, because they translate straightforwardly into the engine, which plays the role of the hardware. This is low-level. Note that due to the limitation of the application area and because domain-specific abstractions are quite rough and irregular, such languages usually do not provide any higher level abstractions. For example, OpenGL is of 1st order. You cannot define new graphic primitives. You cannot bundle graphic primitives into generic sets of, etc. Describe a set of tables sharing some property in SQL. Declare class of rhombus-like inheritance graphs in UML. In terms of abstraction level, most of domain-specific languages stop where FORTRAN-IV began. That's why there is no 5GL, 6GL, 7GL... The idea was wrong. > But does a shared variable mechanism lift Ada to the level of > languages such as APL (which tends to have it, too)? I don't know its newer versions. Initially it was very low-level, 1st set abstraction, in the classification above. >> No chance. O(N**2) is only memory complexity. You should also consider the >> number of operations required per element. Naive matrix multiplication is >> O(N**3). Factor 10 means (N x 10)**3 thousand times slower! And this is >> only the lower bound. But all this is in order learn that the fancy >> language X is greatly slower than Ada and is totally unsuitable for >> production code? I know it in advance! >> > > You can write an algorithm operating on matrices > in O(Absurdly High Degree). The original question was about > vector product where one operand is a row of a matrix. It was matrix multiplication, I guess. > Use a language that allows you to say, > using *builtin* operators, things like > > "Give me all blocks of neighbours no more than two edges apart." > > That's high level. procedure Give_Me_All_Blocks...; This is not high level, and I know the price. Domain-specific languages are usable in domain-specific cases ... and unusable universally. In my area of professional interest we are forced to fight with various domain-specific languages on the daily basis. I have reasons to dislike them. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de