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

[Koenker, Roger W]

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 declared as 
generic, e.g. 

setGeneric("as.matrix.coo")
setMethod("as.matrix.coo","matrix.csr", function(x, nrow, 
ncol,eps){.csr.coo(x)})

that have been fine until now and on my fresh R version 4.4.0 (2024-04-24) are 
still ok with R CMD check —as-cran but CRAN checking reveals, e.g.

Check: S3 generic/method consistency, Result: NOTE
 Mismatches for methods registered for non-generic:
 as:
   function(object, Class, strict, ext)
 as.matrix.coo:
   function(x, nrow, ncol, eps, …)

which I interpret as regarding  my generics as just S3 methods for the 
non-generic “as”.  Can someone advise on the best way to repair this?

With best regards, and eternal gratitude for the efforts of R-core in making R 
a living language.


Roger Koenker
r.koen...@ucl.ac.uk
Honorary Professor of Economics
Department of Economics, UCL
Emeritus Professor of Economics
and Statistics, UIUC


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Koenker, Roger W]

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  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  > > 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  to   because  the size of
> > >  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(, "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

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

[Koenker, Roger W]

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"  wrote:
> 
>> I thought it might come from Rmosek, but mosek folks don’t think so.
> 
> I downloaded the Rmosek source package using
> 
> download.packages(
> 'Rmosek', '.',
> repos='https://urldefense.com/v3/__https://download.mosek.com/R/10.1__;!!DZ3fjg!-J68cgVdf_vRXm7yhSxSNzoDv6i6681nySXG9qhE808C3UTKTWGNCfZEWchGfsh2FZbBpQJuWa8Tr8_mo3f2xFo$
>  '
> )
> 
> ...and there are the deprecated calls:
> 
> 
> Rmosek/R$ grep -C2 -r as\(.*dgT
> toCSCMatrix.R-  }
> toCSCMatrix.R-  else if (is(obj,"dgCMatrix")) {
> toCSCMatrix.R:obj <- as(obj,"dgTMatrix")
> toCSCMatrix.R-  }
> toCSCMatrix.R-  else if (is(obj,"list") && 
> setequal(names(obj),c("i","j","v","ncol","nrow"))) {
> --
> toCSCMatrix.R- x=obj[['v']],
> toCSCMatrix.R- dims=c(obj[['nrow']], obj[['ncol']]) )
> toCSCMatrix.R:obj <- as(tmp, "dgTMatrix")
> toCSCMatrix.R-  }
> toCSCMatrix.R-  else if (canCoerce(obj,"dgTMatrix")) {
> toCSCMatrix.R-# Assume coercion is meaningful, and that
> toCSCMatrix.R-# users are aware of computational overhead.
> toCSCMatrix.R:obj <- as(obj,"dgTMatrix")
> toCSCMatrix.R-  }
> toCSCMatrix.R-  else {
> 
> 
> -- 
> Best regards,
> Ivan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Koenker, Roger W]

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???

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  
> 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  to   because  the size of
>  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(, "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

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

[Koenker, Roger W]

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://groups.google.com/g/mosek/c/yEwXmMfHBbg/m/l_mkeM4vAAAJ

All the best to all the best of the R community,
R
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Koenker, Roger W]

Erin,  I think rumors of the deprecation of .Fortran are greatly exaggerated, 
but I’d welcome some confirmation of this from
someone in R core.  There is quite a lot of .Fortran usage  in packages, and 
perhaps even in base R...

> On Dec 26, 2020, at 7:57 PM, Erin Hodgess  wrote:
> 
> 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 functions to 
> use .C64 from dotCall64 rather than .Fortran.
> For a moderately large problem with n = 500,000 and p = 5, and solving for  
> 1:49/50 quantiles the new version shows
> a 3% speedup, although for smaller problems it is actually slower that the 
> .Fortran version.  So, I’m (provisionally) 
> unimpressed by the claims that .Fortran has a big “overhead” performance 
> penalty.  Compared to the(more than) an order of
> magnitude (base 10) improvement that moving from R to fortran produces,  3% 
> isn’t really worth the (admittedly) minimal
> additional coding effort.
> 
> > On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan 
> >  wrote:
> > 
> > Also, just came to know about dotcall64::.C64() (on CRAN) which allows for 
> > Fortran to be called using .Call().
> > 
> > -Naras
> > 
> > On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
> >> I think it should be pretty easy to fix up SUtools to use the .Call 
> >> instead of .Fortran following along the lines of
> >> 
> >> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
> >>  
> >> I too deal with a lot of f77 and so I will most likely finish 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. glmnet.
> >> 
> >> -Naras
> >> 
> >> 
> >> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
> >>> Thanks to all and best wishes for a better 2021.
> >>> 
> >>> Unfortunately I remain somewhat confused:
> >>> 
> >>> o  Bill reveals an elegant way to get from my rudimentary 
> >>> registration setup to
> >>> one that would explicitly type the C interface functions,
> >>> 
> >>> o Ivan seems to suggest that there would be no performance gain from 
> >>> doing this.
> >>> 
> >>> o  Naras’s pcLasso package does use the explicit C typing, but then 
> >>> uses .Fortran
> >>> not .Call.
> >>> 
> >>> o  Avi uses .Call and cites the Romp package 
> >>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
> >>>  where it is asserted that "there is a (nearly) deprecated interface 
> >>> .Fortran() which you
> >>> should not use due to its large performance overhead.”
> >>> 
> >>> As the proverbial naive R (ab)user I’m left wondering:
> >>> 
> >>> o  if I updated my quantreg_init.c file in accordance with Bill’s 
> >>> suggestion could I
> >>> then simply change my .Fortran calls to .Call?
> >>> 
> >>> o  and if so, do I need to include ALL the fortran subroutines in my 
> >>> src directory
> >>> or only the ones called from R?
> >>> 
> >>> o  and in either case could I really expect to see a significant 
> >>> performance gain?
> >>> 
> >>> Finally, perhaps I should stipulate that my fortran is strictly f77, so 
> >>> no modern features
> >>> are in play, indeed most of the code is originally written in ratfor, 
> >>> Brian Kernighan’s
> >>> dialect from ancient times at Bell Labs.
> >>> 
> >>> Again,  thanks to all for any advice,
> >>> Roger
> >>> 
> >>> 
> >>>> On Dec 23, 2020, at 1:11 AM, Avraham Adler  
> >>>> wrote:
> >>>> 
> >>>> Hello, Ivan.
> >>>> 
> >>>> I used .Call instead of .Fortran in the Delaporte package [1]. What
> >>>> helped me out a lot was Drew Schmid

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

[Koenker, Roger W]

Indeed, using profmem there is a significant advantage in memory:

>  sum(mb$bytes)
[1] 261834640   #using .Fortran
> sum(ma$bytes)
[1] 149221000  #using .C64

> On Dec 26, 2020, at 10:22 PM, Kasper Daniel Hansen 
>  wrote:
> 
> Did you check memory usage? I don't know anything about Fortran, but using 
> .Call for C code doesn't duplicate the memory of the objects you supply to 
> the interface, and in some instances, that's an advantage. But that assumes 
> you're doing something like
>   .Call("foo", xx)
> and not
>   Call("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,000 and p = 5, and solving for  
> 1:49/50 quantiles the new version shows
> a 3% speedup, although for smaller problems it is actually slower that the 
> .Fortran version.  So, I’m (provisionally) 
> unimpressed by the claims that .Fortran has a big “overhead” performance 
> penalty.  Compared to the(more than) an order of
> magnitude (base 10) improvement that moving from R to fortran produces,  3% 
> isn’t really worth the (admittedly) minimal
> additional coding effort.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Koenker, Roger W]

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,000 and p = 5, and solving for  
1:49/50 quantiles the new version shows
a 3% speedup, although for smaller problems it is actually slower that the 
.Fortran version.  So, I’m (provisionally) 
unimpressed by the claims that .Fortran has a big “overhead” performance 
penalty.  Compared to the(more than) an order of
magnitude (base 10) improvement that moving from R to fortran produces,  3% 
isn’t really worth the (admittedly) minimal
additional coding effort.

> On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan  
> wrote:
> 
> Also, just came to know about dotcall64::.C64() (on CRAN) which allows for 
> Fortran to be called using .Call().
> 
> -Naras
> 
> On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
>> I think it should be pretty easy to fix up SUtools to use the .Call instead 
>> of .Fortran following along the lines of
>> 
>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
>>  
>> I too deal with a lot of f77 and so I will most likely finish 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. glmnet.
>> 
>> -Naras
>> 
>> 
>> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
>>> Thanks to all and best wishes for a better 2021.
>>> 
>>> Unfortunately I remain somewhat confused:
>>> 
>>> o  Bill reveals an elegant way to get from my rudimentary registration 
>>> setup to
>>> one that would explicitly type the C interface functions,
>>> 
>>> o Ivan seems to suggest that there would be no performance gain from 
>>> doing this.
>>> 
>>> o  Naras’s pcLasso package does use the explicit C typing, but then 
>>> uses .Fortran
>>> not .Call.
>>> 
>>> o  Avi uses .Call and cites the Romp package 
>>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
>>>  where it is asserted that "there is a (nearly) deprecated interface 
>>> .Fortran() which you
>>> should not use due to its large performance overhead.”
>>> 
>>> As the proverbial naive R (ab)user I’m left wondering:
>>> 
>>> o  if I updated my quantreg_init.c file in accordance with Bill’s 
>>> suggestion could I
>>> then simply change my .Fortran calls to .Call?
>>> 
>>> o  and if so, do I need to include ALL the fortran subroutines in my 
>>> src directory
>>> or only the ones called from R?
>>> 
>>> o  and in either case could I really expect to see a significant 
>>> performance gain?
>>> 
>>> Finally, perhaps I should stipulate that my fortran is strictly f77, so no 
>>> modern features
>>> are in play, indeed most of the code is originally written in ratfor, Brian 
>>> Kernighan’s
>>> dialect from ancient times at Bell Labs.
>>> 
>>> Again,  thanks to all for any advice,
>>> Roger
>>> 
>>> 
>>>> On Dec 23, 2020, at 1:11 AM, Avraham Adler  wrote:
>>>> 
>>>> Hello, Ivan.
>>>> 
>>>> I used .Call instead of .Fortran in the Delaporte package [1]. What
>>>> helped me out a lot was Drew Schmidt's Romp examples and descriptions
>>>> [2]. If you are more comfortable with the older Fortran interface,
>>>> Tomasz Kalinowski has a package which uses Fortran 2018 more
>>>> efficiently [3]. I haven't tried this last in practice, however.
>>>> 
>>>> Hope that helps,
>>>> 
>>>> Avi
>>>> 
>>>> [1] 
>>>> https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
>>>> [2] 
>>>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
>>>> [3] 
>>>> https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
>>>> 
>>&g

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

[Koenker, Roger W]

Yes, dotcall64 looks interesting.  There is a paper about it here:

https://www.sciencedirect.com/science/article/pii/S2352711018300785?via%3Dihub

and the R spam package contains many examples of its use for fortran source.

> On Dec 24, 2020, at 12:39 AM, Balasubramanian Narasimhan  
> wrote:
> 
> Also, just came to know about dotcall64::.C64() (on CRAN) which allows for 
> Fortran to be called using .Call().
> 
> -Naras
> 
> On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
>> I think it should be pretty easy to fix up SUtools to use the .Call instead 
>> of .Fortran following along the lines of
>> 
>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
>>  
>> I too deal with a lot of f77 and so I will most likely finish 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. glmnet.
>> 
>> -Naras
>> 
>> 
>> On 12/23/20 3:57 AM, Koenker, Roger W wrote:
>>> Thanks to all and best wishes for a better 2021.
>>> 
>>> Unfortunately I remain somewhat confused:
>>> 
>>> o  Bill reveals an elegant way to get from my rudimentary registration 
>>> setup to
>>> one that would explicitly type the C interface functions,
>>> 
>>> o Ivan seems to suggest that there would be no performance gain from 
>>> doing this.
>>> 
>>> o  Naras’s pcLasso package does use the explicit C typing, but then 
>>> uses .Fortran
>>> not .Call.
>>> 
>>> o  Avi uses .Call and cites the Romp package 
>>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinG4kC7RtA$
>>>  where it is asserted that "there is a (nearly) deprecated interface 
>>> .Fortran() which you
>>> should not use due to its large performance overhead.”
>>> 
>>> As the proverbial naive R (ab)user I’m left wondering:
>>> 
>>> o  if I updated my quantreg_init.c file in accordance with Bill’s 
>>> suggestion could I
>>> then simply change my .Fortran calls to .Call?
>>> 
>>> o  and if so, do I need to include ALL the fortran subroutines in my 
>>> src directory
>>> or only the ones called from R?
>>> 
>>> o  and in either case could I really expect to see a significant 
>>> performance gain?
>>> 
>>> Finally, perhaps I should stipulate that my fortran is strictly f77, so no 
>>> modern features
>>> are in play, indeed most of the code is originally written in ratfor, Brian 
>>> Kernighan’s
>>> dialect from ancient times at Bell Labs.
>>> 
>>> Again,  thanks to all for any advice,
>>> Roger
>>> 
>>> 
>>>> On Dec 23, 2020, at 1:11 AM, Avraham Adler  wrote:
>>>> 
>>>> Hello, Ivan.
>>>> 
>>>> I used .Call instead of .Fortran in the Delaporte package [1]. What
>>>> helped me out a lot was Drew Schmidt's Romp examples and descriptions
>>>> [2]. If you are more comfortable with the older Fortran interface,
>>>> Tomasz Kalinowski has a package which uses Fortran 2018 more
>>>> efficiently [3]. I haven't tried this last in practice, however.
>>>> 
>>>> Hope that helps,
>>>> 
>>>> Avi
>>>> 
>>>> [1] 
>>>> https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
>>>> [2] 
>>>> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
>>>> [3] 
>>>> https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
>>>> 
>>>> Tomasz Kalinowski
>>>> 
>>>> 
>>>> 
>>>> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
>>>>  wrote:
>>>>> To deal with such Fortran issues in several packages I deal with, I
>>>>> wrote the SUtools package 
>>>>> (https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!

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

[Koenker, Roger W]

Thanks to all and best wishes for a better 2021.

Unfortunately I remain somewhat confused:

o  Bill reveals an elegant way to get from my rudimentary  registration 
setup to
one that would explicitly type the C interface functions,

o Ivan seems to suggest that there would be no performance gain from 
doing this.

o  Naras’s pcLasso package does use the explicit C typing, but then 
uses .Fortran
not .Call.

o  Avi uses .Call and cites the Romp package 
https://github.com/wrathematics/Romp
where it is asserted that "there is a (nearly) deprecated interface 
.Fortran() which you 
should not use due to its large performance overhead.”

As the proverbial naive R (ab)user I’m left wondering:  

o  if I updated my quantreg_init.c file in accordance with Bill’s 
suggestion could I
then simply change my .Fortran calls to .Call?

o  and if so, do I need to include ALL the fortran subroutines in my 
src directory
or only the ones called from R?

o  and in either case could I really expect to see a significant 
performance gain?

Finally, perhaps I should stipulate that my fortran is strictly f77, so no 
modern features
are in play, indeed most of the code is originally written in ratfor, Brian 
Kernighan’s
dialect from ancient times at Bell Labs.

Again,  thanks to all for any advice,
Roger


> On Dec 23, 2020, at 1:11 AM, Avraham Adler  wrote:
> 
> Hello, Ivan.
> 
> I used .Call instead of .Fortran in the Delaporte package [1]. What
> helped me out a lot was Drew Schmidt's Romp examples and descriptions
> [2]. If you are more comfortable with the older Fortran interface,
> Tomasz Kalinowski has a package which uses Fortran 2018 more
> efficiently [3]. I haven't tried this last in practice, however.
> 
> Hope that helps,
> 
> Avi
> 
> [1] 
> https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
>  
> [2] 
> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
>  
> [3] 
> https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
>  
> 
> Tomasz Kalinowski
> 
> 
> 
> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
>  wrote:
>> 
>> To deal with such Fortran issues in several packages I deal with, I
>> wrote the SUtools package 
>> (https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$
>>  ) that you
>> can try.  The current version generates the registration assuming
>> implicit Fortran naming conventions though. (I've been meaning to
>> upgrade it to use the gfortran -fc-prototypes-external flag which should
>> be easy; I might just finish that during these holidays.)
>> 
>> There's a vignette as well:
>> https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!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:
>>> 
>>>> 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.
>>> My understanding of §5.4 and 5.5 is that explicit routine registration
>>> is what's important for efficiency, and your package already does that
>>> (i.e. calls R_registerRoutines()). The only two things left to add
>>> would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
>>> R_ARG_OUT/...) of the arguments of each subroutine.
>>> 
>>> Switching to .Call makes sense if you want to change the interface of
>>> your native subroutines to accept arbitrary heavily structured SEXPs
>>> (and switching to .External could be useful if you wanted to play with
>>> evaluation of the arguments).
>>> 
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] From .Fortran to .Call?

[Koenker, Roger W]

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.
In an effort to modernize my quantreg package I wanted to solicit some advice 
about whether it was worthwhile to move away from .Fortran, and if so how this
might be most expeditiously carried out.

As things currently stand my src directory has, in addition to couple dozen .f 
files, a file called quantreg_init.c that contains

#include 
#include  // for NULL
#include 

/* .Fortran calls */
extern void F77_NAME(brutpow)(void *, void *, void *, void *, void *, void *, 
void *, void *, void *, void *, void *, void *, void *, void *);
extern void F77_NAME(combin)(void *, void *, void *, void *, void *, void *, 
void *);
extern void F77_NAME(crqf)(void *, void *, void *, void *, void *, void *, void 
*, void *, void *, void *, void *, void *, void *, void *, void *, void *, void 
*, void *, void *, void *, void *, void *, void *, void *, void *, void *);

…

static const R_FortranMethodDef FortranEntries[] = {
{"brutpow",   (DL_FUNC) _NAME(brutpow),   14},
{"combin",(DL_FUNC) _NAME(combin), 7},
{"crqf",  (DL_FUNC) _NAME(crqf),  26},

...

void R_init_quantreg(DllInfo *dll)
{
R_registerRoutines(dll, CEntries, NULL, FortranEntries, NULL);
R_useDynamicSymbols(dll, FALSE);
}
This was originally setup by an experienced R person in about 2006, but has
always been rather opaque to me; I just follow the template to add fortran
functions.  My questions are:  what would I need to do beyond replacing
.Fortran calls by .Call in my R code?  And would it help? Obviously, what
I’m dreading is being told that all those “void”s would have to be specified
more explicitly even though they are already specified in the fortran.  My 
willingness to
embarrass myself by writing this message was triggered by comparing
timings of a prototype function in R and its fortranization in which the
prototype was actually faster.  Thanks in advance for any suggestions.
   








__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Environmental Messaging

[Koenker, Roger W]

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 arithmetic is deprecated.
  Use c() or as.vector() instead.

ok,  I can write c(crossprod()) but it is ugly, and environmentally wasteful.
What’s next?  Warnings for my beloved  outer(card, board) * board
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] dbinom link

[Koenker, Roger W]

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 of Economics, UCL
Emeritus Professor of Economics
and Statistics, UIUC



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] #include_next not found

[Koenker, Roger W]

Yes,  this did the trick, thanks very much!  I’m cc’ing r-devel  just for the 
record.


Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.


On Aug 7, 2019, at 4:55 PM, Steven Dirkse 
mailto:sdir...@gams.com>> wrote:

Roger,

Updating Xcode has the unfortunate side effect of wiping out the std header 
files from /usr/include.  The fix - once you know about it - is mercifully 
easy.  Here's my notes on the subject, recorded only yesterday so I don't waste 
more time the next time.

Xcode 10.3
Aug 2019: we updated to Xcode 10.3. First, we did the update through the App 
Store. Next, we opened Xcode in the App Store and said yes to “Install required 
additional components?” But that's not all! As admin, I did

sudo open 
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

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 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/local/clang7/bin/clang 
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG   
-I/usr/local/clang7/include/c++/v1  -fPIC  -Wall -g -O2  -c mcmb.c -o mcmb.o
In file included from mcmb.c:11:
/usr/local/clang7/include/c++/v1/stdio.h:108:15: fatal error: 'stdio.h' file 
not found
#include_next 
  ^

My first thought was I should install Simon’s clang-7.0.0 and gfortran-6.1 
packages
which I dutifully did.  The next thought was to update my ~/.R/Makevars file to:

CC=/usr/local/clang7/bin/clang
CXX=/usr/local/clang7/bin/clang++
LDFLAGS=-L/usr/local/clang7/lib
CPPFLAGS=-I/usr/local/clang7/include/c++/v1
FC=/usr/local/gfortran/bin/gfortran
FLIBS=-L/usr/local/gfortran/lib -lgfortran

Further googling has left me unenlightened…  oh, and I’m running
R version 3.6.1 (2019-07-05) -- "Action of the Toes"

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.


__
R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Steven Dirkse, Ph.D.
GAMS Development Corp.
office: 202.342.0180



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] #include_next not found

[Koenker, Roger W]

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/local/clang7/bin/clang 
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG   
-I/usr/local/clang7/include/c++/v1  -fPIC  -Wall -g -O2  -c mcmb.c -o mcmb.o
In file included from mcmb.c:11:
/usr/local/clang7/include/c++/v1/stdio.h:108:15: fatal error: 'stdio.h' file 
not found
#include_next 
  ^

My first thought was I should install Simon’s clang-7.0.0 and gfortran-6.1 
packages
which I dutifully did.  The next thought was to update my ~/.R/Makevars file to:

CC=/usr/local/clang7/bin/clang
CXX=/usr/local/clang7/bin/clang++
LDFLAGS=-L/usr/local/clang7/lib
CPPFLAGS=-I/usr/local/clang7/include/c++/v1
FC=/usr/local/gfortran/bin/gfortran
FLIBS=-L/usr/local/gfortran/lib -lgfortran

Further googling has left me unenlightened…  oh, and I’m running
R version 3.6.1 (2019-07-05) -- "Action of the Toes"

Roger Koenker
r.koen...@ucl.ac.uk
Department of Economics, UCL
London  WC1H 0AX.


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] gfortran 9 quantreg bug

[Koenker, Roger W]

) ...
Preparing to unpack .../libtsan0_9.1.0-10_amd64.deb ...
Unpacking libtsan0:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../gcc-9-base_9.1.0-10_amd64.deb ...
Unpacking gcc-9-base:amd64 (9.1.0-10) over (9.1.0-8) ...
Setting up gcc-9-base:amd64 (9.1.0-10) ...
(Reading database ... 17787 files and directories currently installed.)
Preparing to unpack .../libstdc++6_9.1.0-10_amd64.deb ...
Unpacking libstdc++6:amd64 (9.1.0-10) over (9.1.0-8) ...
Setting up libstdc++6:amd64 (9.1.0-10) ...
(Reading database ... 17787 files and directories currently installed.)
Preparing to unpack .../0-libquadmath0_9.1.0-10_amd64.deb ...
Unpacking libquadmath0:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../1-liblsan0_9.1.0-10_amd64.deb ...
Unpacking liblsan0:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../2-libitm1_9.1.0-10_amd64.deb ...
Unpacking libitm1:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../3-libgomp1_9.1.0-10_amd64.deb ...
Unpacking libgomp1:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../4-libgfortran5_9.1.0-10_amd64.deb ...
Unpacking libgfortran5:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../5-libcc1-0_9.1.0-10_amd64.deb ...
Unpacking libcc1-0:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../6-libatomic1_9.1.0-10_amd64.deb ...
Unpacking libatomic1:amd64 (9.1.0-10) over (9.1.0-8) ...
Preparing to unpack .../7-libgcc1_1%3a9.1.0-10_amd64.deb ...
Unpacking libgcc1:amd64 (1:9.1.0-10) over (1:9.1.0-8) ...
Setting up libgcc1:amd64 (1:9.1.0-10) ...
Selecting previously unselected package cpp-9.
(Reading database ... 17787 files and directories currently installed.)
Preparing to unpack .../cpp-9_9.1.0-10_amd64.deb ...
Unpacking cpp-9 (9.1.0-10) ...
Selecting previously unselected package libgcc-9-dev:amd64.
Preparing to unpack .../libgcc-9-dev_9.1.0-10_amd64.deb ...
Unpacking libgcc-9-dev:amd64 (9.1.0-10) ...
Selecting previously unselected package gcc-9.
Preparing to unpack .../gcc-9_9.1.0-10_amd64.deb ...
Unpacking gcc-9 (9.1.0-10) ...
Selecting previously unselected package libgfortran-9-dev:amd64.
Preparing to unpack .../libgfortran-9-dev_9.1.0-10_amd64.deb ...
Unpacking libgfortran-9-dev:amd64 (9.1.0-10) ...
Selecting previously unselected package gfortran-9.
Preparing to unpack .../gfortran-9_9.1.0-10_amd64.deb ...
Unpacking gfortran-9 (9.1.0-10) ...
Setting up libgomp1:amd64 (9.1.0-10) ...
Setting up libasan5:amd64 (9.1.0-10) ...
Setting up libquadmath0:amd64 (9.1.0-10) ...
Setting up libatomic1:amd64 (9.1.0-10) ...
Setting up libgfortran5:amd64 (9.1.0-10) ...
Setting up libubsan1:amd64 (9.1.0-10) ...
Setting up cpp-9 (9.1.0-10) ...
Setting up libcc1-0:amd64 (9.1.0-10) ...
Setting up liblsan0:amd64 (9.1.0-10) ...
Setting up libitm1:amd64 (9.1.0-10) ...
Setting up libtsan0:amd64 (9.1.0-10) ...
Setting up libgcc-9-dev:amd64 (9.1.0-10) ...
Setting up gcc-9 (9.1.0-10) ...
Setting up libgfortran-9-dev:amd64 (9.1.0-10) ...
Setting up gfortran-9 (9.1.0-10) ...
Processing triggers for libc-bin (2.28-10) ...
root@90521904fa86:/work# pwd

4.  At this point I removed some dependencies from the package
quantreg that I knew were not relevant to the debugging problem at
hand. This included an attempt to set compiler flags in
quantreg/src/Makevars, but this didn't work.

5.  Set compiler flags as follows:

root@90521904fa86:/work# mkdir ~/.R; vi ~/.R/Makevars 

CC=gcc-9
FC=gfortran-9
F77=gfortran-9

Alternatively, one can find the settings of CC, FC, CXX, ... in 
/etc/R/Makeconf
and alter them there.

6.  At this point 

R CMD INSTALL quantreg_5.43.tar.gz

did use the gfortran-9  compiler and this version did reproduce the 
error initially reported by Kurt and 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:
> | 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 estimates of the coefficient bounds.
> | This example has been around in my R package from the earliest days of R, 
> and
> | before that in various incarnations of S.  The culprit is apparently rqbr.f 
> which is
> | even more ancient, but must have something that gfortran 9 doesn’t approve 
> of.
> | 
> | I note that in R-devel

Re: [Rd] gfortran 9 quantreg bug

[Koenker, Roger W]

Thanks Berend,

Yes,  I know about these warnings, they are mostly a consequence of the 
automated
translation from the ancient Bell Labs dialect of fortran called ratfor.  It is 
easy to add
type declarations for “in”  and the others, but it seems unlikely that this is 
going to fix
anything.  The extra labels are all attributable to the ratfor translation.  I 
agree that
the code is ugly — the ratfor is somewhat better, but not much.  I fact the 
algorithm
is rather simple, but I’m reluctant to write it again from scratch, since there 
are few
fiddly details and I would worry somewhat about reproducibility.

Roger

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.


On Aug 4, 2019, at 3:26 PM, Berend Hasselman 
mailto:b...@xs4all.nl>> wrote:

Roger,

I have run

gfortran -c -fsyntax-only -fimplicit-none -Wall -pedantic rqbr.f

in the src folder of quantreg.

There are many warnings about defined but not used labels.
Also two errors such as "Symbol ‘in’ at (1) has no IMPLICIT type".
And warnings such as: Warning: "Possible change of value in conversion from 
REAL(8) to INTEGER(4)  at ..."

No offense intended but this fortran code is awful. I wouldn't want to debug 
this before an extensive cleanup by
getting rid of as many numerical labels as possible, indenting and doing 
something about the warnings "Possible change of value ...".

This is going to be very difficult.

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 = summary(rq(foodexp ~ income, data = engel, tau = 1:4/5))
plot(f)

fails because summary() produces bogus estimates of the coefficient bounds.
This example has been around in my R package from the earliest days of R, and
before that in various incarnations of S.  The culprit is apparently rqbr.f 
which is
even more ancient, but must have something that gfortran 9 doesn’t approve of.

I note that in R-devel there have been some other issues with gfortran 9, but 
these seem
unrelated to my problem.  Not having access to a machine with an R/gfortran9
configuration, I can’t  apply my rudimentary debugging methods.  I’ve considered
trying to build gfortran on my mac air and then building R from source, but 
before
going down this road, I wondered whether others had other suggestions, or
advice about  my proposed route.  As far as I can see there are not yet
binaries for gfortran 9 for osx.

Thanks,
Roger

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk><mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.



[[alternative HTML version deleted]]

__
R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] gfortran 9 quantreg bug

[Koenker, Roger W]

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 estimates of the coefficient bounds.
This example has been around in my R package from the earliest days of R, and
before that in various incarnations of S.  The culprit is apparently rqbr.f 
which is
even more ancient, but must have something that gfortran 9 doesn’t approve of.

I note that in R-devel there have been some other issues with gfortran 9, but 
these seem
unrelated to my problem.  Not having access to a machine with an R/gfortran9
configuration, I can’t  apply my rudimentary debugging methods.  I’ve considered
trying to build gfortran on my mac air and then building R from source, but 
before
going down this road, I wondered whether others had other suggestions, or
advice about  my proposed route.  As far as I can see there are not yet
binaries for gfortran 9 for osx.

Thanks,
Roger

Roger Koenker
r.koen...@ucl.ac.uk
Department of Economics, UCL
London  WC1H 0AX.



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] tools::package_native_routine_registration_skeleton?

[Koenker, Roger W]

Thanks Georgi and Duncan, exports are now specified explicitly  and the  new 
package
is now on CRAN.

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.


On Jun 28, 2019, at 1:11 PM, Duncan Murdoch 
mailto:murdoch.dun...@gmail.com>> 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

cat(ls("package:quantreg"), sep = ", ")

will print the list in a form suitable for including in the export() directive 
in your NAMESPACE file.  Just delete the names that are meant for internal use 
only.

Duncan Murdoch

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk><mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.
On Jun 28, 2019, at 11:23 AM, Georgi Boshnakov 
mailto:georgi.boshna...@manchester.ac.uk><mailto:georgi.boshna...@manchester.ac.uk>>
 wrote:
... reports that the fortran names of all the registered fortran functions are 
“undocumented objects”...
Those symbols should not be exported. In quantreg v5.33, NAMESPACE has 
'exportPattern(".")'. Maybe it is a good time to remove 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><mailto:rkoen...@illinois.edu>>
To: 
"r-devel@r-project.org<mailto:r-devel@r-project.org><mailto:r-devel@r-project.org>"
 
mailto:r-devel@r-project.org><mailto:r-devel@r-project.org>>
Subject: [Rd] tools::package_native_routine_registration_skeleton?
Message-ID: 
<00702a4f-67b0-4b0c-a791-e72af51c4...@illinois.edu<mailto:00702a4f-67b0-4b0c-a791-e72af51c4...@illinois.edu><mailto:00702a4f-67b0-4b0c-a791-e72af51c4...@illinois.edu>>
Content-Type: text/plain; charset="utf-8"
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 as the calling function in R.   This seems easy to 
fix.  More
puzzling is that R CMD check now reports that the fortran names of all the 
registered fortran
functions are “undocumented objects”.  Can someone point me to the officially 
sanctioned
way to deal with this:  presumably I don’t need to document them as if they 
were R functions.
Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk><mailto:r.koen...@ucl.ac.uk><mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.
[[alternative HTML version deleted]]
--
Subject: Digest Footer
___
R-devel@r-project.org<mailto:R-devel@r-project.org><mailto:R-devel@r-project.org>
 mailing list  DIGESTED
https://stat.ethz.ch/mailman/listinfo/r-devel
--
End of R-devel Digest, Vol 196, Issue 25

[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] tools::package_native_routine_registration_skeleton?

[Koenker, Roger W]

Thanks,  I was just coming to that conclusion and beginning to look for a way 
to make a list of
exportable objects.

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.


On Jun 28, 2019, at 11:23 AM, Georgi Boshnakov 
mailto:georgi.boshna...@manchester.ac.uk>> 
wrote:

... reports that the fortran names of all the registered fortran functions are 
“undocumented objects”...

Those symbols should not be exported. In quantreg v5.33, NAMESPACE has 
'exportPattern(".")'. Maybe it is a good time to remove 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.org>" 
mailto:r-devel@r-project.org>>
Subject: [Rd] tools::package_native_routine_registration_skeleton?
Message-ID: 
<00702a4f-67b0-4b0c-a791-e72af51c4...@illinois.edu<mailto:00702a4f-67b0-4b0c-a791-e72af51c4...@illinois.edu>>
Content-Type: text/plain; charset="utf-8"

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 as the calling function in R.   This seems easy to 
fix.  More
puzzling is that R CMD check now reports that the fortran names of all the 
registered fortran
functions are “undocumented objects”.  Can someone point me to the officially 
sanctioned
way to deal with this:  presumably I don’t need to document them as if they 
were R functions.

Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk><mailto:r.koen...@ucl.ac.uk>
Department of Economics, UCL
London  WC1H 0AX.



[[alternative HTML version deleted]]



--

Subject: Digest Footer

___
R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list  DIGESTED
https://stat.ethz.ch/mailman/listinfo/r-devel


--

End of R-devel Digest, Vol 196, Issue 25



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] tools::package_native_routine_registration_skeleton?

[Koenker, Roger W]

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 as the calling function in R.   This seems easy to 
fix.  More
puzzling is that R CMD check now reports that the fortran names of all the 
registered fortran
functions are “undocumented objects”.  Can someone point me to the officially 
sanctioned
way to deal with this:  presumably I don’t need to document them as if they 
were R functions.

Roger Koenker
r.koen...@ucl.ac.uk
Department of Economics, UCL
London  WC1H 0AX.



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] rgl install for R 3.7

[Koenker, Roger W]

Many thanks,  I couldn’t find the right way to convince R that freetype was 
installed in /opt/X11 but installing it
from http://mac.r-project.org/libs/ into /usr/local worked immediately without 
any change in my Makevars file.


Roger Koenker
r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.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

I presume 'R 3.7.0' is R-devel: it is not released and may never be released 
under that version.

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/local/clang8/include -I/opt/X11/include/freetype2

I suspect you don't want the second: if you have pkg-config it should find 
include paths for you.

FC=/usr/local/gfortran/bin/gfortran
FLIBS=-L/usr/local/gfortran/lib -lgfortran
As usual, the last challenge seems to be to get rgl installed.  Compilation 
_seems_ to go
smoothly, but I now see:
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object 
'/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so':
  
dlopen(/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so,
 6): Symbol not found: _FT_Attach_File
  Referenced from: 
/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so

Perhaps you should show the linking line.  A similar setup works for me:

configure: Darwin, so ensuring /opt/X11/bin is at the head of the PATH...
checking for pkg-config... yes
...

Do you have pkg-config (it is not a standard part of macOS, but is available on 
SU's site -- see the R-admin manual)?  You may need to set its path: for rgl I 
used

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

(which should be the default) but for a few packages (Cairo gdtools rsvg)

PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

/usr/local/clang8/bin/clang++ -std=gnu++11 -dynamiclib 
-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module 
-multiply_defined suppress -L/Users/ripley/R/R-devel/lib 
-L/usr/local/clang8/lib -L/usr/local/lib -o rgl.so ABCLineSet.o BBoxDeco.o 
Background.o ClipPlane.o Color.o Disposable.o Light.o LineSet.o LineStripSet.o 
Material.o NULLgui.o PlaneSet.o PointSet.o PrimitiveSet.o RenderContext.o 
Shape.o SphereMesh.o SphereSet.o SpriteSet.o String.o Surface.o TextSet.o 
Texture.o Viewpoint.o api.o assert.o callbacks.o device.o devicemanager.o fps.o 
ftgl.o geom.o gl2ps.o glErrors.o glgui.o gui.o init.o par3d.o pixmap.o 
platform.o pretty.o render.o rglmath.o rglview.o scene.o select.o subscene.o 
win32gui.o win32lib.o x11gui.o x11lib.o -lGLU -lGL -framework GLKit -framework 
OpenGL -dylib_file 
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
 -L/usr/local/lib -lpng16 -L/usr/X11/lib -lX11 -L/usr/local/lib -lfreetype 
-L/Users/ripley/R/R-devel/lib -lR -Wl,-framework -Wl,CoreFoundation

so that is statically linking libfreetype from /usr/local/lib and installed 
from https://mac.r-project.org/libs/freetype-2.5.5-darwin.13-x86_64.tar.gz . 
And that provides a freetype2.pc file, so

% pkg-config freetype2 --cflags
-I/usr/local/include/freetype2 -I/usr/local/include/libpng16
% pkg-config freetype2 --libs
-L/usr/local/lib -lfreetype



There is a comment somewhat after this about rgl requiring XQuartz, but I have  
XQuartz 2.7.11 so I don’t
think that this is the problem.  Apparently, there is still a freetype problem, 
however I’m out of my depth at this
point.   Any suggestions would be most welcome.
Roger Koenker
Honorary Professor
Department of Economics, UCL
London  WC1H 0AX.


--
Brian D. Ripley,  
rip...@stats.ox.ac.uk<mailto:rip...@stats.ox.ac.uk>
Emeritus Professor of Applied Statistics, University of Oxford


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] rgl install for R 3.7

[Koenker, Roger W]

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/local/clang8/include -I/opt/X11/include/freetype2
FC=/usr/local/gfortran/bin/gfortran
FLIBS=-L/usr/local/gfortran/lib -lgfortran

As usual, the last challenge seems to be to get rgl installed.  Compilation 
_seems_ to go 
smoothly, but I now see:


Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object 
'/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so':
  
dlopen(/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so,
 6): Symbol not found: _FT_Attach_File
  Referenced from: 
/Library/Frameworks/R.framework/Versions/3.7/Resources/library/00LOCK-rgl/00new/rgl/libs/rgl.so


There is a comment somewhat after this about rgl requiring XQuartz, but I have  
XQuartz 2.7.11 so I don’t
think that this is the problem.  Apparently, there is still a freetype problem, 
however I’m out of my depth at this
point.   Any suggestions would be most welcome.

Roger Koenker
Honorary Professor
Department of Economics, UCL
London  WC1H 0AX.


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel