similar to: WRE about R_strtod

The build system rolled up R-4.4.1.tar.gz (codename "Race for Your Life") this morning. =============================================================================== This release is dedicated to the memory of Friedrich (Fritz) Leisch, 1968-2024. =============================================================================== This is a minor update, with a few bug fixes. The list

The build system rolled up R-4.4.1.tar.gz (codename "Race for Your Life") this morning. =============================================================================== This release is dedicated to the memory of Friedrich (Fritz) Leisch, 1968-2024. =============================================================================== This is a minor update, with a few bug fixes. The list

The build system rolled up R-4.4.1.tar.gz (codename "Race for Your Life") this morning. =============================================================================== This release is dedicated to the memory of Friedrich (Fritz) Leisch, 1968-2024. =============================================================================== This is a minor update, with a few bug fixes. The list

Hi all, I've noticed some peculiarities in the tools:::funAPI output that complicate its programmatic use a bit. - Is it for remapped symbol names (with Rf_ or the Fortran underscore), or for unmapped names (without Rf_ or the underscore)? I see that the functions marked in WRE are almost all (except Rf_installChar and Rf_installTrChar) unmapped. This makes a lot of sense because some

Hi Ivan Can you please clarify what input files should be used with your proposed function? I tried a few files in r-svn/src/include and one of them gave me an error. > getdecl("~/R/r-svn/src/include/R.h") [1] "R_FlushConsole" "R_ProcessEvents" "R_WaitEvent" > getdecl("~/R/r-svn/src/include/Rdefines.h") Error in regmatches(lines,

Hi all, I have noticed incorrect parsing of very small hexadecimal numbers like "0x1.00000000d0000p-987". Such a hexadecimal representation can can be produced by sprintf() using the %a flag. The return value is incorrectly reported as 0 when coercing these numbers to double using as.double()/as.numeric(), as illustrated in the three examples below:

[ Email repost 3 of 3 ] From: Dirk Eddelbuettel <edd at debian.org> To: R-devel org <r-devel at r-project.org> Subject: [Patch] Minor glitch in 'Writing R Extensions' Date: Mon, 3 Sep 2012 10:58:32 -0500 The (marked up in info mode) manual Writing R Extensions says in 6.1.3 -- Function: double fprec (double X, double DIGITS) Returns the value of X

Hi, We sometimes see offers to contribute, asking what needs to be done. If they know C, how about the 111 FIXMEs? But which ones would be most useful to fix? Which are difficult and which are easy? Does R-core have a process to list and prioritise the FIXMEs? ~/R/Rtrunk/src/main$ grep "[^/]FIXME" * | wc -l 111 ~/R/Rtrunk/src/main$ grep -A 1 "[^/]FIXME" * arithmetic.c:/*

>>>>> Florent Angly <florent.angly at gmail.com> >>>>> on Tue, 20 Dec 2016 13:26:36 +0100 writes: > Hi all, > I have noticed incorrect parsing of very small hexadecimal numbers > like "0x1.00000000d0000p-987". Such a hexadecimal representation can > can be produced by sprintf() using the %a flag. The return value is

Hum... This boils down to > as.numeric("1.23e") [1] 1.23 > as.numeric("1.23e-") [1] 1.23 > as.numeric("1.23e+") [1] 1.23 which in turn comes from this code in src/main/util.c (function R_strtod) if (*p == 'e' || *p == 'E') { int expsign = 1; switch(*++p) { case '-': expsign = -1; case

Under windows, R supports IEEE floating point arithmetic, but doesn't allow conversion of Inf and NaN from character to numeric. R> is.nan(NaN) [1] TRUE R> as.numeric(as.character(NaN)) [1] NA Warning message: NAs introduced by coercion R> is.infinite(Inf) [1] TRUE R> as.numeric(as.character(Inf)) [1] NA Warning message: NAs introduced by coercion whereas under Linux R>

On Thu, Apr 25, 2024 at 4:24?AM Ivan Krylov via R-devel <r-devel at r-project.org> wrote: > > On Wed, 24 Apr 2024 15:31:39 -0500 (CDT) > luke-tierney--- via R-devel <r-devel at r-project.org> wrote: > > > We would be better off (in my view, not necessarily shared by others > > in R-core) if we could get to a point where: > > > > all entry points

If a package has importClassesFrom(P, C) in its NAMESPACE, then should it _also_ have importClassesFrom(P, <superclasses of C exported from P>) importClassesFrom(Q, <superclasses of C exported from Q>) ## and so on ... ? I think that WRE could be more clear on this point, and in any case I _think_ that the answer is yes. Notably, I think that this rule would

Dear R-developers, I came to a somewhat unexpected behaviour of read.csv() which is trivial but worthwhile to note -- my data involves a protein named "1433E" but to save space I drop the quote so it becomes, Gene,SNP,prot,log10p YWHAE,13:62129097_C_T,1433E,7.35 YWHAE,4:72617557_T_TA,1433E,7.73 Both read.cv() and readr::read_csv() consider prot(ein) name as (possibly confused by

I am trying to build R with 64bit support so I can access more than 2GB of memory on an IBM running AIX. (IBM NightHawk II RS/6000 node with 16 64-bit, 375-MHz POWER3 CPUs and 32 GB of memory, if you want specifics) The 32bit install required little tweaking, but the 64 bit is sufficiently complicated that I thought I would report my findings here and ask for help with the latest (and hopefully

Hi, Thanks for all the great work on compiz, you guys have been great, the shade function works wonderfuly. There's a minor, or not so minor, thing I noticed, if I try to shade an application which minimizes to systray, it shades until it leaves a titlebar-sized artifact on the screen, then I can only activate it again after clicking the notification area icon again. Best regards, Diogo

Recently had passthrough of 2xPCI DVB-T cards and 1xPCIe DVB-S2 card working, the last know config that was *certainly* working was dom0 xen-4.1.1-3.fc16.x86_64 kernel-3.1.0-0.rc7.git0.0.fc16.x86_64 domU kernel-3.1.0-0.rc8.git0.0.fc16.x86_64 Since then I''ve updated xen-4.1.1-6.fc16.x86_64 on dom0 kernel-3.1.0-0.rc9.git0.0.fc16.x86_64 on dom0 and domU and updated all other packages

<<insert bug report here>> ------------------------------------------------------ Error: R : Copyright 2002, The R Development Core Team Version 1.5.1 (2002-06-17) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type `license()' or `licence()' for distribution details. R is a collaborative project with