Re: Larger matrices
- From: Georg Bauhaus <rm.dash-bauhaus@xxxxxxxxxxxxx>
- Date: Fri, 08 Aug 2008 19:37:15 +0200
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. Please, fairly. Yes, there are some higher level
abstractions, like the whole of tasking is. But tasking is
far from describing the entirety of Ada. You can have the same
tasking offered with much higher level PLs.
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.
No constructionist shuffling of artificial categorization frameworks
will convince me that Ada is not a systems programming language.
C++ is one, too. (For another example, Erlang is reportedly good
if helped by a FFI.) And Ada is a rich set of fairly low-level
features. (I am not away of an 'Address mechanism in ML (without FFI).)
There is no EVAL or COMPILE in Ada.
There is no goal directed evaluation.
There is no function environment (no upward closures).
There are no generators with suspension.
There are no comprehensions, no infinite data structurs.
There is no symbol manipulation, no expression macros, no inference.
There is no higher order anything.
There are no solvers.
There are no graphics primitives etc..
There are good elementary data types. And then no data structures
other than those that the programmer defines using the find
construction primitives.
Tasks and POs are built into the typesystem. Great for systems
programming, and also for higher level things like ... pfhhh,
whatever ...
But does a shared variable mechanism lift Ada to the level of
languages such as APL (which tends to have it, too)?
A language that does not provide for the low level
is not a systems programming language.
A logical fallacy: A => B does not imply A = B.
No wonder, you stopped after the first premise ;-)
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.
The specific problem seems to make it desirable to be able
to say,
5
3 .. 14 by .
16
You get the idea. Other algorithms may require more elaborate
subset of matrix cells. 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.
-- Georg
.
- Follow-Ups:
- Re: Larger matrices
- From: Dmitry A. Kazakov
- Re: Larger matrices
- From: Georg Bauhaus
- Re: Larger matrices
- References:
- Larger matrices
- From: amado . alves
- Re: Larger matrices
- From: Georg Bauhaus
- Re: Larger matrices
- From: amado . alves
- Re: Larger matrices
- From: amado . alves
- Re: Larger matrices
- From: Jeffrey R. Carter
- Re: Larger matrices
- From: amado . alves
- Re: Larger matrices
- From: amado . alves
- Re: Larger matrices
- From: Georg Bauhaus
- Re: Larger matrices
- From: amado . alves
- Re: Larger matrices
- From: Jeffrey R. Carter
- Re: Larger matrices
- From: amado . alves
- Re: Larger matrices
- From: Georg Bauhaus
- Re: Larger matrices
- From: Dmitry A. Kazakov
- Re: Larger matrices
- From: Georg Bauhaus
- Re: Larger matrices
- From: Dmitry A. Kazakov
- Re: Larger matrices
- From: Georg Bauhaus
- Re: Larger matrices
- From: Dmitry A. Kazakov
- Larger matrices
- Prev by Date: Re: Suffix _T for types found good
- Next by Date: Re: Larger matrices
- Previous by thread: Re: Larger matrices
- Next by thread: Re: Larger matrices
- Index(es):
Relevant Pages
|