[Rd] R_CheckUserInterrupt() can be a performance bottleneck within GUIs

d possibly change) the position of R_CheckUserInterrupt() in some base R functions. For example, moving R_CheckUserInterrupt() from cwilcox() to pwilcox() and qwilcox() in src/nmath/wilcox.c may lead to a significant improvement (while still being feasible in terms of response time). Best,

Re: [Rd] False positives in check for lost braces (in tools::checkRd())

Thank you very much, so I don't have to wait for the release of the new version of Rdpack on CRAN before submitting. Best regards, Martin -- apl. Prof. Dr. Martin Becker, Akad. Oberrat Lehrstab Statistik Quantitative Methoden Fakultät für Empirische Humanwissenschaften und Wirtschaftswiss

Re: [Rd] False positives in check for lost braces (in tools::checkRd())

Am 07.11.23 um 23:00 schrieb Ivan Krylov: On Tue, 7 Nov 2023 17:13:05 +0100 Martin Becker wrote: More specifically, a 'Lost braces' NOTE is issued (at least sometimes) when using the \insertRef{...}{...} command from the Rdpack package. Does anything change if you use the d

[Rd] False positives in check for lost braces (in tools::checkRd())

reproducible example. Best regards and many thanks, Martin -- apl. Prof. Dr. Martin Becker, Akad. Oberrat Lehrstab Statistik Quantitative Methoden Fakultät für Empirische Humanwissenschaften und Wirtschaftswissenschaft Universität des Saarlandes Campus C3 1, Raum 2.17 66123 Saa

Re: [Rd] feature request: optim() iteration of functions that return multiple values

For a solution that does not require any change to the original function being optimized, the following one-liner could be used, which converts existing functions to functions that return only the first element: returnFirst <- function(fun) function(...) do.call(fun,list(...))[[1]] Example: f

[Rd] Minor bug: plot.table and Axis.table (partially) ignore graphical parameters (patch included)

ove the minor bug and simplify the code. As a downside, the change breaks code which uses 'axes' as '...'-argument in a call to Axis.table(). But, as already mentioned, this is neither documented nor working for other methods of Axis. So, please consider applying t

Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code

ne. That is the way return() is intended to work. Best, luke On Wed, 16 Feb 2011, Duncan Murdoch wrote: On 11-02-16 7:31 AM, Martin Becker wrote: On 15.02.2011 22:48, David Scott wrote: On 16/02/2011 7:04 a.m., Paul Johnson wrote: ... 4. We don't want gratuitous use of "return&qu

Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code

tain situations. Martin -- Dr. Martin Becker Statistics and Econometrics Saarland University Campus C3 1, Room 217 66123 Saarbruecken Germany __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] hist.default()$density

lt;- 0.5 * (breaks[-1L] + breaks[-nB]) r <- structure(list(breaks = breaks, counts = counts, intensities = dens, Martin Becker wrote: Dear developers, the current implementation of hist.default() calculates 'density' (and 'intensities') as dens <- counts/(n*

[Rd] hist.default()$density

t from 1 in many cases, see e.g. > print(sum(tmp$density*diff(tmp$breaks)),digits=15) [1] 0.9996008 Is this intended, or should the calculation of dens read dens <- counts/(n*diff(breaks)) instead (or should hist.default()$breaks return the fuzzy breaks)? Best wishes Martin -

Re: [Rd] Problem with gsl package

E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr. Martin Becker Statistics and

[Rd] suggestion: tiny documentation improvement for R-admin

recommended', I think it would be favourable to note this already in subsection 3.1.2, where the first 'make' commands pop up. Please find attached a corresponding patch for rev. 51148. Thanks, Martin -- Dr. Martin Becker Statistics and Econometrics Saarland University Campus C

[Rd] tiny typo in translation (src/library/tools/po/R-de.po)

nks, Martin -- Dr. Martin Becker Statistics and Econometrics Saarland University Campus C3 1, Room 206 66123 Saarbruecken Germany Index: src/library/tools/po/R-de.po === --- src/library/tools/po/R-de.po(revision 51109) +++ sr

Re: [Rd] RFC: lchoose() vs lfactorial() etc

Robin Hankin wrote: ... Is this the place to discuss having complex arguments for gamma()? ... If this discussion starts I would second the wish for the functionality of gsl's lngamma_complex in base R. Best wishes Martin -- Dr. Martin Becker Statistics and Econometrics Saarland Unive

Re: [Rd] Strange code in `?`

puzzled by this part: cat("Contacting Delphi...") flush.console() Sys.sleep(2 + rpois(1, 2)) cat("the oracle is unavailable.\nWe apologize for any inconvenience.\n") We now got jokes in R code? Why not? ;-) Best, Philippe -- Dr. Martin Becker Statistics and Econometrics Saarl

Re: [Rd] Sweave output encoding in R-2.10.0beta on Windows (Rgui <-> Rterm)

Rgui and Rterm in R-2.10.0rc). It would be great if someone more involved in Sweave could take a look at (and maybe commit) the attached (untested!) patch (to r50160). Many thanks in advance! Best wishes, Martin Martin Becker wrote: Dear developers, I have come across a (somewhat strange

Re: [Rd] Sweave output encoding in R-2.10.0beta on Windows (Rgui <-> Rterm)

þ[1] "ä" "ö" "ü" "ß"ÿþ \end{Soutput} \end{Schunk} \end{document} Best wishes, Martin Martin Becker wrote: Dear developers, I have come across a (somewhat strange) change in the encoding of Sweave output from R-2.9.2pat to R-2.10.0beta (apparentl

[Rd] Sweave output encoding in R-2.10.0beta on Windows (Rgui <-> Rterm)

tasets methods base -- Dr. Martin Becker Statistics and Econometrics Saarland University Campus C3 1, Room 206 66123 Saarbruecken Germany \documentclass{article} \usepackage{c:/Programme/R/R-2.10.0beta/share/texmf/Sweave} \usepackage[latin1]{inputenc} %\usepackage[utf8x]{inputenc} \usepackag

[Rd] creating environments in package's C code

Dear developers, is it possible to create environments in C code of packages? Simply using SEXP env; PROTECT (env = allocSExp(ENVSXP)); and assigning the enclosing environment with SET_ENCLOS seems to be insufficient. Best wishes, Martin -- Dr. Martin Becker Statistics and Econometrics

Re: [Rd] Inaccurate complex arithmetic of R (Matlab is accurate)

ne and Gerontology Johns Hopkins University Ph: (410) 502-2619 Fax: (410) 614-9625 Email: rvarad...@jhmi.edu Webpage: http://www.jhsph.edu/agingandhealth/People/Faculty_personal_pages/Varadhan.h tml ----

Re: [Rd] Inaccurate complex arithmetic of R (Matlab is accurate)

19 email: rvarad...@jhmi.edu ______ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr. Martin Becker Statistics and Econometrics Saarland University Campus C3 1, Room 206 66123 Saarbruecken Germany ___

[Rd] how to change FPU control word?

hope, there is already a better solution. Any hints appreciated! Thanks, Martin -- Dr. Martin Becker Statistics and Econometrics Saarland University Campus C3 1, Room 206 66123 Saarbruecken Germany __ R-devel@r-project.org mailing list https

[Rd] Small bug in axis.POSIXct

(copy&paste error?) is easily fixed, see the attached patch (for revision 47031). Best wishes, Martin -- Dr. Martin Becker Statistics and Econometrics Saarland University Campus C3 1, Room 206 66123 Saarbruecken Germany diff -u --recursive trunk.orig/src/library/graphics/R/datetim

Re: [Rd] pnorm

I guess that you destroy the accuracy of the calculation by the subtraction. Try 2*(pnorm(8.104474,lower=FALSE)) instead, which results in 5.29742e-16 for me. Regards, Martin jing hua zhao schrieb: > Dear R list, > > I calculated a two-sided p values according to 2*(1-pnorm(8.104474)), w

Re: [Rd] Strange number produced by dnorm

Hi, I think the only thing that's wrong is "%d" in your printf statement, shouldn't it be "%f"? ("%d" is used for decimal (integer) numbers, "%f" for float (double) numbers) Regards, Martin Tong Wang wrote: > Hi All, > I just started to learn compiling C codes for R usage, and got a pro

[Rd] bug in cut.Date() (PR#9433)

Full_Name: Martin Becker Version: 2.4.1 OS: WinXP/Linux Submission from: (NULL) (134.96.96.42) When using cut.Date() with 'breaks="year"', the month of the breakpoints is properly set to January, but the day of month is not set to 1. This leads to a strange behaviour, see t

[Rd] Possible bug in cut.Date()

Dear list, I suppose that the behaviour of cut.Date() is not as intended for the case ' breaks="year" ' (in R 2.4.1 and previous versions): The corresponding code fragment which defines the first breakpoint in this case reads: if (valid == 4) { start$mon <- 0 inc

Re: [Rd] Speed of runif() on different Operating Systems

Duncan Murdoch schrieb: > > McLeish published algorithms to simulate these directly in a recent > issue of CJS. I don't have the reference handy, but I think it's 2004 > or 2005. > > Duncan Murdoch Thank you for this reference, I think it is the 2002 article "*Highs and lows: Some properties of

Re: [Rd] Speed of runif() on different Operating Systems

Prof Brian Ripley schrieb: >> The standard method for simulating final, minimal and maximal values of >> Brownian Motion relies on a (discrete) n-step random walk approximation, >> where >> n has to be chosen very large (typically n=100 000) to keep the bias induced >> by the approximation "small

Re: [Rd] Speed of runif() on different Operating Systems

ft it out in my initial submission. I apologise, if my submission was off-topic in this mailing list. > If it matters to you, investigate the code your > compiler creates. (The ATLAS developers report very poor performance on > certain Pentiums for certain versions of gcc4.) > >

[Rd] Speed of runif() on different Operating Systems

() instead of Sys.time()-differences yields similar results. Any hint is appreciated, please let me know, if the given information on system/OS or the R output below is not sufficient. Regards, Martin Becker R - Output below Windows XP