fix post-loop SIDE/TRANS guard in p?ormrz / p?unmrz

[kyungminlee]

In PCUNMRZ/PDORMRZ/PSORMRZ/PZUNMRZ, the post-loop guard that controls the leading-partial-block PORMR3/PUNMR3 fix-up was a byte-for-byte copy of the pre-loop guard. The same condition gated both blocks, so the post-loop fired together with the pre-loop in the (LEFT,!NOTRAN) / (RIGHT,NOTRAN) directions (over-applying K-1 reflectors to an already transformed C) and never fired in the complementary (LEFT,NOTRAN) / (RIGHT,!NOTRAN) directions (silently skipping the leading partial block of reflectors). All four SIDE/TRANS combinations produced numerically incorrect results.

Replace the post-loop guard with the complement of the pre-loop guard, matching the analogous structure in p?ormrq.f.

[zerothi]

I guess these can be replaced with .EQV. for logical equivalence? Simpler?

[kyungminlee]

I agree it would look simpler. The pattern seems to have been inherited from LAPACK, and used multiple times within the same subroutine.

scalapack/SRC/pcunmrz.f

Lines 379 to 384 in f7edd05

	CALL PB_TOPGET( ICTXT, 'Broadcast', 'Columnwise', COLBTOP )
	*
	IF( ( LEFT .AND. .NOT.NOTRAN ) .OR.
	$ ( .NOT.LEFT .AND. NOTRAN ) ) THEN
	I1 = MIN( ICEIL( IA, DESCA( MB_ ) ) * DESCA( MB_ ), IA+K-1 )
	$ + 1

[langou]

As pointed @zerothi, we could replace

      IF( ( LEFT .AND. .NOT.NOTRAN ) .OR.
     $    ( .NOT.LEFT .AND. NOTRAN ) ) THEN

with

      IF( LEFT .EQV. .NOT.NOTRAN ) THEN

This is a good comment.

I do not have a strong opinion.

(1) The former might be easier to read (matter of taste), and (2) is what's already in the code and (3) is based on the three more common logical operators .NOT., .AND., .OR. while the .EQV. logical operator is not used anywhere in LAPACK nor ScaLAPACK.

The latter is more concise and elegant (matter of taste).

If someone wants to propose a separate PR, why not.

[zerothi]

As pointed @zerothi, we could replace

      IF( ( LEFT .AND. .NOT.NOTRAN ) .OR.
     $    ( .NOT.LEFT .AND. NOTRAN ) ) THEN

with

      IF( LEFT .EQV. .NOT.NOTRAN ) THEN

This is a good comment.

I do not have a strong opinion.

(1) The former might be easier to read (matter of taste), and (2) is what's already in the code and (3) is based on the three more common logical operators .NOT., .AND., .OR. while the .EQV. logical operator is not used anywhere in LAPACK nor ScaLAPACK.

The latter is more concise and elegant (matter of taste).

If someone wants to propose a separate PR, why not.

Ok, I can see lots of places in the code that could replace with:
.NEQV. and .EQV..

So if this is ok, I could see if I have the time for this.