Dlange gives inconsistent/incorrect results for RowMajor

Post here if you want to report a bug to the LAPACK team

Dlange gives inconsistent/incorrect results for RowMajor

Postby btracey » Sun Sep 06, 2015 10:59 pm

At Gonum, we are seeing very weird results in the behavior of DLANGE. It is giving incorrect results for row-major matrices. The results are effected by the inital work matrix being zeroed, but in neither case are they correct. It is particularly odd in that it seems inconistent.

For example, in some cases we are seeing:
⎡ 1 1 2 3 4⎤
⎢ 0 1 7 8 9⎥
⎣ 0 0 1 13 14⎦

Gives a norm of 100 when norm = 'M'. We are seeing innacuracies for all norm types, but it appears only for the case where n > m.

Please see the discussion in https://github.com/gonum/lapack/pull/39 ... -138165870 for a number of examples.
Posts: 11
Joined: Mon Aug 10, 2015 6:40 pm

Re: Dlange gives inconsistent/incorrect results for RowMajor

Postby admin » Wed Oct 07, 2015 9:41 pm

Issue is listed as bug 137
Reporting off line conversation

Hi Julien,

On Sep 16, 2015, Dan wrote:

Thanks Julien. Comments in-line.


On Thu, 2015-09-17 Langou, Julien wrote:
Thanks for the bug report and the fix for the LAPACKE DLANGE.

I am looking at the diff of the fix from Dan on the website:
https://github.com/gonum/lapack/pull/39 ... -138165870
And that looks great to me. Thanks a lot. I need to work some more on
this and think about it.

From the top of my head, it seems that one needs to change the indeed
to a
in the row major case.

This was my initial approach, but it did not fix the problem - though
maybe I did something else wrong.

You can see a row-major implementation of Dlange
https://github.com/gonum/lapack/blob/ma ... /dlange.go

As you say below, for the row-major version no workspace is needed for computing the infinity norm. On the other hand, for the 1-norm storage is needed to keep the cache friendly access pattern. It seems to me like switching the size and transposing the matrix should be sufficient. If it’s not either I’m missing something or there’s a second bug.

The fix
is correct but I feel might be an overkill.

I agree. From the observation above above it seems like the logic is
more complicated (though caveat). This was the smallest diff that fixed
the problem, but it is undoubtedly pathological as far as memory use
goes in some cases.

This is one of the case where all this LAPACKE conversion from Row
major to Column major is a pain.

Speaking from experience, in terms of actually translating the code, the hardest place is when the temporary working arrays are used as matrices but are only declared as arrays (Dgecon for example).

(I was strongly against the ROW MAJOR argument in LAPACKE for
precisely this type of reason.)

On the other hand, thanks for making it easier on us to call into Lapack functions! We are building an alternate implementation in pure-Go for a variety of reasons, but Lapack is still faster when available.

Algorithms in LAPACK are all column major. So when called with row
major, LAPACKE converts from row major to column major. Then uses
LAPACK (column major). Then converts back from column major to row

In the case of a norm computation, . . ., this is really really

Is your application (GONUM?) entirely in ROW MAJOR?

The library is row-major, following from conventions in the language.
Originally we did support col-major, but dropped it, largely for the
reasons you mention above. We have Go code that performs the same
operations (these are all purely row-major, written by Brendan), and the
interface to LAPACKE is an option for performance reasons.

In the case of a norm ||.||_oo computation, for an M-by-N matrix
stored in COLUMN MAJOR, the WORKSPACE of size M is needed because we
want to access the data by COLUMN. (We would not need a workspace if
we were ready to access the data by ROW, but this is not contiguous
access (since the data is stored COLUMNWISE), and so we would rather
pay a workspace than not contiguous access.) But, now if the date is
stored by ROW MAJOR format, then we do not need a WORKSPACE. We simply
need to write the code that access the matrix by ROW and we have
contiguous access. So if we were to write the correct code, we would
not need any workspace and we would have contiguous access and we
would not need to go back and forth transpose. (And we would bot have
a bug in allocating the workspace.)

An alternative would be to swap norms between O and I prior to the
LAPACK call. This involves no transpose and no change in work length.

The problem is that we do not have the resources to maintain an LAPACK
(Reason why was strongly against the ROW MAJOR argument in LAPACKE.)

I will post a summary of all this on the lapack forum where Tracey
posted a bug report.

Just to let you know that I started looking into this. Thanks for your
effort and the bug report and the fix.

As we go, we have been logging bugs with OpenBLAS. This was one that was asked to be forwarded onto you. If you look for open bugs with btracey or kortschak you can see what we’ve found. Would you like us to be logging them with you instead? I admit to being a bit confused in which parts are supported by Lapack and which are just OpenBLAS.

In particular, I think https://github.com/xianyi/OpenBLAS/issues/636 may a problem with the Lapack algorithm, and https://github.com/xianyi/OpenBLAS/issues/365 affects the BLAS reference implementation on the netlib website as well.

Thanks for your effort in LAPACK. On the whole it’s an impressively well designed suite.

Site Admin
Posts: 616
Joined: Wed Dec 08, 2004 7:07 pm

Re: Dlange gives inconsistent/incorrect results for RowMajor

Postby admin » Thu Oct 22, 2015 1:37 am

The patch mentioned on https://github.com/xianyi/OpenBLAS/issues/631 has been applied in revision 1602
Closing bug 137
Site Admin
Posts: 616
Joined: Wed Dec 08, 2004 7:07 pm

Return to Bug report

Who is online

Users browsing this forum: No registered users and 4 guests