Larger matrices
in [ADA]
|
Prev: Size of Vector limited to 1024 MB of Heap Size
Next: How to implement a server socket compatible to telnet?
From: Dmitry A. Kazakov on 8 Aug 2008 08:11 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 8 Aug 2008 09:15 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 8 Aug 2008 09:32 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 8 Aug 2008 10:11 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 8 Aug 2008 10:36
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 |