[SciPy-dev] Handling of float96 and complex192 in linalg

[David M. Cooke]

On Mon, 12 Jun 2006 17:01:31 +0200
Johannes Loehnert <a.u.r.e.l.i.a.n at gmx.net> wrote:

> Hi,
> 
> I was looking through the code of the linalg module last week. I noticed
> that several of the functions use ``get_lapack_funcs`` from 
> ``Lib/linalg/lapack.py`` in order to find the appropriate lapack routine
> for a given data type.
> 
> However, ``get_lapack_funcs`` fails on arrays with
> dtype.char=='g' (float96) and dtype.char=='G' (complex 2*96). In both cases
> the double precision routine is given back. (I know there are no
> float96/complex192 routines in lapack).
> 
> While this somewhat acceptable for float96 (precision suffers), it is not
> very nice if complex192 is silently cast to float64 by simply throwing the 
> imaginary part away. (See below for a "fatal" example.)
> 
> The "lazy" solution would be to let get_lapack_funcs raise an error for 'g' 
> and 'G' typechar. 
> 
> Alternatively, complex192 could be treated by double precision complex 
> routines ('z' prefix). For this approach, some kind of warning would be
> nice if float96 or complex192 arrays are cast to a lower precision.

I've implemented downcasting of longdouble to double ('d' prefix) and
clongdouble to cdouble ('z' prefix), and rewritten get_lapack_funcs to use
dtype instead of typecodes.
No warning, though.

[I'd urge you to use longdouble/clongdouble instead of float96/complex192: the
later aren't portable. On the Mac, you get float128 and complex256 as
longdouble and clongdouble instead, for instance, and there is no
float96/complex192.]

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca