LAPACK Archives

[Lapack] Issues with lapack 3.6.0 trunk 1563


Dear Vittorio,

See inlined comments. Your email shows in red.

What flags are you using for compilation? You use gfortran right? You have lots 
of errors, and I am not sure I have so many. Are you using some special flags?

It seems that your execution stops at each overflow.

Are you using:
"-ffpe-trap=overflow"
Well if so, this is a problem.

LAPACK execution might have plenty of overflows, this is just fine and we 
create +INFTY and use them as we should.

We sometimes actually use NaNs as well. So LAPACK does creates NaNs. And this 
is normal. We expect IEEE arithmetic, we create NaNs, we create INFTY, and we 
deal with this. Part of the game.

In other words, you should not compile LAPACK with the option 
"-ffpe-trap=overflow". Is it what you are doing?

See your bug reports #2, #3 and #4. I think there is no problem for these three 
but a compilation flag.

Maybe we should add this in our documentation.

Otherwise thanks a lot for #1, #5, #6 and #7.

I just downloaded lapack 3.6.0 trunk level 1563.
I have an x86-64 hardware.

(1) During compilation I found that in zgges3.f line 404

WORK( 1 ) = DCMPLX( WKOPT )

the variable WKOPT is referenced but not declared nor initialized.
Should it be LWKOPT instead?

Correct. That was a (very bad) typo. We received a bug report from Rodney James 
at 7:46am yesterday and your email pointing to the same problem came at 8:16am 
yesterday. Funny.
Philippe fixed all this in revision 1564 yesterday. Thanks!

(2) Running "./xeigtsts < svd.in" I get the gfortran runtime error message

Program received signal SIGFPE: Floating-point exception - erroneous
arithmetic operation.

This is in sgesvj.f line 627 "TEMP1 = AMIN1( BIG, TEMP1 / AAPP )"
where BIG=3.40282347E+38   TEMP1=1.06502325E+19   AAPP=8.75567555E-32
so that TEMP1/AAPP is too large for single precision arithmetic.
I "fixed" this one changing the abovementioned statement to

TEMP1 = DMIN1( dble(BIG), dble(TEMP1) / dble(AAPP) )

but I am not sure this is correct.
What is the right fix?

Given your values: dble(TEMP1) / dble(AAPP) should be +INFTY. And then MIN( 
NUMBER, +INFTY) should be NUMBER. We should not have any problem.

But I think you have a flag that says that you do not want overflow. Am I 
correct?

Note for LAPACKers: Since AMIN1 is archaic, we might want to use MIN( ) instead 
of AMIN1()
It looks like there is some cleaning to do here. (Replace archaic intrinsic 
with their corresponding modern intrinsic.)

(3) Same error message running "./xeigtsts < sgg.in"
Program received signal SIGFPE: Floating-point exception - erroneous
arithmetic operation.
in shgeqz.f line 762

      IF ( ABS( (WR/S1)*T( ILAST, ILAST ) - H( ILAST, ILAST ) )
     $   .GT. ABS( (WR2/S2)*T( ILAST, ILAST )
     $   - H( ILAST, ILAST ) ) ) THEN

because

WR=-1.11871902E+11   S1=1.17549435E-36  ILAST=3   T=2.48154184E-24
H=-2.41910350E+23  WR2=-1.11871902E+11   S2=1.17549435E-36

so I get overflows computing WR/S1 and WR2/S2
I "fixed" this one by changing the statement into

      IF (DABS((dble(WR)/dble(S1))*T( ILAST, ILAST ) - H( ILAST, ILAST))
     $         .GT.DABS( (dble(WR2)/dble(S2))*T( ILAST, ILAST )
     $         - H( ILAST, ILAST ) ) ) THEN

but I am not sure this is correct.
What is the right fix?

Same answer. Overflow does not necessarily mean problem.

(4) Same error message running "./xeigtsts < sbal.in" at schkbl.f line 141
      VMAX = MAX( VMAX, ABS( A( I, J )-AIN( I, J ) ) / TEMP )

because

I=5          J=6   VMAX=2.65845599E+38  A=-4.00000000
AIN=-8.00000000       TEMP=1.17549435E-38
so that the result of the MAX operation is 3.4028236692093846E+038,
too large to fit in a single precision variable.
I do not know how to fix this one.

Same answer. Overflow does not necessarily mean problem.

(5) Running ./xlintstz < ztest.in zgehrd.f line 350

      WORK( 1 ) = LWKOPT

LWKOPT is undefined.

Thanks! Philippe has just fixed this one with commit 1565. Thanks! Another bad 
one. Thanks!

(6) In sdrgev3.f, line 900
9998 FORMAT( ' SDRGEV3: ', A, ' Eigenvectors from ', A, ' incorrectly ',
the last comma is on column 73. Same for cdrgev3.f at line 902. And
ddrgev3.f line 898. And zdrgev3.f, line 897.

Thanks! Philippe has just fixed this one with commit 1567. Thanks!

(7) The fourth formal argument of CTGSEN is a logical array SELECT.
However in the calling subroutine CGGES3
the corresponding actual argument WORK is a complex array. I believe
this is wrong and error prone.
Are you sure this is intended? Shouldn't it be BWORK, a logical array?

Thanks! Philippe has just fixed this one with commit 1567. Thanks! This was 
just a worspace query, but still, better got that one right. And a compiler 
won't like this indeed. Thanks!

Vittorio: Thanks a lot for all the time and all the feedback. It is great!

Cheers,
Julien and Philippe.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.eecs.utk.edu/mailman/private/lapack/attachments/20150811/f1949877/attachment.html>

<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or