Re: Larger matrices

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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