octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #65321] C++20 warnings about deprecated uses o


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #65321] C++20 warnings about deprecated uses of volatile variables
Date: Mon, 19 Feb 2024 20:30:52 -0500 (EST)

Follow-up Comment #15, bug#65321 (group octave):

I'm not sure how I missed those rcond_plus_one declarations.

Back in ancient times, the LINPACK Users' Guide recommended checking the
condition


1.0 + RCOND .EQ. 1.0


to determine whether a LINPACK subroutine had detected a numerically singular
matrix.  It made sense to do that instead of compare RCOND .LE. ABS (EPSILON)
since there was no built-in EPSILON value in Fortran.

I don't see a similar recommendation for checking RCOND in the first edition
of the LAPACK Users' Guide.  In all the individual subroutine descriptions
that I see, RCOND is just described as the reciprocal condition number and if
the matrix is numerically singular, that will be indicated by some non-zero
value of INFO.

Have we just continued to follow the LINPACK way well past its expiration
date?

In any case, maybe it would be best to add an inline template function in the
lo-lapack-proto.h file (or some other utility header file) that provides a
function like


// untested
// possibly only provide for floating types?
template <typename T>
inline bool
is_numerically_singular (T rcond)
{
   return (std::abs (rcond) <= std::numeric_limits<T>::epsilon () && !
std::isnan (rcond));
}


I'm not sure whether isnan is necessary, but we seem to do that check
everywhere now and I don't think it hurts.

At least if we used a function like this, the intent would be clear and future
generations wouldn't be as easily tempted to replace "rcond_plus_one == rcond"
with "rcond != 0".  I mean, how else could rcond_plus_one equal 1.0, right?!?



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65321>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]