Re: [R-pkg-devel] [Tagged] Re: multithreading in packages
One thing I did not see mentioned in this thread (pun intended) so far: For what kind of computations is multithreading supposed to be used within the package being developed? If the computations involve a lot of linear/matrix algebra, then one could just use R with other linear algebra routines (e.g., OpenBLAS, Atlas, MKL, BLIS) and get the performance benefits of multicore processing of those computations without having to change a single line of code in the package (although in my experience, most of the performance benefits come from switching to something like OpenBLAS and using it single-threaded). This aside, I am personally more in favor of explicitly parallelizing those things that are known to be embarrassingly parallelizable using packages like parallel, future, etc. since a package author should know best when these situations arise and can take the necessary steps to parallelize those computations -- but making the use of parallel processing in these cases an option, not a default. I have seen way too many cases in HPC environments where jobs are being parallelized, the package is doing parallel processing, and multicore linear algebra routines are being used all simultaneously, which is just a disaster. Finally, I don't think the HPC task view has been mentioned so far: https://cran.r-project.org/web/views/HighPerformanceComputing.html (not even by Dirk just now, who maintains it!) Best, Wolfgang >-Original Message- >From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf >Of >Dirk Eddelbuettel >Sent: Saturday, 09 October, 2021 18:33 >To: Ben Bolker >Cc: r-package-devel@r-project.org >Subject: Re: [R-pkg-devel] [Tagged] Re: multithreading in packages > > >On 9 October 2021 at 12:08, Ben Bolker wrote: >|FWIW there is some machinery in the glmmTMB package for querying, >| setting, etc. the number of OpenMP threads. >| >| https://github.com/glmmTMB/glmmTMB/search?q=omp > >https://cloud.r-project.org/package=RhpcBLASctl > >Dirk > >-- >https://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-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] Re: What is a "retired"package?
:) That's a fortune nomination on my part. Best, Wolfgang >-Original Message- >From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf >Of >Hadley Wickham >Sent: Tuesday, 21 September, 2021 20:45 >To: Lenth, Russell V >Cc: r-package-devel@r-project.org >Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package? > >Yes, as Lionel said that is why we have changed our terminology to >superseded — we wanted to imply that a retired package was still a >useful member of society, if not working full-time anymore, but most >people seem to think that retired means that we took the package out >behind the shed and put it out of its misery. > >Haley > >On Tue, Sep 21, 2021 at 1:43 PM Lenth, Russell V > wrote: >> >> Hadley, >> >> As I suspected, and a good point. But please note that the term "retired" >> causes >angst, and it may be good to change that to "superceded" or something else. >> >> As a side note, I'll mention that I myself am retired, and I'll claim that >> that >does not make me less dependable. But one difference in retirement is that I >now >care less about public embarrassment, such as not knowing that all along, I >could >have used base::apply instead of plyr::aaply. >> >> -Original Message- >> From: Hadley Wickham >> Sent: Tuesday, September 21, 2021 11:48 AM >> To: Lenth, Russell V >> Cc: Jeff Newmiller ; r-package-devel@r-project.org >> Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package? >> >> > But for the broader question, Jeff is saying that there really are 700 >packages that are in potential trouble! >> >> I think that's rather an overstatement of the problem — there's nothing wrong >with plyr; it's just no longer under active development. >> If anything, plyr is one of the safest packages to depend upon because you >> can >know it will never change :) >> >> Hadley >> >> -- >> http://hadley.nz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] sum() and mean() for (ALTREP) integer sequences
Wow, thanks for this extensive reply, Andre. As Duncan mentioned, it's probably
not worth the bother for such a rare case. And my curiosity as to why the
timing difference was happening has been more than satisfied.
Best,
Wolfgang
>-Original Message-
>From: GILLIBERT, Andre [mailto:andre.gillib...@chu-rouen.fr]
>Sent: Thursday, 02 September, 2021 21:54
>To: Viechtbauer, Wolfgang (SP); r-devel@r-project.org
>Subject: RE: sum() and mean() for (ALTREP) integer sequences
>
>Hello,
>
>Please, find a long response below.
>
>== difference between mean(x) and sum(x)/length(x) ==
>
>At the core, mean(x) and sum(x)/length(x) works very differently for real
>numbers.
>Mean is more accurate when applied to a vector with a small variance but a very
>high mean, especially on platforms without extended precision numbers (i.e.
>long
>double is 64 bits rather than 80 bits).
>
>On a Windows 10 computer (with 80 bits long double):
>k=1e6
>base=2^51
>realmean = mean(1:k)
>sqa=(base+1):(base+k) # with ALTREP
>sq=(base+1):(base+k)+0.0 # without ALTREP
>mean(sq) - base - realmean # correctly returns zero
>sum(sq)/k - base - realmean # incorrectly returns -0.5
>sum(sqa)/k - base - realmean # correctly returns zero
>
>On a GNU/Linux x86_64 computer with extended precision floating point disabled,
>the difference is worse:
>mean(sq) - base - realmean # correctly returns zero
>sum(sq)/k - base - realmean # incorrectly returns -1180
>sum(sqa)/k - base - realmean # correctly returns zero
>
>Therefore (without ALTREP) sum can be inaccurate, due to floating point
>rounding
>errors.
>
>The good accuracy of mean() is due to a two-passes algorithm of the real_mean()
>function in src/main/summary.c.
>
>The algorithm can be summarized by the following equivalent R code:
>badmean=function(v) {sum(v)/length(v)}
>goodmean=function(v) {center = badmean(v); center + badmean(v - center)}
>goodmean(sq) - base - realmean # correctly returns zero
>
>== should mean() call ALTINTEGER_SUM ? ==
>As you noticed in the examples above, sum() is much more accurate with ALTREPs
>than with the naive algorithm, because there are no cumulative rounding errors.
>
>Moreover, if we focus on INTSXP, the maximum possible value is lower : INT_MAX
>=
>2^31-1
>The sum of a large sequence (e.g. 1:(2^31-1)) can still overflow the exact
>integer
>range (0 to 2^53) of an FP64, and the division does not always round back to
>the
>correct value.
>
>bad = 1:189812531L
>mean(bad) - sum(bad)/length(bad) # returns -1.5e-08 on a platform with FP80
>mean(bad) == 94906266 # correct value (the actual result is an integer)
>
>The implementation of mean() on INTSXP do not use the two-passes trick, but
>relies
>on a LDOUBLE (typically FP80 on the x86 platform) that is large enough to avoid
>rounding bugs even with huge integer sequences.
>
>Unfortunately the ALTINTEGER_SUM interface returns at best a FP64, and so,
>would
>not return the FP64 closest to the actual mean for some sequences.
>
>Adding a MEAN function to the ALTREP interface could solve the problem.
>
>== can mean performance be improved easily ? ==
>
>The mean() implementation for integers, supports ALTREPs with poor iteration
>performances, using the slow INTEGER_ELT() macro.
>Moreover, it converts each integer to LDOUBLE, which is slow.
>
>It can be improved using ITERATE_BY_REGION0 and using a 64 bits integer (if
>available) that cannot overflow on small batches (size = 512).
>
># before patching (on Ubuntu x86_64 Silvermont Celeron J1900)
>x = 1:1e8
>y = 1:1e8+0L
>system.time(mean(x)) # user 1.33 second
>system.time(mean(y)) # user 0.32 second
>
># after patching (on Ubuntu x86_64 Silvermont Celeron J1900)
># after patching (on Ubuntu x86_64 Silvermont Celeron J1900)
>x = 1:1e8
>y = 1:1e8+0L
>system.time(mean(x)) # user 0.29 second # more than x4 faster
>system.time(mean(y)) # user 0.18 second # x 1.7 faster !
>
>(patch attached to this message)
>
>The patch is not optimal. It should ideally use isum(), and risum() but these
>functions are a mess, needing refactoring. For instance, they take a 'call'
>argument and may display a warning message related to the sum() function.
>
>--
>Sincerely
>Andre GILLIBERT
>
>De : R-devel de la part de Viechtbauer,
>Wolfgang
>(SP)
>Envoyé : jeudi 2 septembre 2021 12:55:03
>À : r-devel@r-project.org
>Objet : [Rd] sum() and mean() for (ALTREP) integer sequences
>
>Hi all,
>
>I am trying to understand the performance of functions applied to integer
>sequences. Consider the following:
>
>### begin example ###
>
>library(lobstr)
>library(microbenchmark)
>
>
Re: [Rd] sum() and mean() for (ALTREP) integer sequences
>> Hi all,
>>
>> I am trying to understand the performance of functions applied to integer
>sequences. Consider the following:
>>
>> ### begin example ###
>>
>> library(lobstr)
>> library(microbenchmark)
>>
>> x <- sample(1e6)
>> obj_size(x)
>> # 4,000,048 B
>>
>> y <- 1:1e6
>> obj_size(y)
>> # 680 B
>>
>> # So we can see that 'y' uses ALTREP. These are, as expected, the same:
>>
>> sum(x)
>> # [1] 5050
>> sum(y)
>> # [1] 5050
>>
>> # For 'x', we have to go through the trouble of actually summing up 1e6
>integers.
>> # For 'y', knowing its form, we really just need to do:
>>
>> 1e6*(1e6+1)/2
>> # [1] 5050
>>
>> # which should be a whole lot faster. And indeed, it is:
>>
>> microbenchmark(sum(x),sum(y))
>>
>> # Unit: nanoseconds
>> #exprmin lq mean median uqmax neval cld
>> # sum(x) 533452 595204.5 634266.90 613102.5 638271.5 978519 100 b
>> # sum(y)183245.5446.09338.5447.0 3233 100 a
>>
>> # Now what about mean()?
>>
>> mean(x)
>> # [1] 50.5
>> mean(y)
>> # [1] 50.5
>>
>> # which is the same as
>>
>> (1e6+1)/2
>> # [1] 50.5
>>
>> # But this surprised me:
>>
>> microbenchmark(mean(x),mean(y))
>>
>> # Unit: microseconds
>> # expr minlq mean median uq max neval cld
>> # mean(x) 935.389 943.4795 1021.423 954.689 985.122 2065.974 100 a
>> # mean(y) 3500.262 3581.9530 3814.664 3637.984 3734.598 5866.768 100 b
>>
>> ### end example ###
>>
>> So why is mean() on an ALTREP sequence slower when sum() is faster?
>>
>> And more generally, when using sum() on an ALTREP integer sequence, does R
>actually use something like n*(n+1)/2 (or generalized to sequences a:b --
>(a+b)*(b-a+1)/2) for computing the sum? If so, why not (it seems) for mean()?
>
>The mean.default function looks like this:
>
>function (x, trim = 0, na.rm = FALSE, ...)
>{
> if (!is.numeric(x) && !is.complex(x) && !is.logical(x)) {
> warning("argument is not numeric or logical: returning NA")
> return(NA_real_)
> }
> if (na.rm)
> x <- x[!is.na(x)]
> if (!is.numeric(trim) || length(trim) != 1L)
> stop("'trim' must be numeric of length one")
> n <- length(x)
> if (trim > 0 && n) {
> if (is.complex(x))
> stop("trimmed means are not defined for complex data")
> if (anyNA(x))
> return(NA_real_)
> if (trim >= 0.5)
> return(stats::median(x, na.rm = FALSE))
> lo <- floor(n * trim) + 1
> hi <- n + 1 - lo
> x <- sort.int(x, partial = unique(c(lo, hi)))[lo:hi]
> }
> .Internal(mean(x))
>}
>
>So it does fixups for trimming and NA removal, then calls an internal
>function. The internal function is the first part of do_summary, here:
>
>https://github.com/wch/r-
>source/blob/f9c955fc6699a1f0482e4281ba658215c0e0b949/src/main/summary.c#L541-L556
>
>It is using separate functions for the mean by type. The real_mean
>function here:
>
>https://github.com/wch/r-
>source/blob/f9c955fc6699a1f0482e4281ba658215c0e0b949/src/main/summary.c#L476-L515
>
>makes a big effort to avoid overflows.
>
>So I suspect the reason mean.default doesn't use sum(x)/length(x) at the
>end is that on a long vector sum(x) could overflow when mean(x) shouldn't.
>
>So why not take the ALTREP into account? I suspect it's just too much
>trouble for a rare case.
>
>Duncan Murdoch
Hi Duncan,
Thanks for pointing me to the appropriate places in the C code. And ok, makes
sense.
Best,
Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sum() and mean() for (ALTREP) integer sequences
Hi all, I am trying to understand the performance of functions applied to integer sequences. Consider the following: ### begin example ### library(lobstr) library(microbenchmark) x <- sample(1e6) obj_size(x) # 4,000,048 B y <- 1:1e6 obj_size(y) # 680 B # So we can see that 'y' uses ALTREP. These are, as expected, the same: sum(x) # [1] 5050 sum(y) # [1] 5050 # For 'x', we have to go through the trouble of actually summing up 1e6 integers. # For 'y', knowing its form, we really just need to do: 1e6*(1e6+1)/2 # [1] 5050 # which should be a whole lot faster. And indeed, it is: microbenchmark(sum(x),sum(y)) # Unit: nanoseconds #exprmin lq mean median uqmax neval cld # sum(x) 533452 595204.5 634266.90 613102.5 638271.5 978519 100 b # sum(y)183245.5446.09338.5447.0 3233 100 a # Now what about mean()? mean(x) # [1] 50.5 mean(y) # [1] 50.5 # which is the same as (1e6+1)/2 # [1] 50.5 # But this surprised me: microbenchmark(mean(x),mean(y)) # Unit: microseconds # expr minlq mean median uq max neval cld # mean(x) 935.389 943.4795 1021.423 954.689 985.122 2065.974 100 a # mean(y) 3500.262 3581.9530 3814.664 3637.984 3734.598 5866.768 100 b ### end example ### So why is mean() on an ALTREP sequence slower when sum() is faster? And more generally, when using sum() on an ALTREP integer sequence, does R actually use something like n*(n+1)/2 (or generalized to sequences a:b -- (a+b)*(b-a+1)/2) for computing the sum? If so, why not (it seems) for mean()? Best, Wolfgang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] [External] R package submission fails due to using LaTeX functions that have not been implemented for building pdfs (not due to mathjaxr)
That doesn't seem to work for me (or I am not following this suggestion
properly). But putting \if{html}{\eqn{}} before \mjeqn{}{} does. A bit of a
hackish solution, but if it works, it works.
Not sure why \mjeqn{}{} at the beginning of a paragraph actually leads to a
line break, but it's yet again one of these quirks that is good to document.
Best,
Wolfgang
>-Original Message-
>From: Richard M. Heiberger [mailto:r...@temple.edu]
>Sent: Friday, 25 June, 2021 16:53
>To: Marc Scherstjanoi
>Cc: Viechtbauer, Wolfgang (SP); r-package-devel@r-project.org
>Subject: Re: [External] [R-pkg-devel] R package submission fails due to using
>LaTeX functions that have not been implemented for building pdfs (not due to
>mathjaxr)
>
>> One more question. If I use mjeqn at the beginning of a paragraph it
>automatically sets a line break afterwards.
>> Any idea what I can do to prevent this?
>
>follow it with
>\vspace*{1ex}
>to back up one line.
>
>Rich
>
>> On Jun 25, 2021, at 07:51, Marc Scherstjanoi
>wrote:
>>
>> Hi Wolfgang,
>>
>> thank you for this information.
>> I will try with \mjtdeqn and stick to the intended latex functions for
>> building
>the pdf.
>> Moreover, we will bring up the more complicated equations in a vignette pdf.
>>
>> One more question. If I use mjeqn at the beginning of a paragraph it
>automatically sets a line break afterwards.
>> Any idea what I can do to prevent this?
>>
>> Best regards,
>> Marc
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] speeding up package code/build/test cycle
Dear Greg, You might want to look into the load_all() function from 'devtools'. Best, Wolfgang >-Original Message- >From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf >Of >Greg Minshall >Sent: Thursday, 24 June, 2021 11:16 >To: r-package-devel@r-project.org >Subject: [R-pkg-devel] speeding up package code/build/test cycle > >hi. > >when developing packages, my current work flow is to change the code, >(re-)build the package, detach/load the package, test (to find the >N+1'st bug, sigh). > >the building step takes tens of seconds. > >is there an obvious way to present some code to the R command line and >have it replace the appropriate function in a given package? > >or, are there other things people do to speed up this process? > >thanks in advance, Greg __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R package submission fails due to mathjaxr package
Hi Marc,
Thanks for the additional details.
As far as I can tell, the problem has nothing to do with mathjaxr, but your use
of LaTeX commands that are not supported in creating the pdf manual (which is
not done by mathjaxr but R itself). See:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Mathematics
You can use AMS extensions for the HTML docs since those are supported by
Mathjax, but not for the pdf manual.
So, for the pdf manual, you will have to write the equation without the use of
AMS extensions (and indeed use \mjtdeqn).
Best,
Wolfgang
>-Original Message-
>From: Marc Scherstjanoi [mailto:marc.scherstja...@thuenen.de]
>Sent: Sunday, 20 June, 2021 23:16
>To: Viechtbauer, Wolfgang (SP)
>Cc: Tiago Olivoto; Max Turgeon; r-package-devel@r-project.org
>Subject: Re: R package submission fails due to mathjaxr package
>
>Hi Wolfgang, Tiago and Max
>
>thank you for your reply. Let me first apologize. "due to mathjaxr" sounds a
>bit
>harsh after the second reading.
>I am very thankful for this nice package. It works really well for all of the
>equations I have, and the HTML it creates is just nice.
>The only problem is the PDF and I also found out that the align function
>(amsmath
>latex package) is the actual error source. Furthermore, "\cr" is also giving an
>error message.
>
>For example, having
>
>\mjdeqn{\begin{align} A_e(t) &= \left(A^T \cdot xi(t) \right)^T \cr &= A \cdot
>diag(xi(t)) \end{align}}{Ae(t) = (A^T * xi(t))^T = A * diag(xi(t))}
>
>in the \details section of the .Rd file leads to
>
>"LaTeX errors:
>! LaTeX Error: Environment align undefined."
>
>when building with "R CMD build /home/.../package"
>
>but passes with "R CMD build /home/.../package --no-manual".
>
>The aim of the align command is to set several equations in certain horizontal
>positions (mostly oriented on the "="s, indicated by the "&"s) one below the
>other.
>I read about the possibility to use \mjtdeqn instead of \mjdeqn to specify
>LaTeX
>commands for the PDF and HTML pages differently.
>However, if the pdf necessarily needs to be created when submitting the
>package,
>it would be better to have the equations aligned there as well.
>For readability it would be a plus as I don't just have a couple of equations
>and
>equation systems.
>
>We are using the following setup:
>Added "mathjaxr" to Imports and RdMacros fields of the DESCRIPTION file.
>Added import(mathjaxr) to the NAMESPACE file.
>Added "\loadmathjax" to the \description section.
>
>I would be grateful for any idea how to convince the pdfTeX of the align
>command
>or a similar solution.
>
>Marc
>
>- Ursprüngliche Mail -
>Von: "Viechtbauer, Wolfgang (SP)"
>
>An: "Marc Scherstjanoi" , r-package-devel@r-
>project.org
>Gesendet: Sonntag, 20. Juni 2021 11:08:56
>Betreff: RE: R package submission fails due to mathjaxr package
>
>Hi Marc,
>
>mathjaxr maintainer here. Can you provide a minimal reproducible example
>illustrating the problem? If this is another case where the LaTeX command for
>Mathjax does not work directly for creating the pdf (or vice-versa), then I
>would
>like to document this (and a possible workaround) as was done here:
>
>https://github.com/wviechtb/mathjaxr#issues
>
>Best,
>Wolfgang
>
>>-Original Message-
>>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>>Behalf Of
>>Marc Scherstjanoi
>>Sent: Friday, 18 June, 2021 22:22
>>To: r-package-devel@r-project.org
>>Subject: [R-pkg-devel] R package submission fails due to mathjaxr package
>>
>>Hi,
>>
>>I am about to sumbmit an R package.
>>
>>It passed the
>>"R CMD check /package... --as-cran --no-manual"
>>but not the
>>"R CMD check /package... --as-cran".
>>
>>Our way of presenting mathematical equations by using the mathjaxr package
>>seems
>>to be not supported.
>>As a result, building pdf fails automatically.
>>
>>We have already been aware of that and would like to submit the
>>package manual pdf separately.
>>
>>How can this be done?
>>Can our submission work without the rd to pdf process?
>>Or is there a way to include the mathjaxr style for the texing?
>>
>>Thank you in advance,
>>
>>Marc
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R package submission fails due to mathjaxr package
Hi Marc, mathjaxr maintainer here. Can you provide a minimal reproducible example illustrating the problem? If this is another case where the LaTeX command for Mathjax does not work directly for creating the pdf (or vice-versa), then I would like to document this (and a possible workaround) as was done here: https://github.com/wviechtb/mathjaxr#issues Best, Wolfgang >-Original Message- >From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf >Of >Marc Scherstjanoi >Sent: Friday, 18 June, 2021 22:22 >To: r-package-devel@r-project.org >Subject: [R-pkg-devel] R package submission fails due to mathjaxr package > >Hi, > >I am about to sumbmit an R package. > >It passed the >"R CMD check /package... --as-cran --no-manual" >but not the >"R CMD check /package... --as-cran". > >Our way of presenting mathematical equations by using the mathjaxr package >seems >to be not supported. >As a result, building pdf fails automatically. > >We have already been aware of that and would like to submit the >package manual pdf separately. > >How can this be done? >Can our submission work without the rd to pdf process? >Or is there a way to include the mathjaxr style for the texing? > >Thank you in advance, > >Marc __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] URL checks
>>>>>> Viechtbauer, Wolfgang (SP)
>>>>>> on Fri, 8 Jan 2021 13:50:14 + writes:
>
>> Instead of a separate file to store such a list, would it be an idea
>to add versions of the \href{}{} and \url{} markup commands that are skipped
>by the URL checks?
>> Best,
>> Wolfgang
>
>I think John Nash and you misunderstood -- or then I
>misunderstood -- the original proposal:
>
>I've been understanding that there should be a "central repository" of URL
>exceptions that is maintained by volunteers.
>
>And rather *not* that package authors should get ways to skip
>URL checking..
>
>Martin
Hi Martin,
Kirill suggested: "A file inst/URL that lists all URLs where failures are
allowed -- possibly with a list of the HTTP codes accepted for that link."
So, if it is a file in inst/, then this sounds to me like this is part of the
package and not part of some central repository.
Best,
Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] URL checks
Instead of a separate file to store such a list, would it be an idea to add
versions of the \href{}{} and \url{} markup commands that are skipped by the
URL checks?
Best,
Wolfgang
>-Original Message-
>From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Spencer
>Graves
>Sent: Friday, 08 January, 2021 13:04
>To: r-devel@r-project.org
>Subject: Re: [Rd] URL checks
>
> I also would be pleased to be allowed to provide "a list of known
>false-positive/exceptions" to the URL tests. I've been challenged
>multiple times regarding URLs that worked fine when I checked them. We
>should not be required to do a partial lobotomy to pass R CMD check ;-)
>
> Spencer Graves
>
>On 2021-01-07 09:53, Hugo Gruson wrote:
>>
>> I encountered the same issue today with https://astrostatistics.psu.edu/.
>>
>> This is a trust chain issue, as explained here:
>> https://whatsmychaincert.com/?astrostatistics.psu.edu.
>>
>> I've worked for a couple of years on a project to increase HTTPS
>> adoption on the web and we noticed that this type of error is very
>> common, and that website maintainers are often unresponsive to requests
>> to fix this issue.
>>
>> Therefore, I totally agree with Kirill that a list of known
>> false-positive/exceptions would be a great addition to save time to both
>> the CRAN team and package developers.
>>
>> Hugo
>>
>> On 07/01/2021 15:45, Kirill Müller via R-devel wrote:
>>> One other failure mode: SSL certificates trusted by browsers that are
>>> not installed on the check machine, e.g. the "GEANT Vereniging"
>>> certificate from https://relational.fit.cvut.cz/ .
>>>
>>> K
>>>
>>> On 07.01.21 12:14, Kirill Müller via R-devel wrote:
Hi
The URL checks in R CMD check test all links in the README and
vignettes for broken or redirected links. In many cases this improves
documentation, I see problems with this approach which I have
detailed below.
I'm writing to this mailing list because I think the change needs to
happen in R's check routines. I propose to introduce an "allow-list"
for URLs, to reduce the burden on both CRAN and package maintainers.
Comments are greatly appreciated.
Best regards
Kirill
# Problems with the detection of broken/redirected URLs
## 301 should often be 307, how to change?
Many web sites use a 301 redirection code that probably should be a
307. For example, https://www.oracle.com and https://www.oracle.com/
both redirect to https://www.oracle.com/index.html with a 301. I
suspect the company still wants oracle.com to be recognized as the
primary entry point of their web presence (to reserve the right to
move the redirection to a different location later), I haven't
checked with their PR department though. If that's true, the redirect
probably should be a 307, which should be fixed by their IT
department which I haven't contacted yet either.
$ curl -i https://www.oracle.com
HTTP/2 301
server: AkamaiGHost
content-length: 0
location: https://www.oracle.com/index.html
...
## User agent detection
twitter.com responds with a 400 error for requests without a user
agent string hinting at an accepted browser.
$ curl -i https://twitter.com/
HTTP/2 400
...
...Please switch to a supported browser..
$ curl -s -i https://twitter.com/ -A "Mozilla/5.0 (X11; Ubuntu; Linux
x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" | head -n 1
HTTP/2 200
# Impact
While the latter problem *could* be fixed by supplying a browser-like
user agent string, the former problem is virtually unfixable -- so
many web sites should use 307 instead of 301 but don't. The above
list is also incomplete -- think of unreliable links, HTTP links,
other failure modes...
This affects me as a package maintainer, I have the choice to either
change the links to incorrect versions, or remove them altogether.
I can also choose to explain each broken link to CRAN, this subjects
the team to undue burden I think. Submitting a package with NOTEs
delays the release for a package which I must release very soon to
avoid having it pulled from CRAN, I'd rather not risk that -- hence I
need to remove the link and put it back later.
I'm aware of https://github.com/r-lib/urlchecker, this alleviates the
problem but ultimately doesn't solve it.
# Proposed solution
## Allow-list
A file inst/URL that lists all URLs where failures are allowed --
possibly with a list of the HTTP codes accepted for that link.
Example:
https://oracle.com/ 301
https://twitter.com/drob/status/1224851726068527106 400
__
R-devel@r-project.org mailing list
Re: [R-pkg-devel] [External] Re: Two packages with the same generic function
Still, if pkgA imports the generic from pkgB, then installing pkgA installs
pkgB and all of its dependencies (Depends and Imports). Which of course makes
sense (as otherwise pkgB cannot be installed). But all of this just for
importing
foo <- function(x, ...)
UseMethod("foo")
from pkgB.
Best,
Wolfgang
>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>Behalf Of Duncan Murdoch
>Sent: Tuesday, 23 June, 2020 12:25
>To: Guido Schwarzer; r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] [External] Re: Two packages with the same generic
>function
>
>On 23/06/2020 4:22 a.m., Guido Schwarzer wrote:
>> Am 23.06.20 um 10:00 schrieb Viechtbauer, Wolfgang (SP):
>>> [...]
>>> @Neal: A separate package with generic functions that pkgA and pkgB could
>import is an interesting suggestion, thanks!
>>
>> What makes this interesting is that there is no dependency on other
>> packages in generics.
>>
>> Remains the question which help page would be shown for help(foo).
>
>If a package imports and then exports the generic, it would normally
>create a help page referring to the original one where the generic is
>defined. So both pkgA and pkgB would probably both create help pages,
>and the help system would show a page listing them both plus the generic
>one, and asking the user to choose.
>
>An example happens if you use
>
>library(broom)
>?tidy
>
>The broom package links to a page that says "These objects are imported
>from other packages. Follow the links below to see their documentation."
>One of the links is to the ?tidy page in the generics package.
>
>You are allowed to say ?broom::tidy, and then you don't go to the list
>of possibilities, you go directly to the one you asked for.
>
>Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] Re: Two packages with the same generic function
; >>> Sure it does, if pkgA and pkgB both export the same name, then you get
>> a
>> >>> warning when you attach the second one. For example,
>> >>>
>> >>> > library(MASS)
>> >>> > library(dplyr)
>> >>>
>> >>> Attaching package: ‘dplyr’
>> >>>
>> >>> The following object is masked from ‘package:MASS’:
>> >>>
>> >>> select
>> >>>
>> >>> The following objects are masked from ‘package:stats’:
>> >>>
>> >>> filter, lag
>> >>>
>> >>> The following objects are masked from ‘package:base’:
>> >>>
>> >>> intersect, setdiff, setequal, union
>> >>>
>> >>> Users don't get warned about overriding names in packages they've
>> >>> loaded, because that would just be irritating.
>> >>>
>> >>> Duncan Murdoch
>> >>>>
>> >>>> So, we might try protecting the generic definitions of "foo" in both
>> >>>> packages by enclosing them in something like:
>> >>>>
>> >>>> tryCatch(invisible(methods("foo")), error = {foo <- function(x,...)
>> >>>>> UseMethod("foo")}, finally=NULL)
>> >>>>
>> >>>>
>> >>>> There's probably a more elegant way to accomplish this. This relies
>on
>> >>>> "methods" returning an error if "foo" has no defined methods, so it
>is
>> >>> not
>> >>>> redefined if their are previous methods. I haven't had time to try
>> this
>> >>> in
>> >>>> the two-package example, but it might work, although I'm not sure how
>> >> to
>> >>>> handle the Namespace declarations.
>> >>>>
>> >>>>Tom Wainwright
>> >>>>
>> >>>> On Mon, Jun 22, 2020 at 10:41 AM Bert Gunter
>> >>> wrote:
>> >>>>
>> >>>>> ...
>> >>>>> and just to add to the query, assume the author of pkg B did (does)
>> >> not
>> >>>>> know of pkg A and so, for example, could (did) not import any of pkg
>> >> A's
>> >>>>> content into B. Given that there are at the moment ~20,000 packages
>> >> out
>> >>>>> there, this does not seem to be an unreasonable assumption. One may
>> >> even
>> >>>>> further assume that the user may not know that (s)he has package B
>> >>> loaded,
>> >>>>> as it may be a dependency of another package that (s)he uses. I
>> >>> certainly
>> >>>>> don't keep track of all the dependencies of packages I use.
>> >>>>>
>> >>>>> Under these assumptions, is there any more convenient alternative to
>> >>>>> Wolfgang's pkgA:foo(x) explicit call under such assumptions? If pkgA
>> >>> has a
>> >>>>> long name, what might one do?
>> >>>>>
>> >>>>> Bert Gunter
>> >>>>>
>> >>>>> "The trouble with having an open mind is that people keep coming
>> along
>> >>> and
>> >>>>> sticking things into it."
>> >>>>> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
>> >>>>>
>> >>>>>
>> >>>>> On Mon, Jun 22, 2020 at 10:00 AM Viechtbauer, Wolfgang (SP) <
>> >>>>> wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
>> >>>>>
>> >>>>>> Hi All,
>> >>>>>>
>> >>>>>> Let's say there are two packages pkgA and pkgB, both of which have
>a
>> >>>>>> generic function
>> >>>>>>
>> >>>>>> foo <- function(x, ...)
>> >>>>>> UseMethod("foo")
>> >>>>>>
>> >>>>>> and pkgA has a method for objects of class "A":
>> >>>>>>
>> >>>>>> foo.A <- function(x, ...)
>> >>>>>> print(x)
>> >>>>>>
>> >>>>>> and pkgB has a method for objects of class "B":
>> >>>>>>
>> >>>>>> foo.B <- function(x, ...)
>> >>>>>> plot(x)
>> >>>>>>
>> >>>>>> Both packages export foo and their method and declare their
>> >> respective
>> >>> S3
>> >>>>>> methods, so:
>> >>>>>>
>> >>>>>> export(foo)
>> >>>>>> export(foo.A)
>> >>>>>> S3method(foo, A)
>> >>>>>>
>> >>>>>> in NAMESPACE of pkgA and
>> >>>>>>
>> >>>>>> export(foo)
>> >>>>>> export(foo.B)
>> >>>>>> S3method(foo, B)
>> >>>>>>
>> >>>>>> in NAMESPACE of pkgB.
>> >>>>>>
>> >>>>>> If a user loads pkgA first and then pkgB, this fails:
>> >>>>>>
>> >>>>>> library(pkgA)
>> >>>>>> library(pkgB)
>> >>>>>> x <- 1:4
>> >>>>>> class(x) <- "A"
>> >>>>>> foo(x)
>> >>>>>>
>> >>>>>> Error in UseMethod("foo") :
>> >>>>>>no applicable method for 'foo' applied to an object of class "A"
>> >>>>>>
>> >>>>>> and vice-versa. Of course, pkgA::foo(x) works. Aside from pkgA
>> >>> importing
>> >>>>>> foo() or vice-versa, is there some other clever way to make this
>> >> work?
>> >>> In
>> >>>>>> earlier versions of R (at least in 3.6.3), this used to work (i.e.,
>> >> the
>> >>>>>> generic foo() from pkgB would find method foo.A() and vice-versa),
>> >> but
>> >>>>> not
>> >>>>>> since 4.0.0.
>> >>>>>>
>> >>>>>> Best,
>> >>>>>> Wolfgang
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Two packages with the same generic function
Hi All,
Let's say there are two packages pkgA and pkgB, both of which have a generic
function
foo <- function(x, ...)
UseMethod("foo")
and pkgA has a method for objects of class "A":
foo.A <- function(x, ...)
print(x)
and pkgB has a method for objects of class "B":
foo.B <- function(x, ...)
plot(x)
Both packages export foo and their method and declare their respective S3
methods, so:
export(foo)
export(foo.A)
S3method(foo, A)
in NAMESPACE of pkgA and
export(foo)
export(foo.B)
S3method(foo, B)
in NAMESPACE of pkgB.
If a user loads pkgA first and then pkgB, this fails:
library(pkgA)
library(pkgB)
x <- 1:4
class(x) <- "A"
foo(x)
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "A"
and vice-versa. Of course, pkgA::foo(x) works. Aside from pkgA importing foo()
or vice-versa, is there some other clever way to make this work? In earlier
versions of R (at least in 3.6.3), this used to work (i.e., the generic foo()
from pkgB would find method foo.A() and vice-versa), but not since 4.0.0.
Best,
Wolfgang
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] Possible bug in heatmap()?
Dear All, There might be a bug in heatmap(): x <- matrix(rnorm(10*5), 10, 5) heatmap(x, labCol=1:5) Error in axis(1, 1L:nc, labels = labCol, las = 2, line = -0.5, tick = 0, : 'at' and 'labels' lengths differ, 5 != 10 Works fine under 4.0.1. Looking at the code from 4.0.1 vs. Rdevel, esp. this part sticks out: labRow <- labRow[rowInd] %||% rownames(x) %||% (1L:nr)[rowInd] labCol <- labCol[rowInd] %||% colnames(x) %||% (1L:nc)[colInd] Maybe this should be: labCol <- labCol[colInd] %||% colnames(x) %||% (1L:nc)[colInd] > sessionInfo() R Under development (unstable) (2020-06-21 r78727) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.6 LTS Matrix products: default BLAS: /home/wviechtb/rdev/lib/libRblas.so LAPACK: /home/wviechtb/rdev/lib/libRlapack.so locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 [4] LC_COLLATE=C LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C LC_ADDRESS=C [10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.1.0 Best, Wolfgang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] RES: RES: MathJax for Rd files
I've added a preview_rd() function to the 'devel' version of mathjaxr:
https://github.com/wviechtb/mathjaxr
If you want to give this a try:
remotes::install_github("wviechtb/mathjaxr")
library(mathjaxr)
Then set the working dir to the root of the package you are working on. Then
use:
preview_rd(Rdfile)
with the name of the Rd file given as a character string (either with or
without the .Rd/.rd extension).
By default, the browser (or a new tab in your browser) should open up. But if
you then make further changes to the Rd file, opening up a new tab each time is
inconvenient. Use:
preview_rd(Rdfile, view=FALSE)
to prevent that (then just refresh the page in the open tab in your browser to
see the updates).
One limitation: As far as I can tell, it will not be possible to load MathJax
from the mathjaxr package when using preview_rd(). So, it will be loaded via
the CDN, which means that you need an internet connection for equations to
render.
Best,
Wolfgang
>-Original Message-
>From: Tiago Olivoto [mailto:tiagooliv...@gmail.com]
>Sent: Wednesday, 13 May, 2020 21:25
>To: 'Duncan Murdoch'; Viechtbauer, Wolfgang (SP); r-package-devel@r-
>project.org
>Subject: RES: RES: [R-pkg-devel] RES: MathJax for Rd files
>
>Definitively this is a better way to find the macros.
>I think a function like 'preview_rd()' could be useful in mathjaxr
>
>Thanks for all support
>Olivoto
>
>-Mensagem original-
>De: Duncan Murdoch
>Enviada em: quarta-feira, 13 de maio de 2020 16:16
>Para: tiagooliv...@gmail.com; 'Viechtbauer, Wolfgang (SP)'
>; r-package-devel@r-
>project.org
>Assunto: Re: RES: [R-pkg-devel] RES: MathJax for Rd files
>
>On 13/05/2020 2:30 p.m., Tiago Olivoto wrote:
>> Thank you so much! It works!
>> In my example, I've created a simple helper function, preview_rd()
>>
>> preview_rd <- function(rdfile){ # without '.rd'
>> Rd <- file.path(paste("man/", rdfile, ".rd", sep = "")) # specify the
>> .Rd file you want to preview outfile <- tempfile(fileext = ".html")
>> browseURL(tools::Rd2HTML(Rd, outfile,
>> macros="D:/Documents/R/win-library/4.0/mathjaxr/help/macros/mathjax.Rd
>> "))
>> }
>
>Good to hear. I'd suggest this way to find the macros:
>
> browseURL(tools::Rd2HTML(Rd, outfile, macros =
>system.file("help/macros/mathjax.Rd", package = "mathjaxr")))
>
>so that it works if you use it on a different system that puts the library
>somewhere else.
>
>Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] RES: MathJax for Rd files
Glad to hear that. I might consider adding a function along those lines to
mathjaxr itself, to make it easier to preview files while working on a help
page.
Best,
Wolfgang
>-Original Message-
>From: Tiago Olivoto [mailto:tiagooliv...@gmail.com]
>Sent: Wednesday, 13 May, 2020 20:31
>To: Viechtbauer, Wolfgang (SP); 'Duncan Murdoch'; r-package-devel@r-
>project.org
>Subject: RES: [R-pkg-devel] RES: MathJax for Rd files
>
>Thank you so much! It works!
>In my example, I've created a simple helper function, preview_rd()
>
>preview_rd <- function(rdfile){ # without '.rd'
>Rd <- file.path(paste("man/", rdfile, ".rd", sep = "")) # specify the .Rd
>file you want to preview
>outfile <- tempfile(fileext = ".html")
>browseURL(tools::Rd2HTML(Rd, outfile, macros="D:/Documents/R/win-
>library/4.0/mathjaxr/help/macros/mathjax.Rd"))
>}
>
>I added the macros \loadmathjax and \mjsdeqn in the mgidi.R file, ran
>devtools::document() and then preview_rd("mgidi")
>The html was rendered nicely (in my browser) and shows the equation without
>installing the package.
>That's what I was looking for.
>Thanks again!
>Olivoto
>
>-Mensagem original-
>De: Viechtbauer, Wolfgang (SP)
>
>Enviada em: quarta-feira, 13 de maio de 2020 14:41
>Para: Duncan Murdoch ; tiagooliv...@gmail.com; r-
>package-de...@r-project.org
>Assunto: RE: [R-pkg-devel] RES: MathJax for Rd files
>
>Thanks, Duncan. I was about to respond to suggest the same thing.
>
>One way of getting this to work:
>
>Sys.setenv(MATHJAXR.USECDN = "TRUE")
>Rd <- file.path("/.Rd") # specify the .Rd file you want to
>preview outfile <- tempfile(fileext = ".html") browseURL(tools::Rd2HTML(Rd,
>outfile, macros="installed>/mathjaxr/help/macros/mathjax.Rd"))
>
>Best,
>Wolfgang
>
>>-Original Message-
>>From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>>Sent: Wednesday, 13 May, 2020 19:30
>>To: tiagooliv...@gmail.com; Viechtbauer, Wolfgang (SP); 'Helmut
>>Schütz'; r- package-de...@r-project.org
>>Subject: Re: [R-pkg-devel] RES: MathJax for Rd files
>>
>>On 13/05/2020 12:35 p.m., Tiago Olivoto wrote:
>>> Thanks, Wolfgang and Helmut for the explanations.
>>> When I was trying to use
>>>
>>> #'\if{html}{\out{'>> #''src="<a rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full">https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full</a>
>>> .js
>>> #' }}
>>> #'
>>> #'And then typing
>>> #' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
>>> My mgidi.Rd file was produced with devtools::document(); then, I just
>>> used ?mgidi, and the html page was rendered nicely.
>>>
>>> If I could do the same with mathjaxr, It would be nice, because I
>>> wouldn't
>>need to install the package to see if the equations are as I expect
>>> Anyway, mathjaxr is a very useful package.
>>> Congratulations on the efforts for developing it.
>>
>>Sounds like it's a devtools issue. I don't know how they are
>>simulating the install, but it needs to say to use the mathjaxr macros
>>when converting the Rd pages.
>>
>>Duncan Murdoch
>>
>>> Best
>>> Olivoto
>>>
>>> -Mensagem original-
>>> De: Viechtbauer, Wolfgang (SP)
>>
>>> Enviada em: quarta-feira, 13 de maio de 2020 13:14
>>> Para: Helmut Schütz ;
>>> tiagooliv...@gmail.com; r-
>>package-de...@r-project.org
>>> Assunto: RE: [R-pkg-devel] MathJax for Rd files
>>>
>>> Thanks for the info! Can confirm now that I tried this (I don't
>>> usually
>>use RStudio). That's an RStudio issue then. My guess is that 'Preview'
>>uses
>>tools::Rd2HTML() and that indeed won't automatically understand macros
>>coming from mathjaxr (or any add-on package for that matter). This
>>would be an issue to raise with the RStudio folks then.
>>>
>>> But once a package is installed, the equations are nicely rendered
>>> also in
>>the RStudio help browser, so that part works.
>>>
>>> Best,
>>> Wolfgang
>>>
>>>> -Original Message-
>>>> From: Helmut Schütz [mailto:helmut.schu...@bebac.at]
>>>> Sent: Wednesday, 13 May, 2020 17:01
>>>> To: Viechtbauer, Wolfgang (SP); tiagooliv...@gmail.com;
>>>> r-package-devel@r- project.org
>>>> Subject: Re: [R-pkg-devel] MathJax for Rd files
>>>>
>>>> Hi Wolfgang,
>>>>
>>>> Viechtbauer, Wolfgang (SP) wrote on 2020-05-13 16:53:
>>>>> Seems like you are using roxygen2. I have little experience with
>>>>> that, as
>>>> all my Rd files are 'handcrafted' (plus 100% organic and biodegradable).
>>>>
>>>> As are mine. ;-)
>>>> In the HTML-preview of RStudio the LaTeX is indeed not parsed. I get
>>>> it only (in the HTML man-page and the PDF) if I build the package.
>>>>
>>>> Helmut
>>>>
>>>> --
>>>> Ing. Helmut Schütz
>>>> BEBAC – Consultancy Services for
>>>> Bioequivalence and Bioavailability Studies Neubaugasse 36/11
>>>> 1070 Vienna, Austria
>>>> E helmut.schu...@bebac.at
>>>> W https://bebac.at/
>>>> F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] RES: MathJax for Rd files
Thanks, Duncan. I was about to respond to suggest the same thing.
One way of getting this to work:
Sys.setenv(MATHJAXR.USECDN = "TRUE")
Rd <- file.path("/.Rd") # specify the .Rd file you want to preview
outfile <- tempfile(fileext = ".html")
browseURL(tools::Rd2HTML(Rd, outfile, macros="/mathjaxr/help/macros/mathjax.Rd"))
Best,
Wolfgang
>-Original Message-
>From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>Sent: Wednesday, 13 May, 2020 19:30
>To: tiagooliv...@gmail.com; Viechtbauer, Wolfgang (SP); 'Helmut Schütz'; r-
>package-de...@r-project.org
>Subject: Re: [R-pkg-devel] RES: MathJax for Rd files
>
>On 13/05/2020 12:35 p.m., Tiago Olivoto wrote:
>> Thanks, Wolfgang and Helmut for the explanations.
>> When I was trying to use
>>
>> #'\if{html}{\out{'> #''src="<a rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js">https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js</a>
>> #' }}
>> #'
>> #'And then typing
>> #' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
>> My mgidi.Rd file was produced with devtools::document();
>> then, I just used ?mgidi, and the html page was rendered nicely.
>>
>> If I could do the same with mathjaxr, It would be nice, because I wouldn't
>need to install the package to see if the equations are as I expect
>> Anyway, mathjaxr is a very useful package.
>> Congratulations on the efforts for developing it.
>
>Sounds like it's a devtools issue. I don't know how they are simulating
>the install, but it needs to say to use the mathjaxr macros when
>converting the Rd pages.
>
>Duncan Murdoch
>
>> Best
>> Olivoto
>>
>> -Mensagem original-
>> De: Viechtbauer, Wolfgang (SP)
>
>> Enviada em: quarta-feira, 13 de maio de 2020 13:14
>> Para: Helmut Schütz ; tiagooliv...@gmail.com; r-
>package-de...@r-project.org
>> Assunto: RE: [R-pkg-devel] MathJax for Rd files
>>
>> Thanks for the info! Can confirm now that I tried this (I don't usually
>use RStudio). That's an RStudio issue then. My guess is that 'Preview' uses
>tools::Rd2HTML() and that indeed won't automatically understand macros
>coming from mathjaxr (or any add-on package for that matter). This would be
>an issue to raise with the RStudio folks then.
>>
>> But once a package is installed, the equations are nicely rendered also in
>the RStudio help browser, so that part works.
>>
>> Best,
>> Wolfgang
>>
>>> -Original Message-
>>> From: Helmut Schütz [mailto:helmut.schu...@bebac.at]
>>> Sent: Wednesday, 13 May, 2020 17:01
>>> To: Viechtbauer, Wolfgang (SP); tiagooliv...@gmail.com;
>>> r-package-devel@r- project.org
>>> Subject: Re: [R-pkg-devel] MathJax for Rd files
>>>
>>> Hi Wolfgang,
>>>
>>> Viechtbauer, Wolfgang (SP) wrote on 2020-05-13 16:53:
>>>> Seems like you are using roxygen2. I have little experience with
>>>> that, as
>>> all my Rd files are 'handcrafted' (plus 100% organic and biodegradable).
>>>
>>> As are mine. ;-)
>>> In the HTML-preview of RStudio the LaTeX is indeed not parsed. I get it
>>> only (in the HTML man-page and the PDF) if I build the package.
>>>
>>> Helmut
>>>
>>> --
>>> Ing. Helmut Schütz
>>> BEBAC – Consultancy Services for
>>> Bioequivalence and Bioavailability Studies Neubaugasse 36/11
>>> 1070 Vienna, Austria
>>> E helmut.schu...@bebac.at
>>> W https://bebac.at/
>>> F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] MathJax for Rd files
Thanks for the info! Can confirm now that I tried this (I don't usually use RStudio). That's an RStudio issue then. My guess is that 'Preview' uses tools::Rd2HTML() and that indeed won't automatically understand macros coming from mathjaxr (or any add-on package for that matter). This would be an issue to raise with the RStudio folks then. But once a package is installed, the equations are nicely rendered also in the RStudio help browser, so that part works. Best, Wolfgang >-Original Message- >From: Helmut Schütz [mailto:helmut.schu...@bebac.at] >Sent: Wednesday, 13 May, 2020 17:01 >To: Viechtbauer, Wolfgang (SP); tiagooliv...@gmail.com; r-package-devel@r- >project.org >Subject: Re: [R-pkg-devel] MathJax for Rd files > >Hi Wolfgang, > >Viechtbauer, Wolfgang (SP) wrote on 2020-05-13 16:53: >> Seems like you are using roxygen2. I have little experience with that, as >all my Rd files are 'handcrafted' (plus 100% organic and biodegradable). > >As are mine. ;-) >In the HTML-preview of RStudio the LaTeX is indeed not parsed. I get it >only (in the HTML man-page and the PDF) if I build the package. > >Helmut > >-- >Ing. Helmut Schütz >BEBAC – Consultancy Services for >Bioequivalence and Bioavailability Studies >Neubaugasse 36/11 >1070 Vienna, Austria >E helmut.schu...@bebac.at >W https://bebac.at/ >F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] MathJax for Rd files
Seems like you are using roxygen2. I have little experience with that, as all
my Rd files are 'handcrafted' (plus 100% organic and biodegradable).
But what specifically do you mean by "when I try to preview the current
document as HTML"? Is this some particular functionality of roxygen2 / devtools
/ RStudio? Or do you simply mean using tools::Rd2HTML()? Then you will have to
use permissive=TRUE so that the macros from mathjaxr (which will not be
recognized by default by parse_Rd()) are just passed through as text. Or you
could try adjusting the 'macros' argument, maybe in combination with
loadPkgRdMacros(), to specify that the mathjaxr macros should be loaded. See
help(Rd2HTML, package="tools") and help(parse_Rd, package="tools") for details.
But if I want to see the HTML help file, I just install and load the package
and call up the help file on some function. That works for sure.
As for the more complex equation - it includes a lot of curly braces. See the
note I added recently to the 'devel' version about this:
https://github.com/wviechtb/mathjaxr#issues
Best,
Wolfgang
>-Original Message-
>From: Tiago Olivoto [mailto:tiagooliv...@gmail.com]
>Sent: Wednesday, 13 May, 2020 16:20
>To: Viechtbauer, Wolfgang (SP); r-package-devel@r-project.org
>Subject: RES: [R-pkg-devel] MathJax for Rd files
>
>Dear Wolfgang,
>Thank you so much for the awesome package
>I've installed mathjaxr and it worked.
>I have some more questions, with a short example bellow
>I created an equation in my mgidi.R file as follows
>
>#' \loadmathjax
>#' \mjsdeqn{MGIDI_i = \sum\limits_{j = 1}^f}
>
>And then I ran devtools::document()
>The mgidi.Rd contains
>
>\loadmathjax
>\mjsdeqn{MGIDI_i = \sum\limits_{j = 1}^f}
>
>But when I try to preview the current document as HTML, the equation is not
>rendered and the help page shows
>\loadmathjax \mjsdeqnMGIDI_i = \sum\limits_j = 1^f
>The equation is only rendered after I install my package locally with
>devtools::install(). Is this an expected behavior?
>
>Another question is regarding more complex formulae.
>I tried using
>#' \loadmathjax
>#' \mjsdeqn{MGID{I_i} = {\left[ {\sum\limits_{j = 1}^f {{{\left( {{F_{ij}} -
>{F_j}} \right)}^2}} } \right]^{0.5}}}
>
>Even after installing the package locally the equation is not rendered in
>the html help page, which shows the tex command.
>I tested the same equation with https://www.mathjax.org/#demo and it seems
>to be ok.
>Have I missed anything or used any code not supported by mathjaxr?
>Thanks in advance
>Olivoto
>
>-Mensagem original-
>De: Viechtbauer, Wolfgang (SP)
>
>Enviada em: quarta-feira, 13 de maio de 2020 04:40
>Para: tiagooliv...@gmail.com; r-package-devel@r-project.org
>Assunto: RE: [R-pkg-devel] MathJax for Rd files
>
>Dear Olivoto,
>
>There is a package now for this purpose:
>
>https://cran.r-project.org/package=mathjaxr
>https://github.com/wviechtb/mathjaxr
>
>Best,
>Wolfgang
>
>>-Original Message-
>>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>>Behalf Of Tiago Olivoto
>>Sent: Wednesday, 13 May, 2020 8:55
>>To: r-package-devel@r-project.org
>>Subject: [R-pkg-devel] MathJax for Rd files
>>
>>Dear all,
>>
>>I'm not sure if this is the correct place to make this question, but
>>here I am.
>>
>>I'm trying to use MathJax for html help files in my package metan
>>(https://cran.r-project.org/package=metan)
>>
>>I have success with the following approach:
>>
>>Including the following call
>>
>>#'\if{html}{\out{
>>
>>#'>
>>#'src="<a rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js">https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js</a>
>>">
>>
>>#'
>>
>>#'}}
>>
>>And then typing the equations I need. A simple example bellow
>>
>>#' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
>>
>>Is there any way to put "tex-chtml-full.js" locally so that everyone
>>that has my package installed see the equations rendered properly even
>offline?
>>
>>Thanks in advance
>>
>>Olivoto
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] MathJax for Rd files
Dear Olivoto,
There is a package now for this purpose:
https://cran.r-project.org/package=mathjaxr
https://github.com/wviechtb/mathjaxr
Best,
Wolfgang
>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>Behalf Of Tiago Olivoto
>Sent: Wednesday, 13 May, 2020 8:55
>To: r-package-devel@r-project.org
>Subject: [R-pkg-devel] MathJax for Rd files
>
>Dear all,
>
>I'm not sure if this is the correct place to make this question, but here I
>am.
>
>I'm trying to use MathJax for html help files in my package metan
>(https://cran.r-project.org/package=metan)
>
>I have success with the following approach:
>
>Including the following call
>
>#'\if{html}{\out{
>
>#'
>#'src="https://cdn.jsdelivr.net/npm/mathjax@3.0.5/es5/tex-chtml-full.js";>
>
>#'
>
>#'}}
>
>And then typing the equations I need. A simple example bellow
>
>#' \ifelse{html}{\out{\[\sqrt{a^2}\]}}{\deqn{\sqrt{a^2}}}
>
>Is there any way to put "tex-chtml-full.js" locally so that everyone that
>has my package installed see the equations rendered properly even offline?
>
>Thanks in advance
>
>Olivoto
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] S3 method dispatch for methods in local environments
Thanks, Sebastian, for the pointer to the NEWS item. After some further search,
I also found this in the R Blog:
https://developer.r-project.org/Blog/public/2019/08/19/s3-method-lookup/
Best,
Wolfgang
>-Original Message-
>From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Sebastian
>Meyer
>Sent: Tuesday, 12 May, 2020 21:17
>To: r-devel@r-project.org
>Subject: Re: [Rd] S3 method dispatch for methods in local environments
>
>Dear Wolfgang,
>
>I think this new behaviour is related to the following R 4.0.0 NEWS item:
>
>> S3 method lookup now by default skips the elements of the search path
>between the global and base environments.
>
>Your environment "myenv" is attached at position 2 of the search() path
>and thus now skipped in S3 method lookup.
>
>I have just noticed that
>
>attr(methods(class="myclass"), "info")
>getS3method("print", "myclass")
>
>both still find your function in myenv although the generic's
>UseMethod() won't. I find this a bit confusing.
>
>A solution to make R >= 4.0.0 find your method is to register the S3
>method using the new function .S3method (intended for R scripts, not
>packages). After running
>
>.S3method("print", "myclass", myenv$print.myclass)
>
>your method will be found from the generic.
>
>Best regards,
>
> Sebastian
>
>
>Am 12.05.20 um 20:05 schrieb Viechtbauer, Wolfgang (SP):
>> Dear All,
>>
>> In R 3.6.3 (and earlier), method dispatch used to work for methods stored
>in local environments that are attached to the search path. For example:
>>
>> myfun <- function(y) {
>>out <- list(y=y)
>>class(out) <- "myclass"
>>return(out)
>> }
>>
>> print.myclass <- function(x, ...) print(formatC(x$y, format="f",
>digits=5))
>>
>> myfun(1:4)
>>
>> # prints: [1] "1.0" "2.0" "3.0" "4.0"
>>
>> rm(print.myclass)
>> myenv <- new.env()
>> myenv$print.myclass <- local(function(x, ...) print(formatC(x$y,
>format="f", digits=5)), myenv)
>> attach(myenv)
>> myfun(1:4)
>>
>> # still prints: [1] "1.0" "2.0" "3.0" "4.0"
>>
>> But since R 4.0.0, this no longer words and the above prints:
>>
>> $y
>> [1] 1 2 3 4
>>
>> attr(,"class")
>> [1] "myclass"
>>
>> Is this intended? And is there a way to still make this work?
>>
>> Best,
>> Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 method dispatch for methods in local environments
Indeed, that works:
myfun <- function(y) {
out <- list(y=y)
class(out) <- "myclass"
return(out)
}
myenv <- new.env()
myenv$print.myclass <- local(function(x, ...) print(formatC(x$y, format="f",
digits=5)), new.env(myenv))
.S3method("print", "myclass", myenv$print.myclass)
attach(myenv)
myfun(1:4)
# [1] "1.0" "2.0" "3.0" "4.0"
Thanks for the tip!
Best,
Wolfgang
>-Original Message-
>From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
>Sent: Tuesday, 12 May, 2020 21:05
>To: Viechtbauer, Wolfgang (SP)
>Cc: r-devel (r-devel@r-project.org)
>Subject: Re: [Rd] S3 method dispatch for methods in local environments
>
>>>>>> Viechtbauer, Wolfgang (SP)
>>>>>> on Tue, 12 May 2020 18:05:32 + writes:
>
>> Dear All,
>> In R 3.6.3 (and earlier), method dispatch used to work for methods
>stored in local environments that are attached to the search path. For
>example:
>
>> myfun <- function(y) {
>> out <- list(y=y)
>> class(out) <- "myclass"
>> return(out)
>> }
>
>> print.myclass <- function(x, ...) print(formatC(x$y, format="f",
>digits=5))
>
>> myfun(1:4)
>
>> # prints: [1] "1.0" "2.0" "3.0" "4.0"
>
>> rm(print.myclass)
>> myenv <- new.env()
>> myenv$print.myclass <- local(function(x, ...) print(formatC(x$y,
>format="f", digits=5)), myenv)
>> attach(myenv)
>> myfun(1:4)
>
>> # still prints: [1] "1.0" "2.0" "3.0" "4.0"
>
>> But since R 4.0.0, this no longer words and the above prints:
>
>> $y
>> [1] 1 2 3 4
>
>> attr(,"class")
>> [1] "myclass"
>
>> Is this intended?
>
>yes, most probably, unless
>
>> And is there a way to still make this work?
>
>Using the new
>
> .S3method(, , )
>
>had been intended as substitute. Can you try it with your
>attached-environment (which makes sense!) approach ?
>
>Best,
>Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S3 method dispatch for methods in local environments
Dear All,
In R 3.6.3 (and earlier), method dispatch used to work for methods stored in
local environments that are attached to the search path. For example:
myfun <- function(y) {
out <- list(y=y)
class(out) <- "myclass"
return(out)
}
print.myclass <- function(x, ...) print(formatC(x$y, format="f", digits=5))
myfun(1:4)
# prints: [1] "1.0" "2.0" "3.0" "4.0"
rm(print.myclass)
myenv <- new.env()
myenv$print.myclass <- local(function(x, ...) print(formatC(x$y, format="f",
digits=5)), myenv)
attach(myenv)
myfun(1:4)
# still prints: [1] "1.0" "2.0" "3.0" "4.0"
But since R 4.0.0, this no longer words and the above prints:
$y
[1] 1 2 3 4
attr(,"class")
[1] "myclass"
Is this intended? And is there a way to still make this work?
Best,
Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of MathJax (or something similar) in .Rd files
Hi All,
After some tinkering, and with support from Duncan, I put together a package
that allows for easy inclusion of MathJax equations in Rd files. The package
has been submitted to CRAN, but those who want to try this out already can get
it here:
https://github.com/wviechtb/mathjaxr
or in other words:
install.packages("remotes")
remotes::install_github("wviechtb/mathjaxr")
Package authors can then use the \loadmathjax macro to enable its use and the
\mjeqn{latex}{ascii} and \mjdeqn{latex}{ascii} macros for including inline and
displayed equations.
Feedback and suggestions more than welcome!
Best,
Wolfgang
>-Original Message-
>From: Ravi Varadhan [mailto:ravi.varad...@jhu.edu]
>Sent: Thursday, 30 April, 2020 15:58
>To: Viechtbauer, Wolfgang (SP); r-devel
>Subject: Re: [Rd] Use of MathJax (or something similar) in .Rd files
>
>Thank you. This is a very useful idea!
>
>Best,
>Ravi
>________
>From: R-devel on behalf of Viechtbauer,
>Wolfgang (SP)
>Sent: Thursday, April 30, 2020 6:59:02 AM
>To: r-devel
>Subject: Re: [Rd] Use of MathJax (or something similar) in .Rd files
>
>Thanks Gabor and Duncan! It works. For those interested, I added this to the
>beginning of the \details{} section:
>
>\if{html}{\out{
> src="<a rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"">https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"</a>;>
>
>}}
>
>And then I can use:
>
>\if{html}{\out{\(B_{x(a,b)} = \int_0^x t^{a-1} (1-t)^{b-1} dt\)}}
>
>or
>
>\if{html}{\out{\[B_{x(a,b)} = \int_0^x t^{a-1} (1-t)^{b-1} dt\]}}
>
>to render the equation (inline or as 'displaymath'). I'll try to add MathJax
>locally next.
>
>Best,
>Wolfgang
>
>>-Original Message-
>>From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>>Sent: Thursday, 30 April, 2020 12:22
>>To: Viechtbauer, Wolfgang (SP); r-devel
>>Subject: Re: [Rd] Use of MathJax (or something similar) in .Rd files
>>
>>On 30/04/2020 6:15 a.m., Viechtbauer, Wolfgang (SP) wrote:
>>> Interesting. I gave this a try, but couldn't make this work. One would
>>have to infuse something like
>>>
>>> >> src="<a rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"">https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"</a>;>
>>>
>>>
>>> or
>>>
>>> >> src="<url-to-your-site>/mathjax/tex-chtml.js">
>>>
>>>
>>> into the .html file, but just adding this to the .Rd file (directly or
>>wrapped with \if{html}{}) doesn't do that (it just gets printed). If
>>somebody has already successfully done this, I would be interested in
>>hearing how.
>>
>>You'd need to wrap that code in \out (inside the conditional, i.e.
>>something like
>>
>>\if{html}{\out{>src="<url-to-your-site>/mathjax/tex-chtml.js">}}
>>
>>Duncan Murdoch
>>
>>>
>>> Best,
>>> Wolfgang
>>>
>>>> -Original Message-
>>>> From: Gábor Csárdi [mailto:csardi.ga...@gmail.com]
>>>> Sent: Thursday, 30 April, 2020 11:51
>>>> To: Viechtbauer, Wolfgang (SP)
>>>> Cc: r-devel
>>>> Subject: Re: [Rd] Use of MathJax (or something similar) in .Rd files
>>>>
>>>> You can probably already do this using the \if{html} conditional, and
>>>> either including the matchjax js files in the package, or getting them
>>>>from a CDN.
>>>>
>>>> Gabor
>>>>
>>>> On Thu, Apr 30, 2020 at 9:13 AM Viechtbauer, Wolfgang (SP)
>>>> wrote:
>>>>>
>>>>> Hello All,
>>>>>
>>>>> I am wondering if there has ever been any discussion/consideration
>given
>>>> to incorporating MathJax (or something similar) into R for rendering
>>>> equations in .Rd files. I know that equations are rendered beautifully
>in
>>>> the pdf manuals, but I suspect the majority of users primarily look at
>>the
>>>> html help files when using R. While I am comfortable reading something
>>like
>>>> "B_x(a,b) = integral_0^x t^(a-1) (1-t)^(b-1) dt", it would definitely be
>>>> nicer if this was shown as a 'proper' equation.
>>>>>
>>>>> Best,
>>>>> Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of MathJax (or something similar) in .Rd files
Thanks Gabor and Duncan! It works. For those interested, I added this to the
beginning of the \details{} section:
\if{html}{\out{
https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"</a>;>
}}
And then I can use:
\if{html}{\out{\(B_{x(a,b)} = \int_0^x t^{a-1} (1-t)^{b-1} dt\)}}
or
\if{html}{\out{\[B_{x(a,b)} = \int_0^x t^{a-1} (1-t)^{b-1} dt\]}}
to render the equation (inline or as 'displaymath'). I'll try to add MathJax
locally next.
Best,
Wolfgang
>-Original Message-
>From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
>Sent: Thursday, 30 April, 2020 12:22
>To: Viechtbauer, Wolfgang (SP); r-devel
>Subject: Re: [Rd] Use of MathJax (or something similar) in .Rd files
>
>On 30/04/2020 6:15 a.m., Viechtbauer, Wolfgang (SP) wrote:
>> Interesting. I gave this a try, but couldn't make this work. One would
>have to infuse something like
>>
>> >src="<a rel="nofollow" href="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"">https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"</a>;>
>>
>>
>> or
>>
>> >src="<url-to-your-site>/mathjax/tex-chtml.js">
>>
>>
>> into the .html file, but just adding this to the .Rd file (directly or
>wrapped with \if{html}{}) doesn't do that (it just gets printed). If
>somebody has already successfully done this, I would be interested in
>hearing how.
>
>You'd need to wrap that code in \out (inside the conditional, i.e.
>something like
>
>\if{html}{\out{src="<url-to-your-site>/mathjax/tex-chtml.js">}}
>
>Duncan Murdoch
>
>>
>> Best,
>> Wolfgang
>>
>>> -Original Message-
>>> From: Gábor Csárdi [mailto:csardi.ga...@gmail.com]
>>> Sent: Thursday, 30 April, 2020 11:51
>>> To: Viechtbauer, Wolfgang (SP)
>>> Cc: r-devel
>>> Subject: Re: [Rd] Use of MathJax (or something similar) in .Rd files
>>>
>>> You can probably already do this using the \if{html} conditional, and
>>> either including the matchjax js files in the package, or getting them
>>>from a CDN.
>>>
>>> Gabor
>>>
>>> On Thu, Apr 30, 2020 at 9:13 AM Viechtbauer, Wolfgang (SP)
>>> wrote:
>>>>
>>>> Hello All,
>>>>
>>>> I am wondering if there has ever been any discussion/consideration given
>>> to incorporating MathJax (or something similar) into R for rendering
>>> equations in .Rd files. I know that equations are rendered beautifully in
>>> the pdf manuals, but I suspect the majority of users primarily look at
>the
>>> html help files when using R. While I am comfortable reading something
>like
>>> "B_x(a,b) = integral_0^x t^(a-1) (1-t)^(b-1) dt", it would definitely be
>>> nicer if this was shown as a 'proper' equation.
>>>>
>>>> Best,
>>>> Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of MathJax (or something similar) in .Rd files
Interesting. I gave this a try, but couldn't make this work. One would have to
infuse something like
https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"</a>;>
or
into the .html file, but just adding this to the .Rd file (directly or wrapped
with \if{html}{}) doesn't do that (it just gets printed). If somebody has
already successfully done this, I would be interested in hearing how.
Best,
Wolfgang
>-Original Message-
>From: Gábor Csárdi [mailto:csardi.ga...@gmail.com]
>Sent: Thursday, 30 April, 2020 11:51
>To: Viechtbauer, Wolfgang (SP)
>Cc: r-devel
>Subject: Re: [Rd] Use of MathJax (or something similar) in .Rd files
>
>You can probably already do this using the \if{html} conditional, and
>either including the matchjax js files in the package, or getting them
>from a CDN.
>
>Gabor
>
>On Thu, Apr 30, 2020 at 9:13 AM Viechtbauer, Wolfgang (SP)
> wrote:
>>
>> Hello All,
>>
>> I am wondering if there has ever been any discussion/consideration given
>to incorporating MathJax (or something similar) into R for rendering
>equations in .Rd files. I know that equations are rendered beautifully in
>the pdf manuals, but I suspect the majority of users primarily look at the
>html help files when using R. While I am comfortable reading something like
>"B_x(a,b) = integral_0^x t^(a-1) (1-t)^(b-1) dt", it would definitely be
>nicer if this was shown as a 'proper' equation.
>>
>> Best,
>> Wolfgang
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Use of MathJax (or something similar) in .Rd files
Hello All, I am wondering if there has ever been any discussion/consideration given to incorporating MathJax (or something similar) into R for rendering equations in .Rd files. I know that equations are rendered beautifully in the pdf manuals, but I suspect the majority of users primarily look at the html help files when using R. While I am comfortable reading something like "B_x(a,b) = integral_0^x t^(a-1) (1-t)^(b-1) dt", it would definitely be nicer if this was shown as a 'proper' equation. Best, Wolfgang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Require -package.Rd?
Hi Dirk, Point well taken, but the same goes for many other CRAN requirements. For example, I can create totally useless help files for all the functions that pass all checks. Just because some will try to skirt around a requirement doesn't mean it's a useless requirement. In fact, the point of such requirements is to promote good practices and I would like to believe that most package authors would make an honest effort to create a somewhat useful -package.Rd file, even (as Joris pointed out) it is essentially just a pointer to the vignette(s) (which is also useful). Best, Wolfgang -Original Message- From: Dirk Eddelbuettel [mailto:e...@debian.org] Sent: Tuesday, 24 September, 2019 14:39 To: joris.m...@ugent.be Cc: Viechtbauer, Wolfgang (SP); r-package-devel@r-project.org Subject: Re: [R-pkg-devel] Require -package.Rd? Wolfgang, Joris, This may not necessarily work -- see "Goodhart's Law" [1] Once you impose something like this, (some) will skirt it with just the minimum requirement of an (essentially) empty file. An existing set of examples is provided by the vignettes of (at least) one developer which each consist (or consisted ?) of just a single line with a hyperlink to the corresponding package website. Passes the letter of the law (hey, look, a vignette) and all possible tests, but clearly violates the spirit of the law that documentation and package should be self-contained (and no, connectivity should not be assumed). Moral persuasion may be better. We should encourage best practices and highlight packages that follow them. Dirk [1] https://en.wikipedia.org/wiki/Goodhart%27s_law -- 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] Require -package.Rd?
Hi All, When starting to work with an unfamiliar package, one might typically look for vignettes, a paper/book accompanying the package, a package website, and of course the help files themselves, but help(package="") is often not so useful -- such a listing of functions (with titles) might not clarify what the main 'workhorses' of the package are and how to get started. Personally, the first thing I do is try: help() in the hopes that the package author(s) have created a -package.Rd file to get new users started (or to point them to appropriate places to get going). In my experience, if such a package help file is available, it is tremendously useful. Unfortunately, many packages do not provide a -package.Rd file. I am curious how others and CRAN members would feel about making this a requirement (not retrospectively, but at least for new / resubmissions). Best, Wolfgang __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] Weird problem / bug with augPred() from nlme
Posted this to r-sig-mixed-models
(https://stat.ethz.ch/pipermail/r-sig-mixed-models/2019q1/027620.html) but this
might rather need to go to r-devel anyway, so reposting here:
I came across a weird problem / bug with augPred() from nlme (nlme_3.1-137).
Here is a reproducible example to illustrate the issue (tested on R 3.5.2 and
R-devel 2019-03-03 r76192):
library(nlme)
dat <- data.frame(id = c(1,1,1,2,3,3,4,4,4,4),
xi = c(1,2,3,1,1,2,1,2,3,4),
yi = c(2,1,4,2,3,2,5,4,6,8),
zi = c(rep("a",9), NA))
res1 <- lme(yi ~ xi, random = ~ 1 | id, data=dat)
sav1 <- augPred(res1, primary = ~ xi) # WORKS
dat$zi <- "a"
res2 <- lme(yi ~ xi, random = ~ 1 | id, data=dat)
sav2 <- augPred(res2, primary = ~ xi) # WORKS
dat$zi[10] <- NA
res3 <- lme(yi ~ xi, random = ~ 1 | id, data=dat)
sav3 <- augPred(res3, primary = ~ xi) # ERROR
The error message:
Error in `[[<-.data.frame`(`*tmp*`, nm, value = c(1L, 1L, 1L, 2L, 3L, :
replacement has 10 rows, data has 4
So, if 'zi' is a factor, then a missing value causes no problems (sav1). Or if
'zi' is a character variable without any missings, then augPred() also runs
(sav2). But if 'zi' is a character variable and there is at least one missing
value, then augPred() fails (sav3).
This aside, why does 'zi' even play a role here? It isn't used at all in the
model fit.
Best,
Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] xyTable(x,y) versus table(x,y) with NAs
Hi All, I asked this over at r-help, but didn't get any responses. As this seems like a bug (or at least undocumented behavior) to me, I'll try again here. It seems to me that xyTable() gets thrown off by NAs: x <- c(1, 1, 2, 2, 2, 3) y <- c(1, 2, 1, 3, NA, 3) table(x, y, useNA="always") xyTable(x, y) Is this intended behavior? Best, Wolfgang __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Font Size for View() under Linux
Hello, I am using Ubuntu 16.04, using the default (Unity) window manager. The font size using View() is way too small on a high dpi monitor. I already use scaling, but View() doesn't seem affected by that. On Windows, the font size for View() appears to be controlled by the font size specified under the Rgui preferences / Rconsole. I thought that under Linux, it might be controlled by some .Xresources/.Xdefaults setting. Any suggestions for how I could tweak the font size here? Best, Wolfgang -- Wolfgang Viechtbauer, Ph.D., Statistician | Department of Psychiatry and Neuropsychology | Maastricht University | P.O. Box 616 (VIJV1) | 6200 MD Maastricht, The Netherlands | +31 (43) 388-4170 | http://www.wvbauer.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Discourage the weights= option of lm with summarized data
Ah, I think you are referring to this part from ?lm: "(including the case that there are w_i observations equal to y_i and the data have been summarized)" I see; indeed, I don't think this is what 'weights' should be used for (the other part before that is correct). Sorry, I misunderstood the point you were trying to make. Best, Wolfgang -Original Message- From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Arie ten Cate Sent: Sunday, 08 October, 2017 14:55 To: r-devel@r-project.org Subject: [Rd] Discourage the weights= option of lm with summarized data Indeed: Using 'weights' is not meant to indicate that the same observation is repeated 'n' times. As I showed, this gives erroneous results. Hence I suggested that it is discouraged rather than encouraged in the Details section of lm in the Reference manual. Arie ---Original Message- On Sat, 7 Oct 2017, wolfgang.viechtba...@maastrichtuniversity.nl wrote: Using 'weights' is not meant to indicate that the same observation is repeated 'n' times. It is meant to indicate different variances (or to be precise, that the variance of the last observation in 'x' is sigma^2 / n, while the first three observations have variance sigma^2). Best, Wolfgang -Original Message- From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Arie ten Cate Sent: Saturday, 07 October, 2017 9:36 To: r-devel@r-project.org Subject: [Rd] Discourage the weights= option of lm with summarized data In the Details section of lm (linear models) in the Reference manual, it is suggested to use the weights= option for summarized data. This must be discouraged rather than encouraged. The motivation for this is as follows. With summarized data the standard errors get smaller with increasing numbers of observations. However, the standard errors in lm do not get smaller when for instance all weights are multiplied with the same constant larger than one, since the inverse weights are merely proportional to the error variances. Here is an example of the estimated standard errors being too large with the weights= option. The p value and the number of degrees of freedom are also wrong. The parameter estimates are correct. n <- 10 x <- c(1,2,3,4) y <- c(1,2,5,4) w <- c(1,1,1,n) xb <- c(x,rep(x[4],n-1)) # restore the original data yb <- c(y,rep(y[4],n-1)) print(summary(lm(yb ~ xb))) print(summary(lm(y ~ x, weights=w))) Compare with PROC REG in SAS, with a WEIGHT statement (like R) and a FREQ statement (for summarized data). Arie __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Discourage the weights= option of lm with summarized data
Using 'weights' is not meant to indicate that the same observation is repeated 'n' times. It is meant to indicate different variances (or to be precise, that the variance of the last observation in 'x' is sigma^2 / n, while the first three observations have variance sigma^2). Best, Wolfgang -Original Message- From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Arie ten Cate Sent: Saturday, 07 October, 2017 9:36 To: r-devel@r-project.org Subject: [Rd] Discourage the weights= option of lm with summarized data In the Details section of lm (linear models) in the Reference manual, it is suggested to use the weights= option for summarized data. This must be discouraged rather than encouraged. The motivation for this is as follows. With summarized data the standard errors get smaller with increasing numbers of observations. However, the standard errors in lm do not get smaller when for instance all weights are multiplied with the same constant larger than one, since the inverse weights are merely proportional to the error variances. Here is an example of the estimated standard errors being too large with the weights= option. The p value and the number of degrees of freedom are also wrong. The parameter estimates are correct. n <- 10 x <- c(1,2,3,4) y <- c(1,2,5,4) w <- c(1,1,1,n) xb <- c(x,rep(x[4],n-1)) # restore the original data yb <- c(y,rep(y[4],n-1)) print(summary(lm(yb ~ xb))) print(summary(lm(y ~ x, weights=w))) Compare with PROC REG in SAS, with a WEIGHT statement (like R) and a FREQ statement (for summarized data). Arie __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R-devel - missing some expected features (zlib, bzlib, lzma, PCRE)
Just a quick follow-up on this ... I was informed (off the mailing list) that this is all as it should be. A check with extSoftVersion() shows that everything is in order. Best, Wolfgang >-Original Message- >From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of >Viechtbauer Wolfgang (SP) >Sent: Thursday, June 22, 2017 12:49 >To: r-devel@r-project.org >Subject: [Rd] Compiling R-devel - missing some expected features (zlib, >bzlib, lzma, PCRE) > >Hi All, > >I am compiling R-devel on Linux (Ubuntu 16.04.2) and that works just fine, >but I am missing some of the expected features, as shown here: > >https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Linux > >In particular, after configure (using all defaults), I see: > >R is now configured for x86_64-pc-linux-gnu > > [...] > > Interfaces supported: X11 > External libraries:readline, curl > Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU > Options enabled: shared BLAS, R profiling > >Under 'External libraries', I am missing "zlib, bzlib, lzma, PCRE". As far >as I can tell, I have all necessary libs installed: > >wviechtb@psysim:~$ dpkg -l | grep zlib >ii zlib1g:amd641:1.2.8.dfsg-2ubuntu4.1 >ii zlib1g-dev:amd641:1.2.8.dfsg-2ubuntu4.1 >wviechtb@psysim:~$ dpkg -l | grep libbz >ii libbz2-1.0:amd641.0.6-8 >ii libbz2-dev:amd641.0.6-8 >wviechtb@psysim:~$ dpkg -l | grep liblzma >ii liblzma-dev:amd64 5.1.1alpha+20120614- >2ubuntu2 >ii liblzma5:amd64 5.1.1alpha+20120614- >2ubuntu2 >wviechtb@psysim:~$ dpkg -l | grep pcre >ii libpcre16-3:amd64 2:8.38-3.1 >ii libpcre3:amd64 2:8.38-3.1 >ii libpcre3-dev:amd64 2:8.38-3.1 >ii libpcre32-3:amd64 2:8.38-3.1 >ii libpcrecpp0v5:amd64 2:8.38-3.1 > >Any suggestions on what else I may need? > >Best, >Wolfgang > >-- >Wolfgang Viechtbauer, Ph.D., Statistician | Department of Psychiatry and >Neuropsychology | Maastricht University | P.O. Box 616 (VIJV1) | 6200 MD >Maastricht, The Netherlands | +31 (43) 388-4170 | http://www.wvbauer.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] lm() gives different results to lm.ridge() and SPSS
Well, one correction -- the 'standardized coefficients' that SPSS shows are
based on standardizing all variables separately (so x1, x2, and x1*x2 are all
standardized). So with respect to that, the criticism certainly stands.
-Original Message-
From: Viechtbauer Wolfgang (SP)
Sent: Friday, May 05, 2017 22:35
To: r-devel@r-project.org
Subject: RE: [Rd] lm() gives different results to lm.ridge() and SPSS
Totally agree that standardizing the interaction term is nonsense. But in all
fairness, SPSS doesn't do that. In fact, the 'REGRESSION' command in SPSS
doesn't compute any interaction terms -- one has to first compute them 'by
hand' and then add them to the model like any other variable. So somebody
worked extra hard to standardize that interaction term in SPSS as well :/
Best,
Wolfgang
-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Fox, John
Sent: Friday, May 05, 2017 20:23
To: Nick Brown; peter dalgaard
Cc: r-devel@r-project.org
Subject: Re: [Rd] lm() gives different results to lm.ridge() and SPSS
Dear Nick,
On 2017-05-05, 9:40 AM, "R-devel on behalf of Nick Brown"
<r-devel-boun...@r-project.org on behalf of nick.br...@free.fr> wrote:
>>I conjecture that something in the vicinity of
>> res <- lm(DEPRESSION ~ scale(ZMEAN_PA) + scale(ZDIVERSITY_PA) +
>>scale(ZMEAN_PA * ZDIVERSITY_PA), data=dat)
>>summary(res)
>> would reproduce the SPSS Beta values.
>
>Yes, that works. Thanks!
That you have to work hard in R to match the SPSS results isn’t such a bad
thing when you factor in the observation that standardizing the
interaction regressor, ZMEAN_PA * ZDIVERSITY_PA, separately from each of
its components, ZMEAN_PA and ZDIVERSITY_PA, is nonsense.
Best,
John
-
John Fox, Professor
McMaster University
Hamilton, Ontario, Canada
Web: http://socserv.mcmaster.ca/jfox/
>- Original Message -
>
>From: "peter dalgaard" <pda...@gmail.com>
>To: "Viechtbauer Wolfgang (SP)"
><wolfgang.viechtba...@maastrichtuniversity.nl>, "Nick Brown"
><nick.br...@free.fr>
>Cc: r-devel@r-project.org
>Sent: Friday, 5 May, 2017 3:33:29 PM
>Subject: Re: [Rd] lm() gives different results to lm.ridge() and SPSS
>
>Thanks, I was getting to try this, but got side tracked by actual work...
>
>Your analysis reproduces the SPSS unscaled estimates. It still remains to
>figure out how Nick got
>
>>
>coefficients(lm(ZDEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA, data=s1))
>
>(Intercept) ZMEAN_PA ZDIVERSITY_PA ZMEAN_PA:ZDIVERSITY_PA
>0.07342198 -0.39650356 -0.36569488 -0.09435788
>
>
>which does not match your output. I suspect that ZMEAN_PA and
>ZDIVERSITY_PA were scaled for this analysis (but the interaction term
>still obviously is not). I conjecture that something in the vicinity of
>
>res <- lm(DEPRESSION ~ scale(ZMEAN_PA) + scale(ZDIVERSITY_PA) +
>scale(ZMEAN_PA * ZDIVERSITY_PA), data=dat)
>summary(res)
>
>would reproduce the SPSS Beta values.
>
>> On 5 May 2017, at 14:43 , Viechtbauer Wolfgang (SP)
>><wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
>>
>> I had no problems running regression models in SPSS and R that yielded
>>the same results for these data.
>>
>> The difference you are observing is from fitting different models. In
>>R, you fitted:
>>
>> res <- lm(DEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA, data=dat)
>> summary(res)
>>
>> The interaction term is the product of ZMEAN_PA and ZDIVERSITY_PA. This
>>is not a standardized variable itself and not the same as "ZINTER_PA_C"
>>in the png you showed, which is not a variable in the dataset, but can
>>be created with:
>>
>> dat$ZINTER_PA_C <- with(dat, scale(ZMEAN_PA * ZDIVERSITY_PA))
>>
>> If you want the same results as in SPSS, then you need to fit:
>>
>> res <- lm(DEPRESSION ~ ZMEAN_PA + ZDIVERSITY_PA + ZINTER_PA_C,
>>data=dat)
>> summary(res)
>>
>> This yields:
>>
>> Coefficients:
>> Estimate Std. Error t value Pr(>|t|)
>> (Intercept) 6.41041 0.01722 372.21 <2e-16 ***
>> ZMEAN_PA -1.62726 0.04200 -38.74 <2e-16 ***
>> ZDIVERSITY_PA -1.50082 0.07447 -20.15 <2e-16 ***
>> ZINTER_PA_C -0.58955 0.05288 -11.15 <2e-16 ***
>> ---
>> Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
>>
>> Exactly the same as in the png.
>>
>> Peter already mentioned this as a possible reason for the discrepancy:
>>https://stat.ethz.ch/pipermail/r-devel/2017-May/074191.html ("Is it
>>perhaps the case that x1 and x2 have already been scaled to have
>>standard deviation 1? In that case, x1*x2 won't be.")
>>
>> Best,
>> Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] lm() gives different results to lm.ridge() and SPSS
Totally agree that standardizing the interaction term is nonsense. But in all
fairness, SPSS doesn't do that. In fact, the 'REGRESSION' command in SPSS
doesn't compute any interaction terms -- one has to first compute them 'by
hand' and then add them to the model like any other variable. So somebody
worked extra hard to standardize that interaction term in SPSS as well :/
Best,
Wolfgang
-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Fox, John
Sent: Friday, May 05, 2017 20:23
To: Nick Brown; peter dalgaard
Cc: r-devel@r-project.org
Subject: Re: [Rd] lm() gives different results to lm.ridge() and SPSS
Dear Nick,
On 2017-05-05, 9:40 AM, "R-devel on behalf of Nick Brown"
<r-devel-boun...@r-project.org on behalf of nick.br...@free.fr> wrote:
>>I conjecture that something in the vicinity of
>> res <- lm(DEPRESSION ~ scale(ZMEAN_PA) + scale(ZDIVERSITY_PA) +
>>scale(ZMEAN_PA * ZDIVERSITY_PA), data=dat)
>>summary(res)
>> would reproduce the SPSS Beta values.
>
>Yes, that works. Thanks!
That you have to work hard in R to match the SPSS results isn’t such a bad
thing when you factor in the observation that standardizing the
interaction regressor, ZMEAN_PA * ZDIVERSITY_PA, separately from each of
its components, ZMEAN_PA and ZDIVERSITY_PA, is nonsense.
Best,
John
-
John Fox, Professor
McMaster University
Hamilton, Ontario, Canada
Web: http://socserv.mcmaster.ca/jfox/
>- Original Message -
>
>From: "peter dalgaard" <pda...@gmail.com>
>To: "Viechtbauer Wolfgang (SP)"
><wolfgang.viechtba...@maastrichtuniversity.nl>, "Nick Brown"
><nick.br...@free.fr>
>Cc: r-devel@r-project.org
>Sent: Friday, 5 May, 2017 3:33:29 PM
>Subject: Re: [Rd] lm() gives different results to lm.ridge() and SPSS
>
>Thanks, I was getting to try this, but got side tracked by actual work...
>
>Your analysis reproduces the SPSS unscaled estimates. It still remains to
>figure out how Nick got
>
>>
>coefficients(lm(ZDEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA, data=s1))
>
>(Intercept) ZMEAN_PA ZDIVERSITY_PA ZMEAN_PA:ZDIVERSITY_PA
>0.07342198 -0.39650356 -0.36569488 -0.09435788
>
>
>which does not match your output. I suspect that ZMEAN_PA and
>ZDIVERSITY_PA were scaled for this analysis (but the interaction term
>still obviously is not). I conjecture that something in the vicinity of
>
>res <- lm(DEPRESSION ~ scale(ZMEAN_PA) + scale(ZDIVERSITY_PA) +
>scale(ZMEAN_PA * ZDIVERSITY_PA), data=dat)
>summary(res)
>
>would reproduce the SPSS Beta values.
>
>> On 5 May 2017, at 14:43 , Viechtbauer Wolfgang (SP)
>><wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
>>
>> I had no problems running regression models in SPSS and R that yielded
>>the same results for these data.
>>
>> The difference you are observing is from fitting different models. In
>>R, you fitted:
>>
>> res <- lm(DEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA, data=dat)
>> summary(res)
>>
>> The interaction term is the product of ZMEAN_PA and ZDIVERSITY_PA. This
>>is not a standardized variable itself and not the same as "ZINTER_PA_C"
>>in the png you showed, which is not a variable in the dataset, but can
>>be created with:
>>
>> dat$ZINTER_PA_C <- with(dat, scale(ZMEAN_PA * ZDIVERSITY_PA))
>>
>> If you want the same results as in SPSS, then you need to fit:
>>
>> res <- lm(DEPRESSION ~ ZMEAN_PA + ZDIVERSITY_PA + ZINTER_PA_C,
>>data=dat)
>> summary(res)
>>
>> This yields:
>>
>> Coefficients:
>> Estimate Std. Error t value Pr(>|t|)
>> (Intercept) 6.41041 0.01722 372.21 <2e-16 ***
>> ZMEAN_PA -1.62726 0.04200 -38.74 <2e-16 ***
>> ZDIVERSITY_PA -1.50082 0.07447 -20.15 <2e-16 ***
>> ZINTER_PA_C -0.58955 0.05288 -11.15 <2e-16 ***
>> ---
>> Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
>>
>> Exactly the same as in the png.
>>
>> Peter already mentioned this as a possible reason for the discrepancy:
>>https://stat.ethz.ch/pipermail/r-devel/2017-May/074191.html ("Is it
>>perhaps the case that x1 and x2 have already been scaled to have
>>standard deviation 1? In that case, x1*x2 won't be.")
>>
>> Best,
>> Wolfgang
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] lm() gives different results to lm.ridge() and SPSS
I had no problems running regression models in SPSS and R that yielded the same
results for these data.
The difference you are observing is from fitting different models. In R, you
fitted:
res <- lm(DEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA, data=dat)
summary(res)
The interaction term is the product of ZMEAN_PA and ZDIVERSITY_PA. This is not
a standardized variable itself and not the same as "ZINTER_PA_C" in the png you
showed, which is not a variable in the dataset, but can be created with:
dat$ZINTER_PA_C <- with(dat, scale(ZMEAN_PA * ZDIVERSITY_PA))
If you want the same results as in SPSS, then you need to fit:
res <- lm(DEPRESSION ~ ZMEAN_PA + ZDIVERSITY_PA + ZINTER_PA_C, data=dat)
summary(res)
This yields:
Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept)6.410410.01722 372.21 <2e-16 ***
ZMEAN_PA -1.627260.04200 -38.74 <2e-16 ***
ZDIVERSITY_PA -1.500820.07447 -20.15 <2e-16 ***
ZINTER_PA_C -0.589550.05288 -11.15 <2e-16 ***
---
Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
Exactly the same as in the png.
Peter already mentioned this as a possible reason for the discrepancy:
https://stat.ethz.ch/pipermail/r-devel/2017-May/074191.html ("Is it perhaps the
case that x1 and x2 have already been scaled to have standard deviation 1? In
that case, x1*x2 won't be.")
Best,
Wolfgang
-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Nick Brown
Sent: Friday, May 05, 2017 10:40
To: peter dalgaard
Cc: r-devel@r-project.org
Subject: Re: [Rd] lm() gives different results to lm.ridge() and SPSS
Hi,
Here is (I hope) all the relevant output from R.
> mean(s1$ZDEPRESSION, na.rm=T) [1] -1.041546e-16 > mean(s1$ZDIVERSITY_PA,
> na.rm=T) [1] -9.660583e-16 > mean(s1$ZMEAN_PA, na.rm=T) [1] -5.430282e-15 >
> lm.ridge(ZDEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA, data=s1)$coef ZMEAN_PA
>ZDIVERSITY_PA ZMEAN_PA:ZDIVERSITY_PA
-0.3962254 -0.3636026 -0.1425772 ##
This is what I thought was the problem originally. :-)
> coefficients(lm(ZDEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA, data=s1)) (Intercept)
> ZMEAN_PA ZDIVERSITY_PA ZMEAN_PA:ZDIVERSITY_PA
0.07342198-0.39650356-0.36569488
-0.09435788 > coefficients(lm.ridge(ZDEPRESSION ~ ZMEAN_PA * ZDIVERSITY_PA,
data=s1)) ZMEAN_PA ZDIVERSITY_PA ZMEAN_PA:ZDIVERSITY_PA
0.07342198-0.39650356-0.36569488
-0.09435788 The equivalent from SPSS is attached. The unstandardized
coefficients in SPSS look nothing like those in R. The standardized
coefficients in SPSS match the lm.ridge()$coef numbers very closely indeed,
suggesting that the same algorithm may be in use.
I have put the dataset file, which is the untouched original I received from
the authors, in this Dropbox folder:
https://www.dropbox.com/sh/xsebjy55ius1ysb/AADwYUyV1bl6-iAw7ACuF1_La?dl=0. You
can read it into R with this code (one variable needs to be standardized and
centered; everything else is already in the file):
s1 <- read.csv("Emodiversity_Study1.csv", stringsAsFactors=FALSE)
s1$ZDEPRESSION <- scale(s1$DEPRESSION)
Hey, maybe R is fine and I've stumbled on a bug in SPSS? If so, I'm sure IBM
will want to fix it quickly (ha ha ha).
Nick
- Original Message -
From: "peter dalgaard"
To: "Nick Brown"
Cc: "Simon Bonner" , r-devel@r-project.org
Sent: Friday, 5 May, 2017 10:02:10 AM
Subject: Re: [Rd] lm() gives different results to lm.ridge() and SPSS
I asked you before, but in case you missed it: Are you looking at the right
place in SPSS output?
The UNstandardized coefficients should be comparable to R, i.e. the "B" column,
not "Beta".
-pd
> On 5 May 2017, at 01:58 , Nick Brown wrote:
>
> Hi Simon,
>
> Yes, if I uses coefficients() I get the same results for lm() and lm.ridge().
> So that's consistent, at least.
>
> Interestingly, the "wrong" number I get from lm.ridge()$coef agrees with the
> value from SPSS to 5dp, which is an interesting coincidence if these numbers
> have no particular external meaning in lm.ridge().
>
> Kind regards,
> Nick
>
> - Original Message -
>
> From: "Simon Bonner"
> To: "Nick Brown" , r-devel@r-project.org
> Sent: Thursday, 4 May, 2017 7:07:33 PM
> Subject: RE: [Rd] lm() gives different results to lm.ridge() and SPSS
>
> Hi Nick,
>
> I think that the problem here is your use of $coef to extract the
> coefficients of the ridge regression. The help for lm.ridge states that coef
> is a "matrix of coefficients, one row for each value of lambda. Note that
> these are not on the original scale and are for use by the coef method."
>
> I ran a small test with simulated data, code is copied below, and
[Rd] help(clusterApply) (parallel package)
Hello,
In help(clusterApply) of the 'parallel' package, it says:
"clusterApply calls fun on the first node with arguments seq[[1]] and ..., on
the second node with seq[[2]] and ..., and so on, recycling nodes as needed."
But the argument that is iterated over in clusterApply() is called 'x' not
'seq', so shouldn't it read x[[1]], x[[2]], and so on?
Also, 'x' doesn't have to be a vector ("x - a vector for clusterApply and
clusterApplyLB, a matrix for parRapply and parCapply."), it just needs to be an
object for which x[[1]], x[[2]], ... works (e.g., a data frame works just fine).
"clusterApplyLB is a load balancing version of clusterApply. If the length p of
seq is not greater than the number of nodes n, then a job is sent to p nodes."
Again, shouldn't that say "If the length p of x"?
And finally, "For clusterApply and clusterApplyLB, a list the same length as
seq." Again, 'x' instead of 'seq'?
Best,
Wolfgang
--
Wolfgang Viechtbauer, Ph.D., Statistician | Department of Psychiatry and
Neuropsychology | Maastricht University | P.O. Box 616 (VIJV1) | 6200 MD
Maastricht, The Netherlands | +31 (43) 388-4170 | http://www.wvbauer.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
