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 > 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
Re: [Rd] Undocumented functions
Nicola Sturaro Sommacal 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 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 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 /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 reg
[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