Re: Singular Value Decomposition (SVD) Ada Algorithm

[aschwarz@acm.org (skidmarks)]

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.