This is really old school, but a lot of times we have users sending us
copy pasting of codes, and that is the only way to know the version of
the code.
This is mostly a long term maintenance improvement.
Many coding styles require elimination of trailing whitespace, and
many editors and source code management configurations automatically
gobble up whitespace. When these tools gobble up whitespace, it
complicates reviewing the meaningful code changes.
By removing whitespace on one patch, it makes future
code reviews much easier.
=SCRIPT====================================================================
if which tempfile &>/dev/null; then
TEMPMAKER=tempfile
elif which mktemp &>/dev/null; then
TEMPMAKER=mktemp
else
echo "Cannot find tempfile program." 2>&1
exit 1
fi
MYTEMP=$($TEMPMAKER)
trap 'rm -f $MYTEMP' SIGINT SIGTERM
stripit() {
echo "stripping $1"
sed 's/[ \t]*$//' "$1" > $MYTEMP
cp $MYTEMP "$1"
}
if [ $# -gt 0 ]; then
while [ "$1" != "" ]; do
stripit $1
shift
done
else
while read -t 2; do
stripit $REPLY
done
fi
rm $MYTEMP
=================================================
Subject: [PATCH 01/42] Fix ?GEJSV: handle M=N=0 case correctly, amend
documentation. ISSUE: need LQUERY
- Complex kind functions operate on complex matrices
- JOBA cannot be 'N', and we have no parameter named JOBE
- Typos like CGEJSV uses CUNMQR, not SUNMQR
- Case M=0 N=0 shall zero IWORK(1:3) and WORK(1:7) anyway (F90 syntax!)
- Comments fixed to not corrupt doxygen output
- Missing fill of IWORK(3) = 0
- Math is written from capital letter :-)
- Typos like use ZGELQF, not ZGELQ
While looking at the new lapack version (v3.4.1) and going through the routines on http://www.netlib.org/lapack/lapack_routine/, we found some errors and thought that we should report them. Below is the list of the errors.
====================================================================
(1) Should be "\ingroup complex16OTHERsolve" and not "\ingroup complex16OTHERcomputational" because they are driver routines; in addition, in the line just below SUBROUTINE <routinename>, it should be driver routine:
sgtsv.f
sgtsvx.f
sptsv.f
sptsvx.f
dgtsv.f
dgtsvx.f
dptsv.f
dptsvx.f
cgtsv.f
cgtsvx.f
cptsv.f
cptsvx.f
zgtsv.f
zgtsvx.f
zptsv.f
zptsvx.f
(2) Should be "\ingroup complex16SYsolve" and not "\ingroup complex16OTHERcomputational" because they are driver routines; in addition, in the line just below SUBROUTINE <routinename>, it should be driver routine:
ssysvxx.f
dsysvxx.f
(3) Should be "\ingroup realOTHERcomputational" and not ""\ingroup auxOTHERcomputational":
spttrf.f
(4) Should be "\ingroup doubleOTHERcomputational" and not ""\ingroup auxOTHERcomputational":
dpttrf.f
(5) Should be "symmetric matrix" and not "Hermitian indefinite matrix" in "\par Purpose:"
ssytri2.f
dsytri2.f
csytri2.f
zsytri2.f
(6) Should be "\ingroup realGEsing" and not "\ingroup realGEcomputational":
sgejsv.f
dgejsv.f
Use \par instead of \details for section.
add a Contributors Section and a Reference Section.
Remove (some) verbatim section when not needed.
Those changes have been done by hand so I am not sure I manage to catch them all.
Email from Zlatco on August 24th 2010:
The problem that was reported (with zero matrix) is caused by bad initialization to xLASSQ.
It should be ZERO, ONE and not ZERO, ZERO. In fact, I had it ZERO, ONE throughout
the complete development of the code and decided to change it to ZERO, ZERO a the very
end to make it "more elegant". That was stupid, because xLASSQ does not touch those
variables in case of zero vector, leaving scaling at ZERO, and in the nonzero case the scaling
is between ONE and SQRT(N). So, in case of zero vector, division by a variable that
is normally bigger than ONE causes division by zero.
I have corrected that and few other things, stress tested the code and it should be OK now.
README:
i) In xgejsv.f and xgesvj.f input parameters SCALE and
SUMSQ in xlassq.f are now initially set as SCALE = ZERO, SUMSQ=ONE.
Setting them both to zero (without carefully reading xlassq.f) caused
problems with exactly zero columns.
ii) There was a problem in the branch that computes only SIGMA and U of a
rank deficient matrix. The computed numerical rank (NR) was incorrectly
written as N in parameter lists of the corresponding calls.
iii) In xgsvj0.f, xgsvj1.f testing the input parameters is changed to prevent
unnecessarily negative INFO in some situations.
iv) Minor changes, renaming some variables etc.
Mark Gates