Re: [R-pkg-devel] How to fix a check error for a package in CRAN

[Wang, Zhu]

Thanks Duncan - I am planning to submit an update, so I have to deal with the 
error message.

Best,
Zhu

-Original Message-
From: Duncan Murdoch  
Sent: Monday, February 15, 2021 2:45 PM
To: Wang, Zhu ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to fix a check error for a package in CRAN

On 15/02/2021 3:38 p.m., Wang, Zhu wrote:
> Hello,
> 
> There is an error for R package mpath:
> 
> https://cran.r-project.org/web/checks/check_results_mpath.html
> 
> However, the information related to the error is not very helpful for me to 
> fix the error:
> 
> https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/mp
> ath-00check.html
> 
> 
> On the other hand, The same package seems to be ok on R Under development 
> (unstable). I guess this is different from the platform where the error 
> occurred in CRAN.
> 
> https://win-builder.r-project.org/Y272HSJc0X4T/00check.log
> 
> Any idea how to fix the error?

It looks like some sort of transient problem on the test machine.  I'd ignore 
it unless you're submitting an update.  In that case, I'd comment on it in your 
submission comment, saying you haven't fixed one problem because it was not 
reproducible.

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

[R-pkg-devel] How to fix a check error for a package in CRAN

[Wang, Zhu]

Hello,

There is an error for R package mpath:

https://cran.r-project.org/web/checks/check_results_mpath.html

However, the information related to the error is not very helpful for me to fix 
the error:

https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/mpath-00check.html


On the other hand, The same package seems to be ok on R Under development 
(unstable). I guess this is different from the platform where the error 
occurred in CRAN.

https://win-builder.r-project.org/Y272HSJc0X4T/00check.log

Any idea how to fix the error?

Many thanks,

Zhu

[[alternative HTML version deleted]]

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

[R-pkg-devel] Error(s) in re-building vignettes

[Wang, Zhu]

Hello,

I got an e-mail response with warnings on an R package submitted to CRAN.  So I 
made some changes to the package, after testing successfully with R CMD check 
-as-cran, then used r-hub for testing. On one of the systems, there were 
error/warnings on vignettes:

! LaTeX Error: File `framed.sty' not found. ! Emergency stop.  Error: 
processing vignette 'ccsvmExample.Rmd' failed with diagnostics: LaTeX failed to 
compile /home/docker/mpath.Rcheck/vign_test/mpath/vignettes/ccsvmExample.tex. 
See https://yihui.org/tinytex/r/#debugging for debugging tips. See 
ccsvmExample.log for more info. --- failed re-building 'ccsvmExample.Rmd'

https://builder.r-hub.io/status/original/mpath_0.4-2.16.tar.gz-6dfdccd06155455db6054cd9e4e98ab0

Package mpath can be found below:

artifacts

Could somebody please help?

Thanks,
Zhu

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Wang, Zhu]

Yes, mypkg is different from pkg, and I am the maintainer of mypkg, but not 
pkg. Otherwise, things can be easier. Sorry for not clear enough.

Thanks to Duncan for a practical solution.

Best,
Zhu

-Original Message-
From: Duncan Murdoch  
Sent: Monday, September 14, 2020 10:49 AM
To: Wang, Zhu ; David Kepplinger 
; R Package Devel 
Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel 
cluster

On 14/09/2020 10:30 a.m., Wang, Zhu wrote:
> In mypkg, I want to call a function foo from pkg,  and foo is not exported. I 
> thought I should use pkg:: or pkg:::, but R CMD check provided a warning.

I'm assuming that mypkg is not the same as pkg; Jeff Newmiller's answer assumes 
the opposite.

In that case where they are different, there is only one circumstance where you 
should be calling foo, and you'll have to do it using foo:::pkg.  That 
circumstance is that you are the maintainer of both packages.  You should 
explain this in your submission message, and ask CRAN to ignore the warning if 
there is one.

The reason for this is the following.  If someone else is maintaining pkg, then 
they are free to change the behaviour of foo without any consideration for you, 
because as an internal function, they have no contract with you to maintain its 
behaviour.  On the other hand, if you maintain both packages, then you should 
be ready to modify mypkg as soon as you modify pkg:::foo.

Duncan Murdoch


> 
> Thanks,
> Zhu
> 
>> You don't need either pkg:: or pkg::: if you are calling the function from 
>> within the package.  You may need one of those if the call is coming from a 
>> user script.
> 
> -Original Message-
> From: Duncan Murdoch 
> Sent: Monday, September 14, 2020 7:17 AM
> To: Wang, Zhu ; David Kepplinger 
> ; R Package Devel 
> 
> Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a 
> parallel cluster
> 
> On 13/09/2020 8:47 p.m., Wang, Zhu wrote:
>> Apologize if I hijack this thread, but the use of ::: is something I was 
>> puzzled.
>>
>> I tried Duncan's solution in my R package mypkg, something like:
>>
>> pkg::callInternal("foo", args)
>>
>> R CMD check mypkg
>>
>> * checking dependencies in R code ... WARNING '::' or ':::' import 
>> not declared from: ‘pkg'
>>
>> I probably missed something here.
> 
> You don't need either pkg:: or pkg::: if you are calling the function from 
> within the package.  You may need one of those if the call is coming from a 
> user script.
> 
> If you use pkg:: from mypkg, you need to declare that mypkg Imports pkg.
>(This is a line in its DESCRIPTION file.)  I think that's what the WARNING 
> is telling you.
> 
> Duncan Murdoch
> 
>>
>> Thanks,
>> Zhu
>>
>> -Original Message-
>> From: R-package-devel  On 
>> Behalf Of Duncan Murdoch
>> Sent: Sunday, September 13, 2020 3:20 PM
>> To: David Kepplinger ; R Package Devel 
>> 
>> Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in 
>> a parallel cluster
>>
>> On 13/09/2020 3:51 p.m., David Kepplinger wrote:
>>> Dear list members,
>>>
>>> I submitted an update for my package and got automatically rejected 
>>> by the incoming checks (as expected from my own checks) for using 
>>> `:::` calls to access the package's namespace.
>>> "There are ::: calls to the package's namespace in its code. A 
>>> package
>>> *almost* never needs to use ::: for its own objects:…" (emphasis
>>> mine)
>>>
>>> This was a conscious decision on my part as the package runs code on 
>>> a user-supplied parallel cluster and I consider cluster-exporting 
>>> the required functions a no-go as it would potentially overwrite 
>>> objects in the clusters R sessions. The package code does not own 
>>> the cluster and hence the R sessions. Therefore overwriting objects 
>>> could potentially lead to unintended behaviour which is opaque to the user 
>>> and difficult to debug.
>>>
>>> Another solution to circumvent the R CMD check note is to export the 
>>> functions to the public namespace but mark them as internal. This 
>>> was also suggested in another thread on this mailing list (c.f.
>>> "Etiquette for package submissions that do not automatically pass 
>>> checks?"). I do not agree with this work-around as the methods are 
>>> indeed internal and should never be used by users. Exporting truly 
>>> internal functions for the sake of satisfying R CMD check is a bad 
>>

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Wang, Zhu]

In mypkg, I want to call a function foo from pkg,  and foo is not exported. I 
thought I should use pkg:: or pkg:::, but R CMD check provided a warning.

Thanks,
Zhu

> You don't need either pkg:: or pkg::: if you are calling the function from 
> within the package.  You may need one of those if the call is coming from a 
> user script.

-Original Message-
From: Duncan Murdoch  
Sent: Monday, September 14, 2020 7:17 AM
To: Wang, Zhu ; David Kepplinger 
; R Package Devel 
Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel 
cluster

On 13/09/2020 8:47 p.m., Wang, Zhu wrote:
> Apologize if I hijack this thread, but the use of ::: is something I was 
> puzzled.
> 
> I tried Duncan's solution in my R package mypkg, something like:
> 
> pkg::callInternal("foo", args)
> 
> R CMD check mypkg
> 
> * checking dependencies in R code ... WARNING '::' or ':::' import not 
> declared from: ‘pkg'
> 
> I probably missed something here.

You don't need either pkg:: or pkg::: if you are calling the function from 
within the package.  You may need one of those if the call is coming from a 
user script.

If you use pkg:: from mypkg, you need to declare that mypkg Imports pkg. 
  (This is a line in its DESCRIPTION file.)  I think that's what the WARNING is 
telling you.

Duncan Murdoch

> 
> Thanks,
> Zhu
> 
> -Original Message-
> From: R-package-devel  On 
> Behalf Of Duncan Murdoch
> Sent: Sunday, September 13, 2020 3:20 PM
> To: David Kepplinger ; R Package Devel 
> 
> Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a 
> parallel cluster
> 
> On 13/09/2020 3:51 p.m., David Kepplinger wrote:
>> Dear list members,
>>
>> I submitted an update for my package and got automatically rejected 
>> by the incoming checks (as expected from my own checks) for using 
>> `:::` calls to access the package's namespace.
>> "There are ::: calls to the package's namespace in its code. A 
>> package
>> *almost* never needs to use ::: for its own objects:…" (emphasis 
>> mine)
>>
>> This was a conscious decision on my part as the package runs code on 
>> a user-supplied parallel cluster and I consider cluster-exporting the 
>> required functions a no-go as it would potentially overwrite objects 
>> in the clusters R sessions. The package code does not own the cluster 
>> and hence the R sessions. Therefore overwriting objects could 
>> potentially lead to unintended behaviour which is opaque to the user and 
>> difficult to debug.
>>
>> Another solution to circumvent the R CMD check note is to export the 
>> functions to the public namespace but mark them as internal. This was 
>> also suggested in another thread on this mailing list (c.f. 
>> "Etiquette for package submissions that do not automatically pass 
>> checks?"). I do not agree with this work-around as the methods are 
>> indeed internal and should never be used by users. Exporting truly 
>> internal functions for the sake of satisfying R CMD check is a bad 
>> argument, in particular if there is a clean, well-documented, 
>> solution by using `:::`
> 
> Who is calling this function:  package code or user code?  I assume 
> it's a bit of a mix:  your package writes a script that calls the 
> function when it runs in user space.  (It would help if you gave an 
> explicit example of when you need to use this technique.)
> 
> If my assumption is correct, there are other simple workarounds 
> besides exporting the functions.  Instead of putting
> 
>  pkg:::foo(args)
> 
> into your script, put
> 
>  pkg::callInternal("foo", args)
> 
> where pkg::callInternal is an exported function that can look up unexported 
> functions in the namespace.
> 
> You may argue that you prefer pkg:::foo for some reason:  to which I'd 
> respond that you are being rude to the CRAN volunteers.  I've offered two 
> options (one in the previous thread, a different one here), and there was a 
> third one in that thread offered by Ivan Krylov.  Surely one of these is good 
> enough for your needs, and you shouldn't force CRAN to handle you specially.
> 
> Duncan
> 
>>
>> I argue `:::` is the only clean solution to this problem and no dirty 
>> work-arounds are necessary. This is a prime example of where `:::` is 
>> actually useful and needed inside a package. If the R community 
>> disagrees, I think R CMD check should at least emit a WARNING instead 
>> of a NOTE and elaborate on the problem and accepted work-arounds in 
>> "Writing R extensions". Or

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Wang, Zhu]

Apologize if I hijack this thread, but the use of ::: is something I was 
puzzled.

I tried Duncan's solution in my R package mypkg, something like:

pkg::callInternal("foo", args)

R CMD check mypkg

* checking dependencies in R code ... WARNING
'::' or ':::' import not declared from: ‘pkg'

I probably missed something here.

Thanks,
Zhu

-Original Message-
From: R-package-devel  On Behalf Of 
Duncan Murdoch
Sent: Sunday, September 13, 2020 3:20 PM
To: David Kepplinger ; R Package Devel 

Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel 
cluster

On 13/09/2020 3:51 p.m., David Kepplinger wrote:
> Dear list members,
> 
> I submitted an update for my package and got automatically rejected by 
> the incoming checks (as expected from my own checks) for using `:::` 
> calls to access the package's namespace.
> "There are ::: calls to the package's namespace in its code. A package
> *almost* never needs to use ::: for its own objects:…" (emphasis mine)
> 
> This was a conscious decision on my part as the package runs code on a 
> user-supplied parallel cluster and I consider cluster-exporting the 
> required functions a no-go as it would potentially overwrite objects 
> in the clusters R sessions. The package code does not own the cluster 
> and hence the R sessions. Therefore overwriting objects could 
> potentially lead to unintended behaviour which is opaque to the user and 
> difficult to debug.
> 
> Another solution to circumvent the R CMD check note is to export the 
> functions to the public namespace but mark them as internal. This was 
> also suggested in another thread on this mailing list (c.f. "Etiquette 
> for package submissions that do not automatically pass checks?"). I do 
> not agree with this work-around as the methods are indeed internal and 
> should never be used by users. Exporting truly internal functions for 
> the sake of satisfying R CMD check is a bad argument, in particular if 
> there is a clean, well-documented, solution by using `:::`

Who is calling this function:  package code or user code?  I assume it's a bit 
of a mix:  your package writes a script that calls the function when it runs in 
user space.  (It would help if you gave an explicit example of when you need to 
use this technique.)

If my assumption is correct, there are other simple workarounds besides 
exporting the functions.  Instead of putting

pkg:::foo(args)

into your script, put

pkg::callInternal("foo", args)

where pkg::callInternal is an exported function that can look up unexported 
functions in the namespace.

You may argue that you prefer pkg:::foo for some reason:  to which I'd respond 
that you are being rude to the CRAN volunteers.  I've offered two options (one 
in the previous thread, a different one here), and there was a third one in 
that thread offered by Ivan Krylov.  Surely one of these is good enough for 
your needs, and you shouldn't force CRAN to handle you specially.

Duncan

> 
> I argue `:::` is the only clean solution to this problem and no dirty 
> work-arounds are necessary. This is a prime example of where `:::` is 
> actually useful and needed inside a package. If the R community 
> disagrees, I think R CMD check should at least emit a WARNING instead 
> of a NOTE and elaborate on the problem and accepted work-arounds in 
> "Writing R extensions". Or keep emitting a NOTE but listing those 
> nebulous reasons where `:::` would be tolerated inside a package. 
> Having more transparent criteria for submitting to CRAN would be 
> really helpful to the entire R community and probably also reduce the traffic 
> on this mailing list.
> 
> Best,
> David
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] [External] Re: incomplete gamma function Fortran subroutine

[Wang, Zhu]

Indeed, that is the piece I missed completely! Glad that I didn't try to invent 
wheels.
Thanks,
Zhu

-Original Message-
From: Ben Bolker  
Sent: Tuesday, July 21, 2020 3:58 PM
To: luke-tier...@uiowa.edu; Wang, Zhu 
Cc: John P. Nolan ; r-package-devel@r-project.org
Subject: Re: [External] Re: [R-pkg-devel] incomplete gamma function Fortran 
subroutine

   Interesting.  It looks like the way to make use of this is to combine the 
information in section 6.7.1 ("Distribution functions", including pgamma ...) 
with section 6.6 "Calling C from Fortran and vice versa" ?

On 7/21/20 4:33 PM, luke-tier...@uiowa.edu wrote:
> Looking at this section of WRE may help:
>
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Numerical
> -analysis-subroutines
>
>
> Best,
>
> luke
>
> On Tue, 21 Jul 2020, Wang, Zhu wrote:
>
>> Thanks to Ben and John. Perhaps the program should call pgamma in R 
>> and pass the number to Fortran. Calling some Fortran subroutines 
>> older than R can trigger concerns when submitting the package to the 
>> CRAN.
>>
>> Best,
>> Zhu
>>
>> -Original Message-
>> From: John P. Nolan 
>> Sent: Tuesday, July 21, 2020 1:43 PM
>> To: Wang, Zhu ; Ben Bolker ; 
>> r-package-devel@r-project.org
>> Subject: RE: [R-pkg-devel] incomplete gamma function Fortran 
>> subroutine
>>
>> As others have said, built-in function pgamma is a (normalized) 
>> version of the incomplete gamma function!   John
>>
>> -Original Message-
>> From: R-package-devel  On 
>> Behalf Of Wang, Zhu
>> Sent: Tuesday, July 21, 2020 2:16 PM
>> To: Ben Bolker ; r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] incomplete gamma function Fortran 
>> subroutine
>>
>> External Email: Use caution with links and attachments.
>>
>> Sorry for not making myself clear: The Fortran subroutine in an R 
>> package needs to call incomplete gamma function.
>>
>> -Original Message-
>> From: R-package-devel  On 
>> Behalf Of Ben Bolker
>> Sent: Tuesday, July 21, 2020 12:54 PM
>> To: r-package-devel@r-project.org
>> Subject: Re: [R-pkg-devel] incomplete gamma function Fortran 
>> subroutine
>>
>>     Is there a reason not to use pgamma(), possibly adjusted by a 
>> (de-)normalizing constant?   (See detailed notes in ?pgamma)
>>
>> On 7/21/20 1:44 PM, Wang, Zhu wrote:
>>> Hello,
>>>
>>> In an R function within a package, I would like to call a Fortran 
>>> subroutine to compute lower gamma function. Any advice will be 
>>> appreciated.
>>>
>>> Thanks!
>>>
>>> Zhu Wang
>>>
>>>   [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_ma
>>> il
>>> man_listinfo_r-2Dpackage-2Ddevel&d=DwIGaQ&c=U0G0XJAMhEk_X0GAGzCL7Q&r
>>> =7 
>>> rQvU8hscCTWlvO-F5wI2-2eTiW40XI5qUKda0AnbG0&m=Y5sTjoEyQhEnvYqP-rmi1Pm
>>> vi 
>>> Z_5jj7ur9P8ujvLiBc&s=w0p6b_yBQ1jDH3amMKQGvmEKYJD-BAid_CphFO37yu0&e=
>>
>> __
>> R-package-devel@r-project.org mailing list 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai
>> lman_listinfo_r-2Dpackage-2Ddevel&d=DwIGaQ&c=U0G0XJAMhEk_X0GAGzCL7Q&r
>> =7rQvU8hscCTWlvO-F5wI2-2eTiW40XI5qUKda0AnbG0&m=Y5sTjoEyQhEnvYqP-rmi1P
>> mviZ_5jj7ur9P8ujvLiBc&s=w0p6b_yBQ1jDH3amMKQGvmEKYJD-BAid_CphFO37yu0&e
>> = __
>> R-package-devel@r-project.org mailing list 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai
>> lman_listinfo_r-2Dpackage-2Ddevel&d=DwIGaQ&c=U0G0XJAMhEk_X0GAGzCL7Q&r
>> =7rQvU8hscCTWlvO-F5wI2-2eTiW40XI5qUKda0AnbG0&m=Y5sTjoEyQhEnvYqP-rmi1P
>> mviZ_5jj7ur9P8ujvLiBc&s=w0p6b_yBQ1jDH3amMKQGvmEKYJD-BAid_CphFO37yu0&e
>> = __
>> R-package-devel@r-project.org mailing list 
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

[Wang, Zhu]

Thanks to Ben and John. Perhaps the program should call pgamma in R and pass 
the number to Fortran. Calling some Fortran subroutines older than R can 
trigger concerns when submitting the package to the CRAN.

Best,
Zhu

-Original Message-
From: John P. Nolan  
Sent: Tuesday, July 21, 2020 1:43 PM
To: Wang, Zhu ; Ben Bolker ; 
r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] incomplete gamma function Fortran subroutine

As others have said, built-in function pgamma is a (normalized) version of the 
incomplete gamma function!   John

-Original Message-
From: R-package-devel  On Behalf Of 
Wang, Zhu
Sent: Tuesday, July 21, 2020 2:16 PM
To: Ben Bolker ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

External Email: Use caution with links and attachments.

Sorry for not making myself clear: The Fortran subroutine in an R package needs 
to call incomplete gamma function.

-Original Message-
From: R-package-devel  On Behalf Of Ben 
Bolker
Sent: Tuesday, July 21, 2020 12:54 PM
To: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

 Is there a reason not to use pgamma(), possibly adjusted by a 
(de-)normalizing constant?   (See detailed notes in ?pgamma)

On 7/21/20 1:44 PM, Wang, Zhu wrote:
> Hello,
>
> In an R function within a package, I would like to call a Fortran subroutine 
> to compute lower gamma function. Any advice will be appreciated.
>
> Thanks!
>
> Zhu Wang
>
>   [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mail
> man_listinfo_r-2Dpackage-2Ddevel&d=DwIGaQ&c=U0G0XJAMhEk_X0GAGzCL7Q&r=7
> rQvU8hscCTWlvO-F5wI2-2eTiW40XI5qUKda0AnbG0&m=Y5sTjoEyQhEnvYqP-rmi1Pmvi
> Z_5jj7ur9P8ujvLiBc&s=w0p6b_yBQ1jDH3amMKQGvmEKYJD-BAid_CphFO37yu0&e=

__
R-package-devel@r-project.org mailing list 
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dpackage-2Ddevel&d=DwIGaQ&c=U0G0XJAMhEk_X0GAGzCL7Q&r=7rQvU8hscCTWlvO-F5wI2-2eTiW40XI5qUKda0AnbG0&m=Y5sTjoEyQhEnvYqP-rmi1PmviZ_5jj7ur9P8ujvLiBc&s=w0p6b_yBQ1jDH3amMKQGvmEKYJD-BAid_CphFO37yu0&e=
__
R-package-devel@r-project.org mailing list 
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dpackage-2Ddevel&d=DwIGaQ&c=U0G0XJAMhEk_X0GAGzCL7Q&r=7rQvU8hscCTWlvO-F5wI2-2eTiW40XI5qUKda0AnbG0&m=Y5sTjoEyQhEnvYqP-rmi1PmviZ_5jj7ur9P8ujvLiBc&s=w0p6b_yBQ1jDH3amMKQGvmEKYJD-BAid_CphFO37yu0&e=
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

[Wang, Zhu]

Thanks Steven.

Zhu

From: Steven Scott 
Sent: Tuesday, July 21, 2020 1:30 PM
To: Wang, Zhu 
Cc: Ben Bolker ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

You can often find this kind of code on netlib.org<http://netlib.org>.  Just 
include it with the fortran code in your package.

On Tue, Jul 21, 2020 at 11:22 AM Wang, Zhu 
mailto:wan...@uthscsa.edu>> wrote:
Sorry for not making myself clear: The Fortran subroutine in an R package needs 
to call incomplete gamma function.

-Original Message-
From: R-package-devel 
mailto:r-package-devel-boun...@r-project.org>>
 On Behalf Of Ben Bolker
Sent: Tuesday, July 21, 2020 12:54 PM
To: r-package-devel@r-project.org<mailto:r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

 Is there a reason not to use pgamma(), possibly adjusted by a 
(de-)normalizing constant?   (See detailed notes in ?pgamma)

On 7/21/20 1:44 PM, Wang, Zhu wrote:
> Hello,
>
> In an R function within a package, I would like to call a Fortran subroutine 
> to compute lower gamma function. Any advice will be appreciated.
>
> Thanks!
>
> Zhu Wang
>
>   [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing 
> list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

[Wang, Zhu]

Sorry for not making myself clear: The Fortran subroutine in an R package needs 
to call incomplete gamma function.

-Original Message-
From: R-package-devel  On Behalf Of Ben 
Bolker
Sent: Tuesday, July 21, 2020 12:54 PM
To: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] incomplete gamma function Fortran subroutine

     Is there a reason not to use pgamma(), possibly adjusted by a 
(de-)normalizing constant?   (See detailed notes in ?pgamma)

On 7/21/20 1:44 PM, Wang, Zhu wrote:
> Hello,
>
> In an R function within a package, I would like to call a Fortran subroutine 
> to compute lower gamma function. Any advice will be appreciated.
>
> Thanks!
>
> Zhu Wang
>
>   [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[R-pkg-devel] incomplete gamma function Fortran subroutine

[Wang, Zhu]

Hello,

In an R function within a package, I would like to call a Fortran subroutine to 
compute lower gamma function. Any advice will be appreciated.

Thanks!

Zhu Wang

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

[Wang, Zhu]

Thanks Sebastian, and I appreciate the suggestion.
Best,
Zhu

-Original Message-
From: R-package-devel  On Behalf Of 
Sebastian Meyer
Sent: Monday, June 1, 2020 1:53 PM
To: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not 
defined in package

This is a new check in R-devel. The NEWS say:

> R CMD check etc now warn when a package exports non-existing S4 
> classes or methods, also in case of no "methods" presence

In your case, the NAMESPACE contains

> exportClasses("bujar")
> exportMethods("show")

but the package neither defines an S4 class "bujar" nor methods for the
S4 generic "show". You should remove these two lines from your NAMESPACE.

Best regards,

Sebastian Meyer


Am 01.06.20 um 18:34 schrieb Wang, Zhu:
> Dear All,
> 
> I received warnings regarding a package:
> 
> https://cran.r-project.org/web/checks/check_results_bujar.html
> 
> The warning still occurred after I changed export(bujar, gcv.enet) to 
> export(bujar) in NAMESPACE. The function bujar was defined in the package, so 
> I probably missed something in Sec 1.5.6 in Writing R Extensions.
> 
> Could somebody kindly advise how to address the warning?
> 
> Thanks,
> 
> Zhu Wang
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

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

Re: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

[Wang, Zhu]

Thanks Max for the very helpful reply.

Best,

Zhu

From: Max Turgeon 
Sent: Monday, June 1, 2020 11:53 AM
To: Wang, Zhu ; R-package-devel@r-project.org
Subject: Re: Warning: S4 exports specified in 'NAMESPACE' but not defined in 
package


Good morning,



I had a quick look at the source file on CRAN, and I don't see any evidence 
that you're using S4 classes...? Indeed, at the end of your function 'bujar', 
you are defining the class of the results using "class(x) <- value", which is 
an S3 idiom.



If indeed you're using S3 instead of S4, then the correct section of WRE is 
1.5.2, and therefore you'll need to clean up your NAMESPACE.



Best,


Max Turgeon
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca<http://maxturgeon.ca>




From: R-package-devel 
mailto:r-package-devel-boun...@r-project.org>>
 on behalf of Wang, Zhu mailto:wan...@uthscsa.edu>>
Sent: June 1, 2020 11:34:27 AM
To: R-package-devel@r-project.org<mailto:R-package-devel@r-project.org>
Subject: [R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not 
defined in package


Caution: This message was sent from outside the University of Manitoba.


Dear All,

I received warnings regarding a package:

https://cran.r-project.org/web/checks/check_results_bujar.html

The warning still occurred after I changed export(bujar, gcv.enet) to 
export(bujar) in NAMESPACE. The function bujar was defined in the package, so I 
probably missed something in Sec 1.5.6 in Writing R Extensions.

Could somebody kindly advise how to address the warning?

Thanks,

Zhu Wang

[[alternative HTML version deleted]]

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

[[alternative HTML version deleted]]

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

[R-pkg-devel] Warning: S4 exports specified in 'NAMESPACE' but not defined in package

[Wang, Zhu]

Dear All,

I received warnings regarding a package:

https://cran.r-project.org/web/checks/check_results_bujar.html

The warning still occurred after I changed export(bujar, gcv.enet) to 
export(bujar) in NAMESPACE. The function bujar was defined in the package, so I 
probably missed something in Sec 1.5.6 in Writing R Extensions.

Could somebody kindly advise how to address the warning?

Thanks,

Zhu Wang

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check Rcpp_1.0.1.tar.gz error

[Wang, Zhu]

Indeed it is from .R/Makevars. Thanks!

From: Ben Bolker 
Sent: Monday, June 17, 2019 4:03 PM
To: Wang, Zhu 
Cc: R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check Rcpp_1.0.1.tar.gz error

This looks like it's caused by the quotation marks around the compiler flags 
("-g ... "), but I couldn't tell you how they got there or how to get rid of 
them ...

On Tue, Jun 18, 2019, 6:57 AM Wang, Zhu 
mailto:wan...@uthscsa.edu>> wrote:
Dear all,

For some reason, I couldn't install Rcpp 
https://cran.r-project.org/web/packages/Rcpp/index.html, and R CMD check 
generated the error message below. I also attached Makeconf file referred below.

Thanks for your attention.

Zhu Wang

installing *source* package 'Rcpp' ...
 ** package 'Rcpp' successfully unpacked and MD5 sums checked
 ** using non-staged installation
 ** libs
 g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG -I../inst/include/-fpic 
 "-g -O2 -Wall -pedantic -mtune=native -Wno-ignored-attributes 
-Wno-deprecated-declarations -Wno-parentheses" -c Date.cpp -  o Date.o
 g++: error: unrecognized debug output level ' -O2 -Wall -pedantic 
-mtune=native -Wno-ignored-attributes -Wno-deprecated-declarations 
-Wno-parentheses'
 /usr/lib/R/etc/Makeconf:176: recipe for target 'Date.o' failed
 make: *** [Date.o] Error 1
 ERROR: compilation failed for package 'Rcpp'

sessionInfo()
## R version 3.6.0 (2019-04-26)
## Platform: x86_64-pc-linux-gnu (64-bit)
## Running under: Ubuntu 18.04.2 LTS
__
R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[alternative HTML version deleted]]

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

[R-pkg-devel] R CMD check Rcpp_1.0.1.tar.gz error

[Wang, Zhu]

Dear all,

For some reason, I couldn't install Rcpp 
https://cran.r-project.org/web/packages/Rcpp/index.html, and R CMD check 
generated the error message below. I also attached Makeconf file referred below.

Thanks for your attention.

Zhu Wang

installing *source* package 'Rcpp' ...
 ** package 'Rcpp' successfully unpacked and MD5 sums checked
 ** using non-staged installation
 ** libs
 g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG -I../inst/include/-fpic 
 "-g -O2 -Wall -pedantic -mtune=native -Wno-ignored-attributes 
-Wno-deprecated-declarations -Wno-parentheses" -c Date.cpp -  o Date.o
 g++: error: unrecognized debug output level ' -O2 -Wall -pedantic 
-mtune=native -Wno-ignored-attributes -Wno-deprecated-declarations 
-Wno-parentheses'
 /usr/lib/R/etc/Makeconf:176: recipe for target 'Date.o' failed
 make: *** [Date.o] Error 1
 ERROR: compilation failed for package 'Rcpp'
 
sessionInfo()
## R version 3.6.0 (2019-04-26)
## Platform: x86_64-pc-linux-gnu (64-bit)
## Running under: Ubuntu 18.04.2 LTS
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in Fortran?

[Wang, Zhu]

Thanks Michael. I agree that it is possible to simplify the codes.

Best,

Zhu 

-Original Message-
From: Michael Weylandt  
Sent: Monday, May 20, 2019 3:41 PM
To: Wang, Zhu 
Cc: Ivan Krylov ; R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in 
Fortran?

Negative binomial is a bit trickier since it's a two parameter family without a 
closed-form MLE.

For the probability parameter, you can use the closed form MLE at 
https://en.wikipedia.org/wiki/Negative_binomial_distribution#Maximum_likelihood_estimation

For the number of samples, you'll need to use an iterative method to solve the 
score equation (see the above link).

It's probably easier to code this up yourself rather than calling into R, but 
if you do call into R, I'd look into using the `fitdistr` function instead of a 
full regression method, as demonstrated at 
https://stat.ethz.ch/pipermail/r-help/2012-October/338458.html

Michael

On Sat, May 11, 2019 at 11:10 AM Wang, Zhu  wrote:
>
> Thanks Michael.
>
> I also need an intercept-only negative binomial model with unknown scale 
> parameter. So my thought was on borrowing some codes that already existed. I 
> think Ivan's solution is an excellent one and can be extended to other 
> scenarios.
>
> Best,
>
> Zhu
>
> On May 11, 2019, at 9:48 AM, Michael Weylandt  
> wrote:
>
> On Sat, May 11, 2019 at 8:28 AM Wang, Zhu  wrote:
>>
>>
>> I am open to whatever suggestions but I am not aware a simple closed-form 
>> solution for my original question.
>>
>
> It would help if you could clarify your original question a bit more, 
> but for at least the main three GLMs, there are closed form solutions, 
> based on means of y. Assuming canonical links,
>
> - Gaussian: intercept = mean(y)
> - Logistic: intercept = logit(mean(y))  [Note that you have problems 
> here if your data is all 0 or all 1]
> - Poisson: intercept = log(mean(y)) [You have problems here if your 
> data is all 0]
>
> (Check my math on these, but I'm pretty sure this is right.)
>
> Like I said above, this gets trickier if you add observation weights or 
> offsets, but the same ideas work.
>
> Stepping back to the statistical theory: GLMs predict the mean of y, 
> conditional on x. If x doesn't vary (intercept only model), then the GLM is 
> just predicting the mean of y and the MLE for the mean of y is exactly that 
> under standard GLM assumptions - the sample mean of y.
>
> We then just have to use the link function and its inverse to transform to 
> and from the observation space (where mean(y) lives) and the linear predictor 
> space (where the intercept term naturally lives).
>
> Michael
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in Fortran?

[Wang, Zhu]

Thanks Michael.

I also need an intercept-only negative binomial model with unknown scale 
parameter. So my thought was on borrowing some codes that already existed. I 
think Ivan's solution is an excellent one and can be extended to other 
scenarios.

Best,

Zhu

On May 11, 2019, at 9:48 AM, Michael Weylandt 
mailto:michael.weyla...@gmail.com>> wrote:

On Sat, May 11, 2019 at 8:28 AM Wang, Zhu 
mailto:wan...@uthscsa.edu>> wrote:

I am open to whatever suggestions but I am not aware a simple closed-form 
solution for my original question.


It would help if you could clarify your original question a bit more, but for 
at least the main three GLMs, there are closed form solutions, based on means 
of y. Assuming canonical links,

- Gaussian: intercept = mean(y)
- Logistic: intercept = logit(mean(y))  [Note that you have problems here if 
your data is all 0 or all 1]
- Poisson: intercept = log(mean(y)) [You have problems here if your data is all 
0]

(Check my math on these, but I'm pretty sure this is right.)

Like I said above, this gets trickier if you add observation weights or 
offsets, but the same ideas work.

Stepping back to the statistical theory: GLMs predict the mean of y, 
conditional on x. If x doesn't vary (intercept only model), then the GLM is 
just predicting the mean of y and the MLE for the mean of y is exactly that 
under standard GLM assumptions - the sample mean of y.

We then just have to use the link function and its inverse to transform to and 
from the observation space (where mean(y) lives) and the linear predictor space 
(where the intercept term naturally lives).

Michael

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in Fortran?

[Wang, Zhu]

Ivan's answer is very impressive.   

Michael,

I am open to whatever suggestions but I am not aware a simple closed-form 
solution for my original question.

Thanks,

Zhu

> On May 11, 2019, at 8:01 AM, Michael Weylandt  
> wrote:
> 
> This is very cool, but I wonder if it isn't over-kill for the larger
> problem.
> 
> In general, calculating the coefficient of an intercept-only GLM is just
> calculating (a transformation of) the MLE of a univariate exponential
> family distribution. (Things may be a bit trickier if the GLM also involves
> weights and offsets, not just an intercept, but I'm assuming it doesn't.)
> 
> OP: Can you clarify why you want to invoke R's entire GLM machinery as
> opposed to just using the closed form solutions?
> 
> Michael
> 
>> On Sat, May 11, 2019 at 7:23 AM Ivan Krylov  wrote:
>> 
>> On Fri, 10 May 2019 16:17:42 +
>> "Wang, Zhu"  wrote:
>> 
>>> Are there any examples or links for me to follow through more closely?
>> 
>> Calling R functions from C++ is described at
>> <http://dirk.eddelbuettel.com/code/rcpp/Rcpp-quickref.pdf> and
>> elsewhere in Rcpp documentation. An example follows:
>> 
>> --8<--glmfit.cpp--8<--
>> #include 
>> #include 
>> using namespace Rcpp;
>> 
>> extern "C" double intercept_glm(size_t n, const double * response) {
>>// access functions from default environment
>>Function glm_fit("glm.fit"), coef("coef");
>> 
>>// intercept-only model: response ~ 1
>>NumericVector x(n);
>>x.fill(1);
>> 
>>// I couldn't find a way to wrap a double* into a NumericVector
>>// without copying anything, sorry; perhaps someone else
>>// can offer a solution
>>NumericVector y(n);
>>std::copy_n(response, n, y.begin());
>> 
>>// call the R function, convert the result back
>>return as(coef(glm_fit(x, y)));
>> }
>> --8<--glmfit.cpp--8<--
>> 
>> Since this function is extern "C" and uses only primitive C types, it
>> should be fairly easy to call from Fortran. (C is the lingua franca of
>> programming languages). Fortran-C interoperability is well described in
>> "Modern Fortran Explained" by Metcalf et al. Here is the Fortran side
>> of the code:
>> 
>> --8<--callglm.f90--8<--
>> subroutine callglm(ret)
>> use, intrinsic :: iso_c_binding, only: c_size_t, c_double
>> ! using iso_c_binding here
>> ! - to get correct type of ret when R calls the function
>> ! - to convert variables before calling C function
>> implicit none
>> ! using F77-style arguments to match expectations of .Fortran()
>> real(c_double), intent(out) :: ret
>> ! toy data to compare against R code later
>> real :: y(10) = [10, 11, 20, 9, 10, 8, 11, 45, 2, 3]
>> ! the interface block declares an extern "C" function
>> interface
>>  ! double intercept_glm(size_t n, const double * response)
>>  function intercept_glm(n, response) bind(c)
>>   use, intrinsic :: iso_c_binding
>>   real(c_double) :: intercept_glm
>>   integer(c_size_t), value :: n
>>   real(c_double) :: response(*)
>>  end function
>> end interface
>> 
>> ! call the function as you would call any other function
>> ret = intercept_glm(int(size(y), c_size_t), real(y, c_double))
>> end subroutine
>> --8<--callglm.f90--8<--
>> 
>> For a quick test, make sure that you have Rcpp installed and run:
>> 
>> # adjust R version and path if your library is elsewhere
>> PKG_CPPFLAGS='-g -I ~/R/x86_64-pc-linux-gnu-library/3.3/Rcpp/include' \
>>R CMD SHLIB callglm.f90 glmfit.cpp
>> R
>> library(Rcpp)
>> dyn.load('callglm.so') # change extension if needed
>> .Fortran('callglm', ret=numeric(1))
>> # $ret
>> # [1] 12.9
>> coef(glm.fit(rep(1, 10), c(10, 11, 20, 9, 10, 8, 11, 45, 2, 3)))
>> # [1] 12.9
>> 
>> To use this in a package, place both files in the src/ subdirectory of
>> your package and add LinkingTo: Rcpp in the DESCRIPTION.
>> 
>> --
>> Best regards,
>> Ivan
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
>[[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in Fortran?

[Wang, Zhu]

Thanks Ivan for the tip. Are there any examples or links for me to follow 
through more closely?

Thanks,

Zhu

-Original Message-
From: Ivan Krylov  
Sent: Monday, May 6, 2019 4:14 AM
To: Wang, Zhu 
Cc: R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] How to obtain intercept of intercept-only glm in 
Fortran?

On Sat, 4 May 2019 22:41:16 +
"Wang, Zhu"  wrote:

> In an R package I would like to compute intercept for an 
> intercept-only GLM in a Fortran subroutine.

If all else fails, you could use R API [*] to call coef(glm.fit(...)), though 
it might require writing a C or C++ wrapper to avoid translating all function 
prototypes from Rinternals.h into Fortran 2003 C interoperability syntax.

--
Best regards,
Ivan

[*]:
https://cran.r-project.org/doc/manuals/R-exts.html#Evaluating-R-expressions-from-C

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

Re: [R-pkg-devel] R CMD check ERROR (strange to me)

[Wang, Zhu]

Thanks Iñaki for the tip that helps!

Best,

Zhu

-Original Message-
From: Iñaki Ucar  
Sent: Friday, May 10, 2019 9:50 AM
To: Wang, Zhu 
Cc: Ivan Krylov ; R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check ERROR (strange to me)

On Fri, 10 May 2019 at 15:42, Wang, Zhu  wrote:
>
> 00install.out
>
> ** testing if installed package can be loaded from temporary location
>  ** checking absolute paths in shared objects and dynamic libraries
>  mv: cannot move 
> '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/00LOCK-cts/00new/cts' to 
> '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts': File exists
>  ERROR:   moving to final location failed
>  * removing '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts'

I believe this has something to do with the new staged installation.
Reported here:

https://stat.ethz.ch/pipermail/r-devel/2019-May/077736.html

Try to disable it with by setting the environment variable 
R_INSTALL_STAGED=false

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

Re: [R-pkg-devel] R CMD check ERROR (strange to me)

[Wang, Zhu]

00install.out

** testing if installed package can be loaded from temporary location
 ** checking absolute paths in shared objects and dynamic libraries
 mv: cannot move 
'/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/00LOCK-cts/00new/cts' to 
'/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts': File exists
 ERROR:   moving to final location failed
 * removing '/media/sf_Documents/Zwang/Rpkg/cts.Rcheck/cts'

-Original Message-
From: Ivan Krylov  
Sent: Friday, May 10, 2019 1:12 AM
To: Wang, Zhu 
Cc: R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check ERROR (strange to me)

On Thu, 9 May 2019 23:19:46 +
"Wang, Zhu"  wrote:

> I have encountered some strange error (see 00install.out).

It seems to have been stripped by the attachment filter, and there are no 
compilation errors on my system. Can you include the relevant lines from 
00install.out inline?

--
Best regards,
Ivan

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

[R-pkg-devel] How to obtain intercept of intercept-only glm in Fortran?

[Wang, Zhu]

Hello,

In an R package I would like to compute intercept for an intercept-only GLM in 
a Fortran subroutine. For instance, in logistic regression, how to obtain an 
intercept in this simple model? I know glm_fit calls some Fortran subroutine, 
but I am not trying to invent something here. Any other suggestions?

Thanks,

Zhu Wang


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] parallel computing slower than sequential computing

[Wang, Zhu]

-Original Message-
From: Ivan Krylov  
Sent: Tuesday, April 30, 2019 10:17 AM
To: Wang, Zhu 
Cc: R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] parallel computing slower than sequential computing

On Mon, 29 Apr 2019 23:44:42 +
"Wang, Zhu"  wrote:

> sessionInfo()
> R version 3.5.2 (2018-12-20)
> Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.2 
> LTS

Which BLAS implementation do you use? One popular implementation, OpenBLAS, 
spawns multiple threads to do some operations faster; the threads can compete 
against each other for CPU resources if resulting number of processes * threads 
per process is more than what CPU can handle.

>>BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
>>LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1


How many CPU cores does your system have? Does this include SMT (also known as 
hyper-threading on Intel processors)? While some problems benefit from 
processor pipeline being able to fetch from multiple threads at the same time, 
for others it's more of a bottleneck.

>>8 CPU cores and 16 logical processors. The Linux system is on a Virtualbox. I 
>>realized this might be a factor.

It may help to decrease the n.cores parameter.
>> n.cores=3, 4, 5 would have similar user/elapsed time compared with 
>> sequential computing.  Thanks Ivan.
--
Best regards,
Ivan

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

[R-pkg-devel] parallel computing slower than sequential computing

[Wang, Zhu]

Hello,

I have a package where parallel computing is slower than sequential computing 
with cross-validation. For instance, please see the following reproducible 
example with 10 cores and the relevant lines in the corresponding R function. 
The R package is also attached. I thought parallel computing should improve the 
speed. However, it is not obvious to me where it went wrong.

Many thanks in advance.

Zhu Wang

library("mpath")
library("pscl")
data("bioChemists", package = "pscl")
>system.time(cv.zipath(art ~ . | ., data = bioChemists, family = "negbin", 
>nlambda=100, parallel=FALSE))
user  system elapsed
  77.430   0.031  79.547
> system.time(cv.zipath(art ~ . | ., data = bioChemists, family = "negbin", 
> nlambda=100, parallel=TRUE, n.cores=10))
user  system elapsed
  95.694   0.517 106.072
R> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.2 LTS

The relevant lines in cv.zipath regarding parallel argument are below:

if(parallel){
 registerDoParallel(cores=n.cores)
 i <- 1  ###needed to pass R CMD check with parallel code below
 residmat <- foreach(i=seq(K), .combine=cbind, .packages='mpath') %dopar% {
 omit <- all.folds[[i]]
 fitcv <- do.call("zipath", list(formula, data[-omit,], weights[-omit], 
 lambda.count=lambda.count, lambda.zero=lambda.zero, nlambda=nlambda, ...))
 logLik(fitcv, newdata=data[omit,, drop=FALSE], Y[omit],
 weights=weights[omit])
 }
 stopImplicitCluster()
 }
 else{
  residmat <- matrix(NA, nlambda, K)
  for(i in seq(K)) {
if(trace)
  cat("\n CV Fold", i, "\n\n")
omit <- all.folds[[i]]
fitcv <- do.call("zipath", list(formula, data[-omit,], weights[-omit],  
 lambda.count=lambda.count, lambda.zero=lambda.zero, nlambda=nlambda, ...))
residmat[, i] <- logLik(fitcv, newdata=data[omit,, drop=FALSE], 
 Y[omit], weights=weights[omit])
  }
 }


mpath_0.3-13.tar.gz
Description: mpath_0.3-13.tar.gz
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] compute pnorm in Fortran subroutine in R package

[Wang, Zhu]

Thanks for the useful tips!

-Original Message-
From: Duncan Murdoch  
Sent: Friday, March 8, 2019 1:32 PM
To: Wang, Zhu ; R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] compute pnorm in Fortran subroutine in R package

On 08/03/2019 12:55 p.m., Wang, Zhu wrote:
> Hello,
> 
> In my R package I would like a Fortran subroutine to compute the same value 
> as pnorm does in R. I didn't find out an existing Fortran pnorm subroutine. 
> Perhaps a Fortran subroutine can somehow call R function pnorm, but I would 
> like advice on how to do this correctly.

This is described in the Writing R Extensions manual, Ch 6, The R API: 
entry points for C code.  As the title suggests, it's mainly written for 
calling things like pnorm() from C, but section 6.6 talks about calling C 
functions from Fortran.

You probably also have the erf() function available in Fortran; it's a linear 
transformation of pnorm().  That is,

   erf(x) = 2*pnorm(x*sqrt(2)) - 1

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

[R-pkg-devel] compute pnorm in Fortran subroutine in R package

[Wang, Zhu]

Hello,

In my R package I would like a Fortran subroutine to compute the same value as 
pnorm does in R. I didn't find out an existing Fortran pnorm subroutine. 
Perhaps a Fortran subroutine can somehow call R function pnorm, but I would 
like advice on how to do this correctly.

Many thanks!

Zhu Wang

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check --as-cran problem

[Wang, Zhu]

I reinstalled Matrix and the installation was fine. But the same problem 
occurred, again only with --as-cran option. I propose to submit the package to 
CRAN and see how it goes. Please advise if you have different suggestions. 

Thanks,

Zhu 

-Original Message-
From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de] 
Sent: Tuesday, January 15, 2019 2:59 AM
To: Wang, Zhu; Dirk Eddelbuettel
Cc: Duncan Murdoch; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check --as-cran problem

If this happens with the CRAN version of the package, you likely have a 
corrupted installtion of Matrix on your machine, please reinstall Matrix 
and try again. We all assumed your Matrix installation is fine.

Best,
Uwe Ligges


On 14.01.2019 23:36, Wang, Zhu wrote:
> The source file is on a local computer, so I would not be able to send a link.
> 
> Nevertheless, I downloaded a stable version at 
> https://cran.r-project.org/src/contrib/bujar_0.2-3.tar.gz, and attached 
> results from
> 
> R CMD check --as-cran
> 
> Thanks,
> 
> Zhu
> 
> From: Dirk Eddelbuettel  on behalf of Dirk 
> Eddelbuettel 
> Sent: Monday, January 14, 2019 4:19 PM
> To: Wang, Zhu
> Cc: Uwe Ligges; Dirk Eddelbuettel; Duncan Murdoch; 
> r-package-devel@r-project.org
> Subject: RE: [R-pkg-devel] R CMD check --as-cran problem
> 
> On 14 January 2019 at 21:05, Wang, Zhu wrote:
> | Apologize for multiple emails but my another email with source version of 
> the package was hold waiting for moderator approval.
> 
> I now formally rejected the post.
> 
> Why? There is a reason there is a size limit there.  You were not asked to
> send your sources, the comment approach is email a link to the repo.
> 
> Dirk
> 
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> 
> 00check.log
> 
> * using log directory 
> ‘/media/zhu/easystore/backupdir/cygwin/home/Zwang/Rpkg/bujar.Rcheck’
> * using R version 3.5.2 (2018-12-20)
> * using platform: x86_64-pc-linux-gnu (64-bit)
> * using session charset: UTF-8
> * using option ‘--as-cran’
> * checking for file ‘bujar/DESCRIPTION’ ... OK
> * checking extension type ... Package
> * this is package ‘bujar’ version ‘0.2-3’
> * checking CRAN incoming feasibility ... WARNING
> Maintainer: ‘Zhu Wang ’
> 
> Insufficient package version (submitted: 0.2.3, existing: 0.2.3)
> 
> The Date field is over a month old.
> 
> This build time stamp is over a month old.
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking if there is a namespace ... OK
> * checking for executable files ... OK
> * checking for hidden files and directories ... OK
> * checking for portable file names ... OK
> * checking for sufficient/correct file permissions ... OK
> * checking serialization versions ... OK
> * checking whether package ‘bujar’ can be installed ... ERROR
> Installation failed.
> See 
> ‘/media/zhu/easystore/backupdir/cygwin/home/Zwang/Rpkg/bujar.Rcheck/00install.out’
>  for details.
> * DONE
> Status: 1 ERROR, 1 WARNING
> 
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R CMD check --as-cran problem

[Wang, Zhu]

The source file is on a local computer, so I would not be able to send a link.

Nevertheless, I downloaded a stable version at 
https://cran.r-project.org/src/contrib/bujar_0.2-3.tar.gz, and attached results 
from

R CMD check --as-cran

Thanks,

Zhu

From: Dirk Eddelbuettel  on behalf of Dirk 
Eddelbuettel 
Sent: Monday, January 14, 2019 4:19 PM
To: Wang, Zhu
Cc: Uwe Ligges; Dirk Eddelbuettel; Duncan Murdoch; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] R CMD check --as-cran problem

On 14 January 2019 at 21:05, Wang, Zhu wrote:
| Apologize for multiple emails but my another email with source version of the 
package was hold waiting for moderator approval.

I now formally rejected the post.

Why? There is a reason there is a size limit there.  You were not asked to
send your sources, the comment approach is email a link to the repo.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R CMD check --as-cran problem

[Wang, Zhu]

Apologize for multiple emails but my another email with source version of the 
package was hold waiting for moderator approval.

No error when submitted to winbuilder. 
https://win-builder.r-project.org/37M4Uw7RvkCv

Thanks,

Zhu

-Original Message-
From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de] 
Sent: Monday, January 14, 2019 1:52 PM
To: Wang, Zhu; Dirk Eddelbuettel; Duncan Murdoch
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check --as-cran problem

What happens if you submit to winbuilder?

If that gives the same error, make the source version of your package 
available that you are checking.


Best,
Uwe Ligges


On 14.01.2019 20:30, Wang, Zhu wrote:
> First, I removed the Rnw file in vignettes to make simple.
> 
> Then I followed Duncan's suggestions below, but I had the same error.
> 
> Next, in the DESCRIPTION, I added survival in Imports, and  
> importFrom("survival", "survfitKM") in NAMESPACE. But I still had the same 
> error: there is no package called 'Matrix'.
> 
> Thanks,
> 
> Zhu
> 
> -Original Message-
> From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of 
> Dirk Eddelbuettel
> Sent: Monday, January 14, 2019 12:45 PM
> To: Duncan Murdoch
> Cc: Dirk Eddelbuettel; Wang, Zhu; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] R CMD check --as-cran problem
> 
> 
> On 14 January 2019 at 13:19, Duncan Murdoch wrote:
> | On 14/01/2019 12:37 p.m., Dirk Eddelbuettel wrote:
> | >
> | > On 14 January 2019 at 16:52, Wang, Zhu wrote:
> | > | Thanks Dirk and Klaus. The package Matrix is not used directly but it 
> is used by package survival, which was called in Suggests.  So I am not sure 
> what is the problem. But why CRAN has no such error 
> https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the 
> CRAN check uses the same R version 3.5.2 as I have. The problem only occurred 
> when I used --as-cran option.
> | >
> | > Doesn't this mean that you may to ensure Matrix is present when survival
> | > might be used -- so if your package suggests survival it should also 
> suggest
> | > Matrix?
> |
> | That shouldn't be necessary.  Since survival imports Matrix, you
> | shouldn't be able to load survival unless Matrix is available.
> | requireNamespace("survival") should fail.
> |
> | I think the problem in bujar is that it never checks
> | requireNamespace("survival"), it just calls
> | getFromNamespace('survfitKM','survival').  That will usually work (just
> | about everyone has survival installed, since it's recommended), but is
> | unsafe.  Zhu should use survival::survfitKM, but only after checking
> | that requireNamespace("survival") is successful.
> 
> Yes, I agree. I mostly tried to be helpful but my email wasn't all that
> effective in that.
> 
> Zhu: the behaviour when --as-cran is not set is irrelevant as CRAN asks you
> to test with --as-cran set, so there really is only one relevant choice.
> 
> And Duncan now kindly detailed the appropriate use case: test for a suggested
> package. Or if your use is not conditional, import from it.
> 
> Dirk
> 
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R CMD check --as-cran problem

[Wang, Zhu]

First, I removed the Rnw file in vignettes to make simple. 

Then I followed Duncan's suggestions below, but I had the same error.

Next, in the DESCRIPTION, I added survival in Imports, and  
importFrom("survival", "survfitKM") in NAMESPACE. But I still had the same 
error: there is no package called 'Matrix'. 

Thanks,

Zhu

-Original Message-
From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk 
Eddelbuettel
Sent: Monday, January 14, 2019 12:45 PM
To: Duncan Murdoch
Cc: Dirk Eddelbuettel; Wang, Zhu; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check --as-cran problem


On 14 January 2019 at 13:19, Duncan Murdoch wrote:
| On 14/01/2019 12:37 p.m., Dirk Eddelbuettel wrote:
| > 
| > On 14 January 2019 at 16:52, Wang, Zhu wrote:
| > | Thanks Dirk and Klaus. The package Matrix is not used directly but it is 
used by package survival, which was called in Suggests.  So I am not sure what 
is the problem. But why CRAN has no such error 
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the 
CRAN check uses the same R version 3.5.2 as I have. The problem only occurred 
when I used --as-cran option.
| > 
| > Doesn't this mean that you may to ensure Matrix is present when survival
| > might be used -- so if your package suggests survival it should also suggest
| > Matrix?
| 
| That shouldn't be necessary.  Since survival imports Matrix, you 
| shouldn't be able to load survival unless Matrix is available. 
| requireNamespace("survival") should fail.
| 
| I think the problem in bujar is that it never checks 
| requireNamespace("survival"), it just calls 
| getFromNamespace('survfitKM','survival').  That will usually work (just 
| about everyone has survival installed, since it's recommended), but is 
| unsafe.  Zhu should use survival::survfitKM, but only after checking 
| that requireNamespace("survival") is successful.

Yes, I agree. I mostly tried to be helpful but my email wasn't all that
effective in that.

Zhu: the behaviour when --as-cran is not set is irrelevant as CRAN asks you
to test with --as-cran set, so there really is only one relevant choice.

And Duncan now kindly detailed the appropriate use case: test for a suggested
package. Or if your use is not conditional, import from it.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] R CMD check --as-cran problem

[Wang, Zhu]

I added Matrix in Suggests (I am not sure that is the way to go), but the same 
error occurred with --as-cran: there is no package called 'Matrix.' Again, 
there is no problem without --as-cran.

Zhu

-Original Message-
From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk 
Eddelbuettel
Sent: Monday, January 14, 2019 11:38 AM
To: Wang, Zhu
Cc: Dirk Eddelbuettel; Klaus Schliep; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] R CMD check --as-cran problem


On 14 January 2019 at 16:52, Wang, Zhu wrote:
| Thanks Dirk and Klaus. The package Matrix is not used directly but it is used 
by package survival, which was called in Suggests.  So I am not sure what is 
the problem. But why CRAN has no such error 
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the 
CRAN check uses the same R version 3.5.2 as I have. The problem only occurred 
when I used --as-cran option.

Doesn't this mean that you may to ensure Matrix is present when survival
might be used -- so if your package suggests survival it should also suggest
Matrix?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] R CMD check --as-cran problem

[Wang, Zhu]

Thanks Dirk and Klaus. The package Matrix is not used directly but it is used 
by package survival, which was called in Suggests.  So I am not sure what is 
the problem. But why CRAN has no such error 
https://cran.r-project.org/web/checks/check_results_bujar.html. I assumed the 
CRAN check uses the same R version 3.5.2 as I have. The problem only occurred 
when I used --as-cran option.

Zhu

-Original Message-
From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf Of Dirk 
Eddelbuettel
Sent: Saturday, January 12, 2019 5:19 PM
To: Wang, Zhu
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R CMD check --as-cran problem


On 11 January 2019 at 22:51, Wang, Zhu wrote:
| ** testing if installed package can be loaded
| Error: package or namespace load failed for 'bujar' in loadNamespace(i, 
c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
|  there is no package called 'Matrix'
| Error: loading failed
| Execution halted
| ERROR: loading failed
| 
| 
| I will appreciate advice on the matter.

Something tries to use package Matrix but it is not installed. You may need
it in Imports: (and then in NAMESPACE) or in Suggests: (and then test via if
(requireNamepace(...) and load).

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] R CMD check --as-cran problem

[Wang, Zhu]

I am trying to update an R package but there was some problem illustrated below.


The current version of the package appears to be fine on CRAN:

https://cran.r-project.org/web/checks/check_results_bujar.html


When R checked the package on a Linux system with R 3.5.2, I had no problem, 
but the following problem occurred with --as-cran option:


R CMD check --as-cran bujar_0.2-3.tar.gz


** testing if installed package can be loaded
Error: package or namespace load failed for 'bujar' in loadNamespace(i, 
c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
 there is no package called 'Matrix'
Error: loading failed
Execution halted
ERROR: loading failed


I will appreciate advice on the matter.


Thanks,


Zhu Wang

[[alternative HTML version deleted]]

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