thanks, good to know, although at my age this is the sort of knowledge that has a very short half-life. ;-)
R > On Oct 4, 2023, at 9:57 AM, Mikael Jagan <jagan...@gmail.com> wrote: > > > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
