[Rd] Mismatches for methods registered for non-generic:

I’m trying to repair my SparseM package to meet new CRAN rules. The fun part was rewriting the arithmetic-ifs in cholesky.f — to conform with new fortran rules. (This struck me as a bit like updating “the wine dark seas” in Homer.) Now, my remaining trouble is that I have several functions d

Re: [Rd] as(, "dgTMatrix")' is deprecated.

t; > > library(REBayes) > > demo(GLmix1) > > > > Thanks, > > Roger > > > > > > > On Oct 3, 2023, at 6:17 PM, Martin Maechler > > stat.math.ethz.ch> wrote: > > > > > >>>>>> Duncan Murdoch > > >>>&

Re: [Rd] as(, "dgTMatrix")' is deprecated.

Thanks, Ivan, I should have had the initiative to do this myself. I’ve now written to the Mosek folks in the hope that they will update this in Rmosek. Best Roger > On Oct 3, 2023, at 8:47 PM, Ivan Krylov wrote: > > On Tue, 3 Oct 2023 16:50:55 + > "Koenker, Roger W

Re: [Rd] as(, "dgTMatrix")' is deprecated.

rmosek installed, I’m doing: library(REBayes) demo(GLmix1) Thanks, Roger > On Oct 3, 2023, at 6:17 PM, Martin Maechler > wrote: > >>>>>> Duncan Murdoch >>>>>>on Tue, 3 Oct 2023 12:59:10 -0400 writes: > >> On 03/10/2023 12:50 p.

[Rd] as(, "dgTMatrix")' is deprecated.

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).

Re: [Rd] From .Fortran to .Call?

> Is .Fortran going to be deprecated, please? I have gotten amazing speed up > with geostatistics processes using HPC type tools. > > Thanks > > On Sat, Dec 26, 2020 at 9:48 AM Koenker, Roger W > wrote: > I’ve recoded a version of one of my quantile regression fitting

Re: [Rd] From .Fortran to .Call?

l("foo", as.matrix(xx)) > > > > On Sat, Dec 26, 2020 at 5:48 PM Koenker, Roger W > wrote: > I’ve recoded a version of one of my quantile regression fitting functions to > use .C64 from dotCall64 rather than .Fortran. > For a moderately large problem with n = 500

Re: [Rd] From .Fortran to .Call?

confess I never paid attention to it myself as most Fortran code I use seems >> pretty fast, i.e. glmnet. >> >> -Naras >> >> >> On 12/23/20 3:57 AM, Koenker, Roger W wrote: >>> Thanks to all and best wishes for a better 2021. >>> >>> U

Re: [Rd] From .Fortran to .Call?

nish it before the >> new year, if not earlier. (Would welcome testers besides myself.) >> >> Incidentally, any idea of what the performance hit is, quantitatively? I >> confess I never paid attention to it myself as most Fortran code I use seems >> pretty fast, i.e. gl

Re: [Rd] From .Fortran to .Call?

;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$ >> >> >> -Naras >> >> >> On 12/19/20 9:53 AM, Ivan Krylov wrote: >>> On Sat, 19 Dec 2020 17:04:59 + >>> "Koenker, Roger W" wrote: >>> &g

[Rd] From .Fortran to .Call?

There are comments in various places, including R-extensions §5.4 suggesting that .Fortran is (nearly) deprecated and hinting that use of .Call is more efficient and now preferred for packages. I understand and greatly appreciate its use with dyn.load() and R CMD SHLIB for development workflow.

[Rd] Environmental Messaging

What sort of message is this to send to the younger generation? > plastic = 1:5 > card = 1:4 > board = 1:4 > plastic/crossprod(card,board) [1] 0.0333 0.0667 0.1000 0.1333 0.1667 Warning message: In plastic/crossprod(card, board) : Recycling array of length 1 in vector-array a

[Rd] dbinom link

FWIW the link from ?dbinom to the Loader paper on Binomials is broken but the paper seems to be available here: https://octave.1599824.n4.nabble.com/attachment/3829107/0/loader2000Fast.pdf Roger Koenker r.koen...@ucl.ac.uk Honorary Professor of Economics Department

Re: [Rd] #include_next not found

FYI, I needed an additional step to manually patch /usr/include/sys/ucred.h but it's not likely you'll need that. -Steve On Wed, Aug 7, 2019 at 11:46 AM Koenker, Roger W mailto:rkoen...@illinois.edu>> wrote: Dear All, Just when I thought I had the plague of gfortran-9 under cont

[Rd] #include_next not found

Dear All, Just when I thought I had the plague of gfortran-9 under control, I made the tactical error of allowing my mac mini to “upgrade” to macOS 10.14.6 which apparently also upgraded Xcode to 10.3. In consequence I’m having difficulty building my packages. The current symptom is: /usr/lo

Re: [Rd] gfortran 9 quantreg bug

Brian. 7. Now it is (just!) a matter of finding the bug. Roger Koenker r.koen...@ucl.ac.uk Department of Economics, UCL London WC1H 0AX. > On Aug 4, 2019, at 3:41 PM, Dirk Eddelbuettel wrote: > > > Roger, > > On 4 August 2019 at 06:48, Koenker, Roger W wrote: >

Re: [Rd] gfortran 9 quantreg bug

ult. Berend Hasselman On 4 Aug 2019, at 08:48, Koenker, Roger W mailto:rkoen...@illinois.edu>> wrote: I’d like to solicit some advice on a debugging problem I have in the quantreg package. Kurt and Brian have reported to me that on Debian machines with gfortran 9 library(quantreg) f = s

[Rd] gfortran 9 quantreg bug

I’d like to solicit some advice on a debugging problem I have in the quantreg package. Kurt and Brian have reported to me that on Debian machines with gfortran 9 library(quantreg) f = summary(rq(foodexp ~ income, data = engel, tau = 1:4/5)) plot(f) fails because summary() produces bogus estimate

Re: [Rd] tools::package_native_routine_registration_skeleton?

t;> wrote: On 28/06/2019 6:27 a.m., Koenker, Roger W wrote: Thanks, I was just coming to that conclusion and beginning to look for a way to make a list of exportable objects. After library(quantreg), ls("package:quantreg") will list all the names you currently export. So ca

Re: [Rd] tools::package_native_routine_registration_skeleton?

that and export explicitly the symbols that are meant for export. Georgi Boshnakov -- Message: 6 Date: Fri, 28 Jun 2019 09:06:52 + From: "Koenker, Roger W" mailto:rkoen...@illinois.edu>> To: "r-devel@r-project.org<mailto:r-devel@r-project.o

[Rd] tools::package_native_routine_registration_skeleton?

I’m trying to sort out the consequences of adding registration for my quantreg package. I’ve generated a quantreg_init.c file with the directive in the message title, and placed it in my src directory. The first issue is that 3 of the 20, or so registered functions have the same name in fortran

Re: [Rd] rgl install for R 3.7

.uk> Department of Economics, UCL London WC1H 0AX. On Jun 2, 2019, at 7:42 PM, Prof Brian Ripley mailto:rip...@stats.ox.ac.uk>> wrote: On 02/06/2019 16:28, Koenker, Roger W wrote: I’ve installed R 3.7.0 on a new laptop running macos 10.14.5 and have managed to get most of my usual packages

[Rd] rgl install for R 3.7

I’ve installed R 3.7.0 on a new laptop running macos 10.14.5 and have managed to get most of my usual packages to compile from source with a ~/.R/Makevars file that looks like this: CC=/usr/local/clang8/bin/clang CXX=/usr/local/clang8/bin/clang++ LDFLAGS=-L/usr/local/clang8/lib CPPFLAGS=-I/usr/