> There is a call to mosek and I assumed that this wasn?t going to be helpful
for most R-devel recipients. I tried Duncan?s very reasonable suggestion about
options() but it didn?t produce the desired error, so perhaps this isn?t really
a warning but something else???
>
The details are described in news(package="Matrix") under
"Changes in version
1.5-0" and implemented in Matrix:::Matrix.DeprecatedCoerce. That version
was
released in Sep 2022.
At the time, it was too disruptive to signal a proper deprecation warning
with every as(., "d(g.|.C)Matrix") call, for every reverse dependency
of
Matrix, so we decided that in those most common cases we would use message()
instead of warning(). A corollary was that options(warn=n) would not have
the usual effect, so we advertised an alternative to affected maintainers:
in R:
options(Matrix.warnDeprecatedCoerce=n)
on the command line:
R_MATRIX_WARN_DEPRECATED_COERCE=n R CMD check *.tar.gz
But maybe it is time to begin signaling warnings unconditionally ...
Mikael
> For those who might have rmosek installed, I?m doing:
>
> library(REBayes)
> demo(GLmix1)
>
> Thanks,
> Roger
>
>
> > On Oct 3, 2023, at 6:17 PM, Martin Maechler <maechler using
stat.math.ethz.ch> wrote:
> >
> >>>>>> Duncan Murdoch
> >>>>>> on Tue, 3 Oct 2023 12:59:10 -0400 writes:
> >
> >> On 03/10/2023 12:50 p.m., Koenker, Roger W wrote:
> >>> I?ve been getting this warning for a while now (about
> >>> five years if memory serves) and I?m finally tired of it,
> >>> but also too tired to track it down in Matrix. As far as
> >>> I can grep I have no reference to either deprecated
> >>> object, only the apparently innocuous Matrix::Matrix(A,
> >>> sparse = TRUE). Can someone advise, Martin perhaps? I
> >>> thought it might come from Rmosek, but mosek folks don?t
> >>> think so.
> >>>
https://urldefense.com/v3/__https://groups.google.com/g/mosek/c/yEwXmMfHBbg/m/l_mkeM4vAAAJ__;!!DZ3fjg!71re8ipw9fFStkMab0wGuPNSzSaAhPI5vwxd1BCQ7a55mYiRpAq2prn9-wREqKL_G2uBYboXISQfxZYCZ9AFxCnwxdzqTw$
> >
> >> A quick scan of that discussion didn't turn up anything
> >> relevant, e.g. a script to produce the warning. Could you
> >> be more specific, or just post the script here?
> >
> >> In general, a good way to locate the source of a warning
> >> is to set options(warn=2) to turn it into an error, and
> >> then trigger it. The traceback from the error will
> >> include a bunch of junk from the code that catches the
> >> warning, but it will also include the context where it was
> >> triggered.
> >
> >> Duncan Murdoch
> >
> > Indeed.
> >
> > But Roger is right that it in the end, (almost surely) it is
> > from our {Matrix} package.
> >
> > Indeed for several years now, we have tried to make the setup
> > leaner (and hence faster) by not explicitly define coercion
> > from <everything> to <everything> because the size of
> > <everything> is here about 200, and we don't want to have
to provide
> > 200^2 = 40'000 coercion methods.
> >
> > Rather, Matrix package users should use to high level abstract Matrix
> > classes such as "sparseMatrix" or "CsparseMatrix"
or
> > "TsparseMatrix" or "dMatrix",
"symmetricMatrix".
> >
> > In the case of as(<dgCMatrix>, "dgTMatrix") , if you
> > replace "dgTMatrix" by "TsparseMatrix"
> > the result will be the same but also work in the future when the
> > deprecation may have been turned into a defunctation ...
> >
> > Martin