Re: [Rd] bug in sum() on integer vector
On Dec 15, 2011, at 02:51 , Hervé Pagès wrote:
Hi Peter,
On 11-12-14 08:19 AM, peter dalgaard wrote:
On Dec 14, 2011, at 16:19 , John C Nash wrote:
Following this thread, I wondered why nobody tried cumsum to see where the
integer
overflow occurs. On the shorter xx vector in the little script below I get
a message:
Warning message:
Integer overflow in 'cumsum'; use 'cumsum(as.numeric(.))'
But sum() does not give such a warning, which I believe is the point of
contention. Since
cumsum() does manage to give such a warning, and show where the overflow
occurs, should
sum() not be able to do so? For the record, I don't class the non-zero
answer as an error
in itself. I regard the failure to warn as the issue.
It (sum) does warn if you take the two halves separately. The issue is
that the overflow is detected at the end of the summation, when the result
is to be saved to an integer (which of course happens for all intermediate
sums in cumsum)
x- c(rep(180003L, 1000), -rep(120002L, 1500))
sum(x[1:1000])
[1] NA
Warning message:
In sum(x[1:1e+07]) : Integer overflow - use sum(as.numeric(.))
sum(x[1001:2500])
[1] NA
Warning message:
In sum(x[1001:1.5e+07]) : Integer overflow - use sum(as.numeric(.))
sum(x)
[1] 4996000
There's a pretty easy fix, essentially to move
if(s INT_MAX || s R_INT_MIN){
warningcall(call, _(Integer overflow - use sum(as.numeric(.;
*value = NA_INTEGER;
}
inside the summation loop. Obviously, there's a speed penalty from two FP
comparisons per element, but I wouldn't know whether it matters in practice
for anyone.
Since you want to generate this warning once only, your test (now
inside the loop) needs to be something like:
if (warn (s INT_MAX || s R_INT_MIN)) {
generate the warning
warn = 0;
}
with 'warn' initialized to 1. This makes the isum() function almost
twice slower on my machine (64-bit Ubuntu) when compiling with
gcc -O2 and when no overflow occurs (the most common use case I guess).
Why not just do the sum in a long double instead of a double?
It slows down isum() by only 8% on my machine when compiling
with gcc -O2.
But most importantly this solution also has the advantage of making
sum(x) consistent with sum(as.double(x)). The latter uses rsum() which
does the sum in a long double. So by using a long double in both isum()
and rsum(), consistency between sum(x) and sum(as.double(x)) is
guaranteed.
Hum, yes. Also the test would be overly cautious: The real thing to test is
whether we overrun the range in which integers are exactly representable in FP
i.e. roughly +/-2^52, not the +/-2^31 that fits 32 bit integers. Or +/-2^63 if
we have long doubles.
However, we still need to decide whether the issue is that sum(as.double(x))
can be inconsistent with sum(x), or whether it is that integer arithmetic can
be inexact. Also, the timings should really be viewed in context: Does _any_
actual code use isum to an extent where halving its speed would have any
noticeable impact?
We probably shouldn't touch this for 2.14.1, then.
Maybe that still doesn't give you the guarantee that sum(x) will always
return the correct value (when it does not return NA) because that
depends now on the ability of long double to represent exactly the sum
of at most INT_MAX arbitrary ints. The nb of bits used for long double
seems to vary a lot across platforms/compilers so it's hard to tell.
Not an ideal solution, but at least it makes isum() more accurate than
the current isum() and it makes sum(x) consistent with sum(as.double(x))
on all platforms, without degrading performance too much.
Cheers,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
--
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Undocumented functions
Hi! I am building a package. This package will not submitted to CRAN. I write the help files for the most important functions of my package, I cannot write it for all functions. This may sounds strange, but so there! I know that all user-level functions should be documented, so I have to move my undocumented functions to a non-user-level. It's right? To move my functions to a non-user-level I can write them as hidden functions, with a dot before the names. This require a very long check of my code to change the call to the function preceding it by a dot. So, this is not a real choice. There are other way to reach my purpose? Thank you very much for help. Sincerely, Nicola [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in sum() on integer vector
peter dalgaard pda...@gmail.com
on Thu, 15 Dec 2011 11:40:23 +0100 writes:
On Dec 15, 2011, at 02:51 , Hervé Pagès wrote:
Hi Peter,
On 11-12-14 08:19 AM, peter dalgaard wrote:
On Dec 14, 2011, at 16:19 , John C Nash wrote:
Following this thread, I wondered why nobody tried
cumsum to see where the integer overflow occurs. On the
shorter xx vector in the little script below I get a
message:
Warning message: Integer overflow in 'cumsum'; use
'cumsum(as.numeric(.))'
But sum() does not give such a warning, which I believe
is the point of contention. Since cumsum() does manage
to give such a warning, and show where the overflow
occurs, should sum() not be able to do so? For the
record, I don't class the non-zero answer as an error
in itself. I regard the failure to warn as the issue.
It (sum) does warn if you take the two halves
separately. The issue is that the overflow is detected
at the end of the summation, when the result is to be
saved to an integer (which of course happens for all
intermediate sums in cumsum)
x- c(rep(180003L, 1000), -rep(120002L,
1500)) sum(x[1:1000])
[1] NA Warning message: In sum(x[1:1e+07]) : Integer
overflow - use sum(as.numeric(.))
sum(x[1001:2500])
[1] NA Warning message: In sum(x[1001:1.5e+07]) :
Integer overflow - use sum(as.numeric(.))
sum(x)
[1] 4996000
There's a pretty easy fix, essentially to move
if(s INT_MAX || s R_INT_MIN){ warningcall(call,
_(Integer overflow - use sum(as.numeric(.; *value
= NA_INTEGER; }
inside the summation loop. Obviously, there's a speed
penalty from two FP comparisons per element, but I
wouldn't know whether it matters in practice for anyone.
Since you want to generate this warning once only, your
test (now inside the loop) needs to be something like:
if (warn (s INT_MAX || s R_INT_MIN)) { generate
the warning warn = 0; }
with 'warn' initialized to 1. This makes the isum()
function almost twice slower on my machine (64-bit
Ubuntu) when compiling with gcc -O2 and when no overflow
occurs (the most common use case I guess).
Why not just do the sum in a long double instead of a
double? It slows down isum() by only 8% on my machine
when compiling with gcc -O2. But most importantly this
solution also has the advantage of making sum(x)
consistent with sum(as.double(x)). The latter uses rsum()
which does the sum in a long double. So by using a long
double in both isum() and rsum(), consistency between
sum(x) and sum(as.double(x)) is guaranteed.
Hum, yes. Also the test would be overly cautious: The real
thing to test is whether we overrun the range in which
integers are exactly representable in FP i.e. roughly
+/-2^52, not the +/-2^31 that fits 32 bit integers. Or
+/-2^63 if we have long doubles.
However, we still need to decide whether the issue is that
sum(as.double(x)) can be inconsistent with sum(x), or
whether it is that integer arithmetic can be
inexact. Also, the timings should really be viewed in
context: Does _any_ actual code use isum to an extent
where halving its speed would have any noticeable impact?
We probably shouldn't touch this for 2.14.1, then.
Definitely agree on that.
Given all the (good) considerations in this thread,
I think that Hervé's proposal of just *not* calling isum()
but rather rsum() really makes more sense:
- Not only will it give the correct (finite) answer in more cases,
- but it will be much easier to document what sum(.) does:
sum(x) and sum(as.double(x)) will return the same values.
- it is faster than the isum() version which would check for
overflow every time.
We could think of coercing back to integer when the result is
inside the integer range and also when NA: returning
integer instead of real NA.
Martin
Maybe that still doesn't give you the guarantee that
sum(x) will always return the correct value (when it does
not return NA) because that depends now on the ability of
long double to represent exactly the sum of at most
INT_MAX arbitrary ints. The nb of bits used for long
double seems to vary a lot across platforms/compilers so
it's hard to tell. Not an ideal solution, but at least
it makes isum() more accurate than the current isum() and
it makes sum(x) consistent with sum(as.double(x)) on all
platforms, without degrading performance too much.
Cheers, H.
--
Hervé Pagès
Program in Computational Biology Division of Public
Health Sciences Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA
Re: [Rd] Undocumented functions
Nicola Sturaro Sommacal mailinglist at nicolasturaro.com writes: Hi! I am building a package. This package will not submitted to CRAN. I write the help files for the most important functions of my package, I cannot write it for all functions. This may sounds strange, but so there! I know that all user-level functions should be documented, so I have to move my undocumented functions to a non-user-level. It's right? To move my functions to a non-user-level I can write them as hidden functions, with a dot before the names. This require a very long check of my code to change the call to the function preceding it by a dot. So, this is not a real choice. There are other way to reach my purpose? Read about name spaces; search for NAMESPACE or name space in the R extensions manual. Any function that is not exported from a package need not be documented. Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Undocumented functions
Use namespaces and only export the functions at the user level. The rest will be hidden in the namespace and doesn't require a help page. See 'Package Namespaces' in the manual Writing R Extensions. Cheers On Thu, Dec 15, 2011 at 1:01 PM, Nicola Sturaro Sommacal mailingl...@nicolasturaro.com wrote: Hi! I am building a package. This package will not submitted to CRAN. I write the help files for the most important functions of my package, I cannot write it for all functions. This may sounds strange, but so there! I know that all user-level functions should be documented, so I have to move my undocumented functions to a non-user-level. It's right? To move my functions to a non-user-level I can write them as hidden functions, with a dot before the names. This require a very long check of my code to change the call to the function preceding it by a dot. So, this is not a real choice. There are other way to reach my purpose? Thank you very much for help. Sincerely, Nicola [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Undocumented functions
Why not use package.skeleton() to construct empty help files? But if you're determined to change the function names instead, grep and sed are very useful tools for that sort of thing. (The OS versions, not the R grep()). Sarah On Thu, Dec 15, 2011 at 7:01 AM, Nicola Sturaro Sommacal mailingl...@nicolasturaro.com wrote: Hi! I am building a package. This package will not submitted to CRAN. I write the help files for the most important functions of my package, I cannot write it for all functions. This may sounds strange, but so there! I know that all user-level functions should be documented, so I have to move my undocumented functions to a non-user-level. It's right? To move my functions to a non-user-level I can write them as hidden functions, with a dot before the names. This require a very long check of my code to change the call to the function preceding it by a dot. So, this is not a real choice. There are other way to reach my purpose? Thank you very much for help. Sincerely, Nicola -- Sarah Goslee http://www.functionaldiversity.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problems with iconv
I put the header in the R home/include. Was that right? Probably not. I would expect something like /usr/local/include, and maybe a -I option to make sure it was found before the Solaris-supplied one. Does make install (for iconv) not do that for you? Wow! Thanks! That was it! I checked out /usr/local/include and the header was there, but I'd uncommented a line in the config.site that caused it NOT to look at /usr/local/include. Re-commenting the line fixed that problem. But now, Rsched will not compile from the rhome, though it does from the rhome/src/unix directory. So, it's like an onion. You take a layer off and cry - then repeat. But, I'll make it. Thanks again for your help! Roger -- View this message in context: http://r.789695.n4.nabble.com/problems-with-iconv-tp4191177p4200071.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DESCRIPTION Suggests entry help
How should the Suggests entry be written in this case?
Have package that supports parallel processing available
for multiple R versions. Original package DESCRIPTION
Suggests entry only listed 'multicore' and life was good.
Since R-2.14+ includes 'parallel' package, thought I could
reference that on the Suggests entry too. But not so fast.
As it doesn't exist for previous versions of R, how can I
add this such that multiple R versions are supported? All
older version R CMD checks fail attempting to load 'parallel';
current R CMD checks complain if I leave it out of DESCRIPTION
but require('parallel') within source itself.
And although I'm pretty sure this isn't available, any syntax
to imply 'either this or that' package? Or 'this package with
R version'?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DESCRIPTION Suggests entry help
If it is only in the Suggests and you test for its existence before its
usage, it should be OK.
For old R versions my CRAN checks set the nvironment variable:
_R_CHECK_FORCE_SUGGESTS_=FALSE
Best,
Uwe Ligges
On 15.12.2011 19:53, Roebuck,Paul L wrote:
How should the Suggests entry be written in this case?
Have package that supports parallel processing available
for multiple R versions. Original package DESCRIPTION
Suggests entry only listed 'multicore' and life was good.
Since R-2.14+ includes 'parallel' package, thought I could
reference that on the Suggests entry too. But not so fast.
As it doesn't exist for previous versions of R, how can I
add this such that multiple R versions are supported? All
older version R CMD checks fail attempting to load 'parallel';
current R CMD checks complain if I leave it out of DESCRIPTION
but require('parallel') within source itself.
And although I'm pretty sure this isn't available, any syntax
to imply 'either this or that' package? Or 'this package with
R version'?
__
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] error starting R-devel with --arch ppc -- an unusual circumstance has arisen
When I try and start R-devel as follows: R --vanilla --arch ppc I see this, over and over again, ^C does not interrupt it and I have to close the terminal window: Error in paste0(prefix, conditionMessage(e), \n) : not a BUILTIN function In addition: Warning message: An unusual circumstance has arisen in the nesting of readline input. Please report using bug.report() Error in paste0(prefix, conditionMessage(e), \n) : not a BUILTIN function In addition: Warning message: An unusual circumstance has arisen in the nesting of readline input. Please report using bug.report() I can't get to sessionInfo() but here is sessionInfo() of the same R invoked with no --arch argument: R Under development (unstable) (2011-12-14 r57899) Platform: i386-apple-darwin9.8.0/i386 (32-bit) locale: [1] C attached base packages: [1] stats graphics grDevices utils datasets methods base This seems to be related to the issue I reported here previously: https://stat.ethz.ch/pipermail/r-devel/2011-December/062793.html Thanks, Dan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in sum() on integer vector
Hi Duncan,
On 11-12-14 03:57 AM, Duncan Murdoch wrote:
On 11-12-13 6:41 PM, Hervé Pagès wrote:
Hi Duncan,
On 11-12-10 05:27 AM, Duncan Murdoch wrote:
On 11-12-09 4:41 PM, Hervé Pagès wrote:
Hi Duncan,
On 11-12-09 11:39 AM, Duncan Murdoch wrote:
On 09/12/2011 1:40 PM, Hervé Pagès wrote:
Hi,
x- c(rep(180003L, 1000), -rep(120002L, 1500))
This is correct:
sum(as.double(x))
[1] 0
This is not:
sum(x)
[1] 4996000
Returning NA (with a warning) would also be acceptable for the
latter.
That would make it consistent with cumsum(x):
cumsum(x)[length(x)]
[1] NA
Warning message:
Integer overflow in 'cumsum'; use 'cumsum(as.numeric(.))'
This is a 64 bit problem; in 32 bits things work out properly.
I'd guess
in 64 bit arithmetic we or the run-time are doing something to
simulate
32 bit arithmetic (since integers are 32 bits), but it looks as though
we're not quite getting it right.
It doesn't work properly for me on Leopard (32-bit mode):
x- c(rep(180003L, 1000), -rep(120002L, 1500))
sum(as.double(x))
[1] 0
sum(x)
[1] 4996000
sessionInfo()
R version 2.14.0 RC (2011-10-27 r57452)
Platform: i386-apple-darwin9.8.0/i386 (32-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
It looks like the problem is that isum() (in src/main/summary.c)
uses a 'double' internally to do the sum, whereas rsum() and csum()
use a 'long double'.
A double has 53 bits to store the mantissa, so any 32 bit integer can be
stored exactly.
Note that isum() seems to be assuming that NA_INTEGER and NA_LOGICAL
will always be the same (probably fine) and that TRUE values in the
input vector are always represented as a 1 (not so sure about this
one).
A more fundamental question: is switching back and forth between
'int' and 'double' (or 'long double') the right thing to do for doing
safe arithmetic on integers?
If you have enough terms in the sum that an intermediate value exceeds
53 bits in length, then you'll get the wrong answer, because the
intermediate sum can't be stored exactly. That happens in your example.
On the 32 bit platform I tested (Windows 32 bit), intermediate values
are stored in registers with 64 bit precision, which is probably why
Windows 32 bit gets it right, but various other platforms don't.
On your fundamental question: I think the answer is that R is doing the
right thing. R doesn't think of an integer as a particular
representation, it thinks of it as a number. So if you ask for the sum
of those numbers, R should return its best approximation to that sum,
and it does.
It does, really? Seems like returning 0 would be a better approximation
;-) And with the argument that R doesn't think of an integer as a
particular representation then there is no reason why sum(x)
would get it wrong and sum(as.double(x)) would get it right. Also why
bother having an integer type in R?
Seriously, I completely disagree with your view (hopefully it's only
yours, and not an R feature) that it's ok for integer arithmetic to
return an approximation. It should always return the correct value or
fail.
I think you need to be more specific in your design, because the function
`+` - function(x,y) stop(fail)
Interesting. At least this program is *correct*, strictly speaking.
Which doesn't mean that it is useful. This one too is correct:
`+` - function(x,y) {
warning(cannot sum 'x' and 'y' - returning NA)
NA
}
But this one is *not* correct:
`+` - function(x,y) {set.seed(4); return(some_random_number())}
because sometimes it returns the wrong answer ;-) (which is more or
less what sum() does on an integer vector at the moment).
meets your specs. I think the following requirements are all desirable,
but I don't think they can all be met at the same time:
1. Return the exactly correct answer in all (or even nearly all) of the
cases where the current code returns the correct answer.
2. Do it as quickly (or nearly as quickly) as the current code.
3. Do it without requiring much more memory than the current code does.
4. Never return an incorrect answer.
If you think I'm wrong, show me.
I agree that you can't have it all but IMO correctness should have a
higher priority than speed or memory usage considerations. Quoting
my previous boss (someone you know): There are many fast and memory
efficient ways to compute the wrong result. Just before people in
the meeting room were about to start passionate discussions about the
respective merits of those fast, efficient, but unfortunately incorrect
ways.
Cheers,
H.
Duncan Murdoch
This is one of the reasons why programmers use integers and not
floating point numbers (memory usage being another one). Integers are
used for indexing elements in an array or for shifting pointers at the
C-level. The idea that integer arithmetic can be approximate is scary.
Cheers,
H.
A different approach would be to do the sum in 32 bit registers and
[Rd] S4 NAMESPACE method imports and exports do not include (promoted?) generics
In R.version.string [1] R Under development (unstable) (2011-12-15 r57901) section 1.6.6 of 'Writing R Extensions' says Note that exporting methods on a generic in the namespace will also export the generic, and exporting a generic in the namespace will also export its methods. and Note that importMethodsFrom will also import any generics defined in the namespace on those methods However, if PkgA promotes 'unique' to a generic and exports that DESCRIPTION: Imports: methods R/f.R: setGeneric(unique) NAMESPACE: export(unique) and PkgB creates and exports a method on unique DESCRIPTION Imports: methods, PkgA R/f.R: setClass(B, representation(b=numeric)) setMethod(unique, B, function(x, incomparables=FALSE, ...) unique(x@b)) NAMESPACE: importFrom(PkgA, unique) exportClasses(B) exportMethods(unique) and PkgC wants to import PkgB's classes and methods DESCRIPTION Imports: methods, PkgB R/f.R cunique - function(x) unique(x) NAMESPACE importMethodsFrom(PkgB, unique) export(cunique) then (a) the 'unique' generic is not available to the user of PkgB library(PkgB) unique(new(B, b=1:5)) Error in unique.default(new(B, b = 1:5)) : unique() applies only to vectors and (b) the generic has not been imported to PkgC's namespace cunique(new(B, b=1:5)) Error in unique.default(b) : unique() applies only to vectors A workaround is for PkgB to also export(unique), and for PkgC to also importFrom(PkgA, unique), but is this the intention? This is arising from Bioconductor efforts to place commonly promoted functions and S3 classes into a single package, to avoid conflicts when the same function is promoted independently by several packages. Martin -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check fails to warn about undocumented classes and methods
In R.version.string [1] R Under development (unstable) (2011-12-15 r57901) PkgA promotes 'unique' to a generic and exports that DESCRIPTION: Imports: methods R/f.R: setGeneric(unique) NAMESPACE: export(unique) and PkgB creates and exports a method on unique DESCRIPTION Imports: methods, PkgA R/f.R: setClass(B, representation(b=numeric)) setMethod(unique, B, function(x, incomparables=FALSE, ...) unique(x@b)) NAMESPACE: importFrom(PkgA, unique) exportClasses(B) exportMethods(unique) There is a man/ page for each package, but no other documentation. Yet R CMD check PkgA_1.0.tar.gz says * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK and for Pkg B we only get * checking for missing documentation entries ... WARNING Undocumented code objects: ‘bunique’ All user-level objects in a package should have documentation entries. See the chapter 'Writing R documentation files' in the 'Writing R Extensions' manual. * checking for code/documentation mismatches ... OK Martin -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check fails to warn about undocumented classes and methods
On 12/15/2011 03:40 PM, Martin Morgan wrote: In R.version.string [1] R Under development (unstable) (2011-12-15 r57901) PkgA promotes 'unique' to a generic and exports that DESCRIPTION: Imports: methods R/f.R: setGeneric(unique) NAMESPACE: export(unique) and PkgB creates and exports a method on unique DESCRIPTION Imports: methods, PkgA R/f.R: setClass(B, representation(b=numeric)) setMethod(unique, B, function(x, incomparables=FALSE, ...) unique(x@b)) this also has bunique - function(b) unique(b) NAMESPACE: importFrom(PkgA, unique) exportClasses(B) exportMethods(unique) and export(bunique) There is a man/ page for each package, but no other documentation. Yet R CMD check PkgA_1.0.tar.gz says * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK and for Pkg B we only get * checking for missing documentation entries ... WARNING Undocumented code objects: ‘bunique’ All user-level objects in a package should have documentation entries. See the chapter 'Writing R documentation files' in the 'Writing R Extensions' manual. * checking for code/documentation mismatches ... OK Martin -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error starting R-devel with --arch ppc -- an unusual circumstance has arisen
Dan, I don't know why, but something is off in the recent R-devel build for ppc. The result is that the installed binary ppc is older than the other ones, so it doesn't have paste0 while the others do. The really strange thing is that the build logs show success, but the build directory is old and the resulting tar ball is not updated. I'll keep you posted. Cheers, Simon On Dec 15, 2011, at 4:56 PM, Dan Tenenbaum wrote: When I try and start R-devel as follows: R --vanilla --arch ppc I see this, over and over again, ^C does not interrupt it and I have to close the terminal window: Error in paste0(prefix, conditionMessage(e), \n) : not a BUILTIN function In addition: Warning message: An unusual circumstance has arisen in the nesting of readline input. Please report using bug.report() Error in paste0(prefix, conditionMessage(e), \n) : not a BUILTIN function In addition: Warning message: An unusual circumstance has arisen in the nesting of readline input. Please report using bug.report() I can't get to sessionInfo() but here is sessionInfo() of the same R invoked with no --arch argument: R Under development (unstable) (2011-12-14 r57899) Platform: i386-apple-darwin9.8.0/i386 (32-bit) locale: [1] C attached base packages: [1] stats graphics grDevices utils datasets methods base This seems to be related to the issue I reported here previously: https://stat.ethz.ch/pipermail/r-devel/2011-December/062793.html Thanks, Dan __ 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
