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.
The documentation of 'work' in sgesvj states that it should be of size
max(4,M+N), whereas de documentation of 'lwork' in sgesvj states that
it should be 'length of WORK, WORK >= MAX(6,M+N)'.
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
=================================================
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.
Message from Zlatko:
The following changes are made in the
current version of the code:
1. in dgejsv, sgejsv:
- a typo in checking the parameters LSVEC.OR.LSVEC
has been changed to LSVEC.OR.RSVEC
- the length of WORK, LWORK, its description
and the minimal length for different JOBs
have been revised and corrected
- in a call to xGESVJ with WORK(N+1), the length
of the workspace is set to the correct value of
LWORK-N, instead of the incorrect LWORK
- a missing RETURN after a call to XERBLA
has been inserted
- In the case of zero matrix on input, IWORK(3)
is set to ZERO, to correspond to the description
of IWORK in other nontrivial cases
2. in all routines
- simple editing so that the single and
the corresponding double routines have matching
lines in the source codes.
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.
https://jason@icl.cs.utk.edu/svn/lapack-dev/lapack/branches/SC08-release
........
r609 | julie | 2008-12-16 17:17:52 -0500 (Tue, 16 Dec 2008) | 1 line
Polish routines to fit the LAPACK framework and allow manpages generation
........
r610 | langou | 2008-12-19 12:12:38 -0500 (Fri, 19 Dec 2008) | 30 lines
bug reported on the forum
https://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=854
the complete thread is available at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/635192e11beadb93#
Tobias Burnus also sent us an email:
> Hello,
>
> this was reported at
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/635192e11beadb93#
>
> The problem is the line 47:
>
> 47: IF( M.EQ.0 .OR. A(M, 1).NE.ZERO .OR. A(M, N).NE.ZERO ) THEN
>
> If M == 0 the one accesses A(0,1) which is invalid as the lower bound is 1
> and not 0.
>
> Note: Contrary to C there is no left-to-right evaluation of expressions in
> Fortran; the order is left to the compiler. One might assume that a smart
> compiler does not evaluate "A(M,1)" if "M==0", however, there is nothing in
> the standard guarantees this.
>
> If bounds checks are turned on (see post at the URL above), gfortran aborts
> with an out-of-bounds error.
........
r611 | julie | 2008-12-19 15:00:58 -0500 (Fri, 19 Dec 2008) | 5 lines
Modify the formatting of the comments.
Replace Note and Notes section by Further Details
This allow the manpages to be generated corectly.
........
r612 | julie | 2008-12-19 16:29:21 -0500 (Fri, 19 Dec 2008) | 3 lines
Reformat the xblas routines comments to be able to generate the manpages
........
r613 | julie | 2008-12-19 16:30:31 -0500 (Fri, 19 Dec 2008) | 1 line
Update version number
........
r614 | jason | 2008-12-27 09:44:45 -0500 (Sat, 27 Dec 2008) | 13 lines
Fix non-short-circuited tests in ILAxL{C,R}.
Fortran doesn't short-circuit logical operators, so the check that the leading
dimension /= 0 may not prevent indexing into a 0-length array.
Reported by "hes selex" in
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/635192e11beadb93
and forwarded to the LAPACK maintainers by Tobias Burnus <burnus@net-b.de>.
Chalk up more bugs found by gfortran's diagnostics!
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Cc: Tobias Burnus <burnus@net-b.de>
........
langou