lapack/native: porting "recursion" from LAPACK to gonum

27 views
Skip to first unread message

Vladimír Chalupecký

unread,
Aug 4, 2016, 6:04:12 AM8/4/16
to gonum-dev
Hi,

In the process of porting eigendecomposition-related routines from LAPACK to gonum I got to the entanglement of DLAQR{0,2,3,4}. It turns out that they are in fact only two unique routines. The algorithm at one point benefits from (just one level deep) recursion and since Fortran 77 does not include recursion, the authors expanded it explicitly by duplicating the two routines involved. As a result, DLAQR2 and DLAQR3 are almost indentical, and similarly DLAQR0 and DLAQR4 are almost identical.

More information (also about the whole multi-shift QR implementation) can be found in http://www.netlib.org/lapack/lawnspdf/lawn187.pdf

My question is how to best port this to gonum. Some options that I see:

1. Port one routine from a pair, copy the code, make modifications, and in the future keep them in sync.

2. Port a pair (e.g., DLAQR2 and DLAQR3) as one unexported routine (func dlaqr23) that takes one extra bool parameter to indicate which path should be taken internally. This routine would be called by the implementation methods, something like:

func (impl Implementation) Dlaqr2(...) {
   dlaqr23(..., true)
}

func (impl Implementation) Dlaqr3(...) {
   dlaqr23(..., false)
}

func dlaqr23(..., useAsDlaqr2 bool) {
    // ...
}

3. Similar to 2. but export and provide only func (impl Implementation) Dlaqr23().

4. Something else?

It is not a big design decision, once the routine is ported swapping between 1-4 is easy. I would go with 2 but I thought that I would ask what others think first.

V.

Dan Kortschak

unread,
Aug 4, 2016, 6:15:10 AM8/4/16
to Vladimír Chalupecký, gonum-dev
2. or 3. seem the most sensible (the latter presumably would require the
additional bool param). These are internal only routines so I think that
it's actually probably better to do 3.

Vladimír Chalupecký

unread,
Aug 4, 2016, 6:40:10 AM8/4/16
to gonum-dev, vladimir....@gmail.com
Thanks for confirming my thoughts. Originally I prefered 3 but then switched to 2 because it replicates the reference API. But you are right, these are very internal routines, so I'll go with 3.
Reply all
Reply to author
Forward
0 new messages