From: Dmitry A. Kazakov on
On Fri, 08 Aug 2008 13:35:04 +0200, Georg Bauhaus wrote:

> amado.alves(a)gmail.com schrieb:
>>>> And Ada got in the way: slicing restricted to one-dimensional arrays!
>>> Compared to other languages that have no slicing at all?
>>
>> There are languages better than Ada at array indexing, including
>> slicing. If there aren't, there should be!
>
> Ada is a systems programming language. As such, it is
> targetting digital computers. In cases where Ada can be used
> for some mathematical tasks, it is still a systems programming
> language.

What?! Ada is a universal purpose language.

> Ada is about computers that have word/byte adressable
> storage cells that happen to be able to store
> bit combinations. Ada is not about cells of mathematical
> abstractions. Overlap is accidental.

Submatrices can be handled efficiently [in-place] using interleaving
techniques.

But an efficient or hardware-close implementation was certainly not the
concern of the Ada.Numerics.Generic_Real_Arrays design. Otherwise it would
not use functions at all.

> If you do already have some theory for your graphs,
> and presuming you need a working program for large
> matrices, I'd suggest that you seriously consider prototyping
> your algorithms using one of the fine PLs that do have the
> required mathematical stuff built in.

Really? 90% of numeric libraries and applications is written in FORTRAN. Do
you think they have prototyped them in 60's? I guess that pencil and paper
is what they used. After all maths is best prototyped in math.

The major challenges numerical applications have is not math, but squeezing
most out of the hardware, in terms of memory, time, accuracy, problem size.
None of this can be "prototyped."

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Jeffrey Creem on
Jean-Pierre Rosen wrote:
> amado.alves(a)gmail.com a �crit :
>>>> And Ada got in the way: slicing restricted to one-dimensional arrays!
>>> Compared to other languages that have no slicing at all?
>>
>> There are languages better than Ada at array indexing, including
>> slicing. If there aren't, there should be!
>>
> AFAIK, Fortran90 has very sophisticated slicing of arrays.
> The only thing I heard about it, is that it was so complicated to define
> and use that it was a major reason why there are so few Fortran90
> compilers...
>
> Language design is about balancing features, usefulness, and
> implementability.

It is also fair to say that the vast majority of the
programmers/software engineers in the world do a pretty lousy job of
even using the features they have been given. Putting in a lot of effort
into some fancy feature that no one uses when that same effort could be
used to improve reliability, or efficiency, or the IDE, or standard
libraries is an important consideration.

I am not quite a crusty old programmer yet but I am getting there. I
have seen a lot of code in a lot of languages from lots of developers,
organizations, companies, etc. There are always plenty of counter
examples but the vast majority of the code in the world (including Ada
code) either ignores or misuses existing programming languages features
that could/should be used to improve reliability, performance,
maintainability, etc.

Of course there is a chance that I am just a bad programmer and that is
why I think that...But since I am getting paid to be a sw engineer and
guiding/influencing development of plenty of engineers, its fair to say
that even if I am wrong, then I must be right.


From: Dmitry A. Kazakov on
On Fri, 08 Aug 2008 13:15:00 GMT, Jeffrey Creem wrote:

> It is also fair to say that the vast majority of the
> programmers/software engineers in the world do a pretty lousy job of
> even using the features they have been given. Putting in a lot of effort
> into some fancy feature that no one uses when that same effort could be
> used to improve reliability, or efficiency, or the IDE, or standard
> libraries is an important consideration.

This is true in general, but IMO wrong for arrays.

I believe that the underlying concepts of matrix and index are simpler than
the partial implementation provided by Ada. Restrictions put on slices, and
built-in ranges impose artificial constraints and require additional
efforts from the layman programmer.

Far more important is that this had a huge impact on the design of the
standard container library, making it sufficiently harder to use than it
could be, if there were provided container views in terms of matrices and
indices. The container library is intended for *daily* use.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Georg Bauhaus on
Dmitry A. Kazakov schrieb:
> On Fri, 08 Aug 2008 13:35:04 +0200, Georg Bauhaus wrote:


>> Ada is a systems programming language.

> What?! Ada is a universal purpose language.

Assembly language is universal, too, as are Lisp and Prolog with FFI,
and so on. This notion of "purpose" is not very specific.
Let me put is this way: Ada has to be especially good at
systems programming, hence it has to be fairly low level.



> But an efficient or hardware-close implementation was certainly not the
> concern of the Ada.Numerics.Generic_Real_Arrays design. Otherwise it would
> not use functions at all.

What hardware? Assume data flow hardware, and assume a way
to put the function result in the input box of the next processing unit.
What now?


>> I'd suggest that you seriously consider prototyping
>> your algorithms using one of the fine PLs that do have the
>> required mathematical stuff built in.
>
> Really? 90% of numeric libraries and applications is written in FORTRAN.

Only a fraction of the tabular arrays of numbers
is input to procedures of challenging numeric libraries.
I'll even guess that a larger fraction of matrices in
lots of Ada programs are 3x3, maybe 4x4.


> Do
> you think they have prototyped them in 60's?
[The libraries, or the algorithms? The latter, yes; APL is about
that old.]

I don't see how prototyping a hypertext graph algorithm
requires a maximally efficient implementation of matrix
computations. A production system may require increased
efficiency. At that stage you have to pay attention to
the tiny bits, possibly redesigning the algorithm.
(If I could have stopped at simple recursive
functions when writing the program below it would have been
a trivial exercise. :)

Georg Bauhaus
Y A Time Drain http://www.9toX.de
From: Dmitry A. Kazakov on
On Fri, 08 Aug 2008 16:11:57 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Fri, 08 Aug 2008 13:35:04 +0200, Georg Bauhaus wrote:
>
>>> Ada is a systems programming language.
>
>> What?! Ada is a universal purpose language.
>
> Assembly language is universal,

It is Turing complete.

> too, as are Lisp and Prolog with FFI,
> and so on.

They are not. Lisp is a list-oriented language, Prolog is a logical
inference language.

> This notion of "purpose" is not very specific.
> Let me put is this way: Ada has to be especially good at
> systems programming, hence it has to be fairly low level.

Wrong. Where that follows from? Systems programming need not to be
low-level. It has to have abstractions close to ones typical for "systems."
There is no obvious connection between these. For example, Ada offers the
notion of protected action in order represent a systems-domain specific
concept of interrupt. It is a fairly high-level abstraction.

>> But an efficient or hardware-close implementation was certainly not the
>> concern of the Ada.Numerics.Generic_Real_Arrays design. Otherwise it would
>> not use functions at all.
>
> What hardware?

Vector processors.

> Assume data flow hardware, and assume a way
> to put the function result in the input box of the next processing unit.
> What now?

Nothing, Ada.Numerics.Generic_Real_Arrays was not designed in order to
support this hardware. Which is the point. Ada is not low-level, and its
design goals are not focused solely on efficiency, but on usability,
portability and maintainability.

> I don't see how prototyping a hypertext graph algorithm
> requires a maximally efficient implementation of matrix
> computations.

Because of the problem size. Incidence matrices grow as O(n**2), i.e.
extremely fast.

> A production system may require increased
> efficiency. At that stage you have to pay attention to
> the tiny bits, possibly redesigning the algorithm.

So, what was prototyped then? Numerics is all about algorithms. Changing
matrix representation has a huge impact on the implementation of the
operations. Technically it means that you have to re-write everything.

This BTW is exactly the problem OP has. He has "prototyped" the thing using
Ada.Numerics.Generic_Real_Arrays. Now, he faces the problem that the
prototype does not scale due to stack overflow. The consequence is a need
in full redesign. Ergo, prototyping was time wasting.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de