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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4246083efae0e43b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!not-for-mail From: aschwarz@acm.org (skidmarks) Newsgroups: comp.lang.ada Subject: Re: Singular Value Decomposition (SVD) Ada Algorithm Date: 9 Nov 2004 09:16:49 -0800 Organization: http://groups.google.com Message-ID: <35f054ea.0411090916.58ad069c@posting.google.com> References: <35f054ea.0410290918.5f7f7d0@posting.google.com> <34defe4d.0410300854.5c038648@posting.google.com> <35f054ea.0410302259.7510a56e@posting.google.com> <34defe4d.0410311001.36e3680@posting.google.com> <35f054ea.0411010817.52bbf8fc@posting.google.com> <34defe4d.0411052123.49702f47@posting.google.com> NNTP-Posting-Host: 199.46.200.234 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1100020609 4994 127.0.0.1 (9 Nov 2004 17:16:49 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 9 Nov 2004 17:16:49 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:6086 Date: 2004-11-09T09:16:49-08:00 List-Id: jpwoodruff@irisinternet.net (John Woodruff) wrote in message news:<34defe4d.0411052123.49702f47@posting.google.com>... > aschwarz@acm.org (skidmarks) wrote in message news:<35f054ea.0411010817.52bbf8fc@posting.google.com>... > > > > <...> I developed a doubly-linked list. > <...> > > > My committment to software engineering was (before I retired) to try > to leave lasting artifacts that will function for *decades* in > evolving service. The tactics that Ada promotes helped me do that, I > think. Other folks have other goals, I guess > I enjoy the occasional dialog! And so I do. Well, you've (and others) given several point of thought. Quickly, let me address some: I learned: 1. There are no absolutes in software. 2. Look at the issues before you solve the problem. In this light there are some notes. Issue: The CPU is of limited capability in an embedded, critical real-time environment. It is very important to conserve space and save speed. The tendered solution seems to solve the issue without compromising system integrity. Programmer optimization is often not required, and more often should not be done (because the compiler does it better and good code is preserved). It is a mistake to say 'never'. It is better to address whether this is an appropriate time to consider optimization by the programmer rather than it is always a mistake for the programmer to 'hand' optimize. I did consider the optimization issues, and did mention them. My opinion is that this a case when the compiler will do more damage than good. Let's consider an example. Hopefully there are counter-examples available which solve the same problems which you are aware of and I am not. Suppose that our data size is a Boolean, and suppose further that we conserve space by using 'pragma packed'. A baseline requirement is that pointers be used, and not just indices, and I am left with something like: (Please correct and glaring Ada errors, but understand that this is just for explication of a viewpoint not for delivery of a product). type Cell_Ptr_Type; type Cell_Type is record Previous: Cell_Ptr_Type; Next : Cell_Ptr_Type; Data : Boolean; end record; type Cell_Ptr_Type is access all Cell_Type; type List_Type(Size: Natural) is record Active: Cell_Type; -- Active List Pointer Free : Cell_Type; -- Available Space List Space : array(1..Size) of aliased Cell_Type; end record; List : List_Type; pragma packed( List ); (Hopefully the Ada isn't too wrong). Now one thing that my approach allows is the complete recovery of all list management functions (inserting, deleting, etc.). This translates into not using a generic for list management and not needing to replicate the list management code for each instance of use with a new type. Another advantage(?) is that non-homogenous lists are supported, provided that the datum size fits into the specified size. Another advantage(?) is that processing overhead is minimized because (in my case) advantage is taken of computer data access characteristics, in this case alignment of cells are on _proper_ boundaries. A disadvantage is that more space is consumed. Given my previous example and looking at the above, 31-bits are wasted for each cell. My point is that the advantages exceed the disadvantages. In particular, the 31-bits lost per cell may be gained when the cost of data plus instruction size (to manipulate the lists) plus instruction size (to access data) plus instruction size (for generic copies of the list management functions) are all included. In general terms, the largest list management routine is (about) 10 SLOC and the remainder vary between 1 - 4 SLOC. Unless the maintainers come from a non-software degree, I wouldn't expect much thought in this case, and I have mentioned that issues should be considered before solutions. And is there a suitable counter-example? thanks PS: I only mention this because age seems to be a prominent characteristic in some of the responses. When I went to college it was relayed to me that statistically unless you made your mark in Physics, Mathematics, or Philosophy before age 25 you never would. Mozart composed a number of good compositions prior to his 20th birthday. And I would rather be young than wise.