[patch] QR

[Jules Bergmann]

This patch builds on the QR portion of Assem's earlier QR/SVD patch.  It 
has the following changes:

  - Explicitly disables using Qrd for full-QR (storage_type == qrd_saveq)
    when using SAL as the implementation.  Trying to create a Qrd object
    for qrd_saveq will throw an unimplemented exception.

  - Uses the dispatcher from LU and Cholesky.

  - Fix the use of Ext_data objects to avoid modifying the block being
    accessed during the Ext_data object's lifetime.

    When using an Ext_data object to access a block's data directly, you
    should not modify the block's values during the Ext_data object's
    lifetime.  When the block supports direct access, this happens to
    work OK, but when the block does not support direct access, Ext_data
    will copy data and changes made to the block will not be reflected in
    the copy.

    While we did choose the block types in Qrd with direct access in
    mind, we should keep the usage "correct" so that it doesn't get
    exported via cut-and-paste or subtly break in the future.

    (One test idea: we could build a special version of the library that
    forces all Ext_data objects to copy and see what breaks!)

  - Add support for split-complex

  - Added back assertions on input sizes to impl_prodq and impl_rsol.

    In general, assertions are a good thing.  Here they help enforce
    that input matrices from the user have the right shape.

Also in this patch:

  - Updated QR tests to only cover types and storage types supported
    by the implementation.  In particular, avoids testing double
    precision and full-QR when using SAL.

  - Small configure.ac fix for FFTW3.  Adds an AC_SUBST for
    VSIP_IMPL_FFTW3.  Slight logic change when checking if
    FFTW3 is not enabled (was checking against empty string,
    now checks against "no").

A couple of questions

Assem,

Is there any reason we are using matmgs_dqr instead of matmgs_dqrx? 
Likewise for the other SAL functions (magmgs_srhr, etc).  I don't see 
matmgs_dqr documented in the SAL reference manual (nor the other "non-x" 
functions documented).  It looks like the difference is the missing ESAL 
flags.

If the "non-x" functions are not documented, we should use the "x" 
functions instead.


Stefan,

Does the configure.ac bit for FFTW look OK?


				thanks,
				-- Jules


-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: qr.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20060508/09837907/attachment.ksh>