Re: Singular Value Decomposition (SVD) Ada Algorithm

[aschwarz@acm.org (skidmarks)]

> <...> I developed a
> > doubly-linked list. List management is a normal package body. The
> > generic package provides space, in the generic body, and interfaces to
> > the non-generic list manager. The effect is to have a no-cost generic
> > package interfacing with a shared non-generic package. 
> 
> I'm not sure I followed that claim;  you might consider posting an
> example (folks here are pretty constructive, so you won't get
> pilloried :)

Sorry. To be brief:
1. Optimization of data via generics was avoided. All data is 32-bits.
   The rationale is:
   a. If size optimized and packed, more instructions are required
      during operation for (un)packing operations, which increases
      total size, and with more instructions there is decreased
performance.
      (The size is relative and depends on use. Performance is bad.)
   b. If size optimized and unpacked, then depending on the CPU, slack
      bytes are added which increases the size.
   c. By making all sizes the same, the issue becomes movement into
      and out of the fixed size datum field.
2. The List Manager handles all list operations, insertion, deletion,
   data changes, and is invariant to any application.
3. The generics:
   a. Handles transmission of data to/from cell datum fields.
   b. Creates a free list (an array of cells) in the generic body.
   c. At instantiation, populate the free list.
   d. Provide an interface to the List Manager and some application
      niceties not supported by the List Manager.

At the end, the generic functions are all pragma inline and reference
the List Manager. Data specific issues are addressed in the generic
package which converts data from the user type to the List Manager
type via an Unchecked_Conversion, which I assume requires the
generation of no code for data which have the same size.

The application then does (something like): (Ada like not like Ada):

    package List is new Generic (data_type);

begin

    Cell := List.Push(local data);
    Cell := List.Delete(Cell);
    List.etc
end <>;

A List Manager equivalent function is:

     function Push( List, Cell ) return Cell_Adr_Ptr;

and the Generic functions which make this happen is:

     function Push( Data ) return Cell_Adr_Ptr is
     begin
        return List_Manager.Push( List, Set_Data(
Unchecked_Conversion(Data), NUCELL));
     end Push;
     pragma inline ( Push );

where:
    NUCELL   creates a new cell from the available space list
    Set_Data puts a datum into a cell
    List     is known only to the generic (the list is created
             in the generic body.

And sorry, this is way too long winded. The final result is that there
is a division of responsibility which (I believe) provides an adequate
level of encapsulation and information hiding while giving some
application level conveniences. The generic acts as a no-cost
intermediate level (no code or very little code) to the general
purpose list manager functions.

There is always room for comment and architectural changes. A dialog
will always be appreciated.

art