Re: [Rd] invert argument in grep
On 11/9/2006 5:14 AM, Romain Francois wrote:
> Hello,
>
> What about an `invert` argument in grep, to return elements that are
> *not* matching a regular expression :
>
> R> grep("pink", colors(), invert = TRUE, value = TRUE)
>
> would essentially return the same as :
>
> R> colors() [ - grep("pink", colors()) ]
>
>
> I'm attaching the files that I modified (against today's tarball) for
> that purpose.
I think a more generally useful change would be to be able to return a
logical vector with TRUE for a match and FALSE for a non-match, so a
simple !grep(...) does the inversion. (This is motivated by the recent
R-help discussion of the fact that x[-selection] doesn't always invert
the selection when it's a vector of indices.)
A way to do that without expanding the argument list would be to allow
value="logical"
as well as value=TRUE and value=FALSE.
This would make boolean operations easy, e.g.
colors()[grep("dark", colors(), value="logical")
& !grep("blue", colors(), value="logical")]
to select the colors that contain "dark" but not "blue". (In this case
the RE to select that subset is rather simple because "dark" always
precedes "blue", but if that wasn't true, it would be a lot messier.)
Duncan Murdoch
>
> Cheers,
>
> Romain
>
>
>
>
>
> grep <-
> function(pattern, x, ignore.case = FALSE, extended = TRUE, perl = FALSE,
> value = FALSE, fixed = FALSE, useBytes = FALSE, invert = FALSE)
> {
> pattern <- as.character(pattern)
> ## when value = TRUE we return names
> if(!is.character(x)) x <- structure(as.character(x), names=names(x))
> ## behaves like == for NA pattern
> if (is.na(pattern)) {
> if(value)
> return(structure(rep.int(as.character(NA), length(x)),
> names = names(x)))
> else
> return(rep.int(NA, length(x)))
> }
>
> if(perl)
> .Internal(grep.perl(pattern, x, ignore.case, value, useBytes, invert))
> else
> .Internal(grep(pattern, x, ignore.case, extended, value, fixed,
>useBytes, invert))
> }
>
> sub <-
> function(pattern, replacement, x, ignore.case = FALSE, extended = TRUE,
> perl = FALSE, fixed = FALSE, useBytes = FALSE)
> {
> pattern <- as.character(pattern)
> replacement <- as.character(replacement)
> if(!is.character(x)) x <- as.character(x)
> if (is.na(pattern))
> return(rep.int(as.character(NA), length(x)))
>
> if(perl)
> .Internal(sub.perl(pattern, replacement, x, ignore.case, useBytes))
> else
> .Internal(sub(pattern, replacement, x, ignore.case,
> extended, fixed, useBytes))
> }
>
> gsub <-
> function(pattern, replacement, x, ignore.case = FALSE, extended = TRUE,
> perl = FALSE, fixed = FALSE, useBytes = FALSE)
> {
> pattern <- as.character(pattern)
> replacement <- as.character(replacement)
> if(!is.character(x)) x <- as.character(x)
> if (is.na(pattern))
> return(rep.int(as.character(NA), length(x)))
>
> if(perl)
> .Internal(gsub.perl(pattern, replacement, x, ignore.case, useBytes))
> else
> .Internal(gsub(pattern, replacement, x, ignore.case,
>extended, fixed, useBytes))
> }
>
> regexpr <-
> function(pattern, text, extended = TRUE, perl = FALSE,
> fixed = FALSE, useBytes = FALSE)
> {
> pattern <- as.character(pattern)
> text <- as.character(text)
> if(perl)
> .Internal(regexpr.perl(pattern, text, useBytes))
> else
> .Internal(regexpr(pattern, text, extended, fixed, useBytes))
> }
>
> gregexpr <-
> function(pattern, text, extended = TRUE, perl = FALSE,
> fixed = FALSE, useBytes = FALSE)
> {
> pattern <- as.character(pattern)
> text <- as.character(text)
> if(perl)
> .Internal(gregexpr.perl(pattern, text, useBytes))
> else
> .Internal(gregexpr(pattern, text, extended, fixed, useBytes))
> }
>
> agrep <-
> function(pattern, x, ignore.case = FALSE, value = FALSE,
> max.distance = 0.1)
> {
> pattern <- as.character(pattern)
> if(!is.character(x)) x <- as.character(x)
> ## behaves like == for NA pattern
> if (is.na(pattern)){
> if (value)
> return(structure(rep.int(as.character(NA), length(x)),
> names = names(x)))
> else
> return(rep.int(NA, length(x)))
> }
>
> if(!is.character(pattern)
>|| (length(pattern) < 1)
>|| ((n <- nchar(pattern)) == 0))
> stop("'pattern' must be a non-empty character string")
>
> if(!is.list(max.distance)) {
> if(!is.numeric(max.distance) || (max.distance < 0))
> stop("'max.distance' must be non-negative")
> if(max.distance < 1)# transform percentages
> max.distance <- ceiling(n * max.dista
Re: [Rd] invert argument in grep
On Fri, 10 Nov 2006, Duncan Murdoch wrote:
> On 11/9/2006 5:14 AM, Romain Francois wrote:
>> Hello,
>>
>> What about an `invert` argument in grep, to return elements that are
>> *not* matching a regular expression :
>>
>> R> grep("pink", colors(), invert = TRUE, value = TRUE)
>>
>> would essentially return the same as :
>>
>> R> colors() [ - grep("pink", colors()) ]
Note that grep("pat", x, value = TRUE) is not the same as x[grep("pat", x)],
as the help page carefully points out. (I think it would be better
if it were.)
>>
>> I'm attaching the files that I modified (against today's tarball) for
>> that purpose.
(BTW, sending whole files makes it difficult to see the changes and even
harder to merge them; please use diffs. From a quick look the changes
were very incomplete, as the internal functions were changed and there
were no changed C files.)
> I think a more generally useful change would be to be able to return a
> logical vector with TRUE for a match and FALSE for a non-match, so a
> simple !grep(...) does the inversion. (This is motivated by the recent
> R-help discussion of the fact that x[-selection] doesn't always invert
> the selection when it's a vector of indices.)
I don't think that is pertinent here, as the indices are always a vector
of positive integers.
> A way to do that without expanding the argument list would be to allow
>
> value="logical"
>
> as well as value=TRUE and value=FALSE.
>
> This would make boolean operations easy, e.g.
>
> colors()[grep("dark", colors(), value="logical")
> & !grep("blue", colors(), value="logical")]
>
> to select the colors that contain "dark" but not "blue". (In this case
> the RE to select that subset is rather simple because "dark" always
> precedes "blue", but if that wasn't true, it would be a lot messier.)
That might be worthwhile, but it is relatively simple to change positive
integer indices to logical ones and v.v.
My personal take is that having 'value=TRUE' was already a complication
not worth having, and implementing it at C level was an efficiency tweak
not worth the maintenance effort (and also means that '[' methods are not
dispatched).
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] invert argument in grep
On 11/10/2006 6:28 AM, Prof Brian Ripley wrote:
> On Fri, 10 Nov 2006, Duncan Murdoch wrote:
>
>> On 11/9/2006 5:14 AM, Romain Francois wrote:
>>> Hello,
>>>
>>> What about an `invert` argument in grep, to return elements that are
>>> *not* matching a regular expression :
>>>
>>> R> grep("pink", colors(), invert = TRUE, value = TRUE)
>>>
>>> would essentially return the same as :
>>>
>>> R> colors() [ - grep("pink", colors()) ]
>
> Note that grep("pat", x, value = TRUE) is not the same as x[grep("pat", x)],
> as the help page carefully points out. (I think it would be better
> if it were.)
>
>>> I'm attaching the files that I modified (against today's tarball) for
>>> that purpose.
>
> (BTW, sending whole files makes it difficult to see the changes and even
> harder to merge them; please use diffs. From a quick look the changes
> were very incomplete, as the internal functions were changed and there
> were no changed C files.)
>
>> I think a more generally useful change would be to be able to return a
>> logical vector with TRUE for a match and FALSE for a non-match, so a
>> simple !grep(...) does the inversion. (This is motivated by the recent
>> R-help discussion of the fact that x[-selection] doesn't always invert
>> the selection when it's a vector of indices.)
>
> I don't think that is pertinent here, as the indices are always a vector
> of positive integers.
The issue is that the vector might be empty, in which case
arithmetically negating it has no effect. Negating a vector of integer
indices is not a good way to invert a selection, while logical negation
of a logical vector is fine.
>
>> A way to do that without expanding the argument list would be to allow
>>
>> value="logical"
>>
>> as well as value=TRUE and value=FALSE.
>>
>> This would make boolean operations easy, e.g.
>>
>> colors()[grep("dark", colors(), value="logical")
>> & !grep("blue", colors(), value="logical")]
>>
>> to select the colors that contain "dark" but not "blue". (In this case
>> the RE to select that subset is rather simple because "dark" always
>> precedes "blue", but if that wasn't true, it would be a lot messier.)
>
> That might be worthwhile, but it is relatively simple to change positive
> integer indices to logical ones and v.v.
>
> My personal take is that having 'value=TRUE' was already a complication
> not worth having, and implementing it at C level was an efficiency tweak
> not worth the maintenance effort (and also means that '[' methods are not
> dispatched).
This makes it sound as though it would be worthwhile to redo the
implementation of value=TRUE as something equivalent to x[grep("pat",
x)] by putting this case into the R code. This would simplify the C
code and make the interface a little less quirky. (I'm not sure how
much code this would break because of the loss of coercion to character.)
The value="logical" implementation could also be done in R, not C.
The advantage of putting it into grep() rather than leaving it for the
user to change later is that grep() has a copy of x in hand, so a user
of grep() will not have to save length(x) to use in the conversion to
logical.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] invert argument in grep
Duncan Murdoch wrote:
> On 11/9/2006 5:14 AM, Romain Francois wrote:
>> Hello,
>>
>> What about an `invert` argument in grep, to return elements that are
>> *not* matching a regular expression :
>>
>> R> grep("pink", colors(), invert = TRUE, value = TRUE)
>>
>> would essentially return the same as :
>>
>> R> colors() [ - grep("pink", colors()) ]
>>
>>
>> I'm attaching the files that I modified (against today's tarball) for
>> that purpose.
>
> I think a more generally useful change would be to be able to return a
> logical vector with TRUE for a match and FALSE for a non-match, so a
> simple !grep(...) does the inversion. (This is motivated by the
> recent R-help discussion of the fact that x[-selection] doesn't always
> invert the selection when it's a vector of indices.)
>
> A way to do that without expanding the argument list would be to allow
>
> value="logical"
>
> as well as value=TRUE and value=FALSE.
>
> This would make boolean operations easy, e.g.
>
> colors()[grep("dark", colors(), value="logical")
> & !grep("blue", colors(), value="logical")]
>
> to select the colors that contain "dark" but not "blue". (In this case
> the RE to select that subset is rather simple because "dark" always
> precedes "blue", but if that wasn't true, it would be a lot messier.)
>
> Duncan Murdoch
Hi,
It sounds like a nice thing to have. I would still prefer to type :
R> grep ( "dark", grep("blue", colors(), value = TRUE, invert=TRUE),
value = TRUE )
What about a way to pass more than one regular expression then be able
to call :
R> grep( c("dark", "blue"), colors(), value = TRUE, invert = c(TRUE, FALSE)
I usually use that kind of shortcuts that are easy to remember.
vgrep <- function(...) grep(..., value = TRUE)
igrep <- function(...) grep(..., invert = TRUE)
ivgrep <- vigrep <- function(...) grep(..., invert = TRUE, value = TRUE)
What about things like the arguments `after` and `before` in unix grep.
That could be used when grepping inside a function :
R> grep("plot\\.", body(plot.default) , value= TRUE)
[1] "localWindow <- function(..., col, bg, pch, cex, lty, lwd)
plot.window(...)"
[2] "plot.new()"
[3] "plot.xy(xy, type, ...)"
when this could be useful (possibly).
R> # grep("plot\\.", plot.default, after = 2, value = TRUE)
R> tmp <- tempfile(); sink(tmp) ; print(body(plot.default)); sink();
system( paste( "grep -A2 plot\\. ", tmp) )
localWindow <- function(..., col, bg, pch, cex, lty, lwd)
plot.window(...)
localTitle <- function(..., col, bg, pch, cex, lty, lwd) title(...)
xlabel <- if (!missing(x))
--
plot.new()
localWindow(xlim, ylim, log, asp, ...)
panel.first
plot.xy(xy, type, ...)
panel.last
if (axes) {
--
if (frame.plot)
localBox(...)
if (ann)
BTW, if I call :
R> grep("plot\\.", plot.default)
Error in as.character(x) : cannot coerce to vector
What about adding that line at the beginning of grep, or something else
to be able to do as.character on a function ?
if(is.function(x)) x <- body(x)
Cheers,
Romain
>>
>> Cheers,
>>
>> Romain
--
*mangosolutions*
/data analysis that delivers/
Tel +44 1249 467 467
Fax +44 1249 467 468
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] invert argument in grep
On 11/10/2006 12:52 PM, Romain Francois wrote:
> Duncan Murdoch wrote:
>> On 11/9/2006 5:14 AM, Romain Francois wrote:
>>> Hello,
>>>
>>> What about an `invert` argument in grep, to return elements that are
>>> *not* matching a regular expression :
>>>
>>> R> grep("pink", colors(), invert = TRUE, value = TRUE)
>>>
>>> would essentially return the same as :
>>>
>>> R> colors() [ - grep("pink", colors()) ]
>>>
>>>
>>> I'm attaching the files that I modified (against today's tarball) for
>>> that purpose.
>>
>> I think a more generally useful change would be to be able to return a
>> logical vector with TRUE for a match and FALSE for a non-match, so a
>> simple !grep(...) does the inversion. (This is motivated by the
>> recent R-help discussion of the fact that x[-selection] doesn't always
>> invert the selection when it's a vector of indices.)
>>
>> A way to do that without expanding the argument list would be to allow
>>
>> value="logical"
>>
>> as well as value=TRUE and value=FALSE.
>>
>> This would make boolean operations easy, e.g.
>>
>> colors()[grep("dark", colors(), value="logical")
>> & !grep("blue", colors(), value="logical")]
>>
>> to select the colors that contain "dark" but not "blue". (In this case
>> the RE to select that subset is rather simple because "dark" always
>> precedes "blue", but if that wasn't true, it would be a lot messier.)
>>
>> Duncan Murdoch
> Hi,
>
> It sounds like a nice thing to have. I would still prefer to type :
>
> R> grep ( "dark", grep("blue", colors(), value = TRUE, invert=TRUE),
> value = TRUE )
That's good for intersecting two searches, but not for other boolean
combinations.
My main point was that inversion isn't the only boolean operation you
may want, but R has perfectly good powerful boolean operators, so
installing a limited subset of boolean algebra into grep() is probably
the wrong approach.
>
>
> What about a way to pass more than one regular expression then be able
> to call :
>
> R> grep( c("dark", "blue"), colors(), value = TRUE, invert = c(TRUE, FALSE)
Again, it covers & and !, but it misses other boolean operators.
> I usually use that kind of shortcuts that are easy to remember.
>
> vgrep <- function(...) grep(..., value = TRUE)
> igrep <- function(...) grep(..., invert = TRUE)
> ivgrep <- vigrep <- function(...) grep(..., invert = TRUE, value = TRUE)
If you're willing to write these, then it's easy to write igrep without
an invert arg to grep:
igrep <- function(pat, x, ...)
setdiff(1:length(x), grep(pat, x, value = FALSE, ...))
ivgrep would also be easy, except for the weird semantics of value=TRUE
pointed out by Brian: but it could still be written with a little bit
of care.
Duncan Murdoch
>
> What about things like the arguments `after` and `before` in unix grep.
> That could be used when grepping inside a function :
>
> R> grep("plot\\.", body(plot.default) , value= TRUE)
> [1] "localWindow <- function(..., col, bg, pch, cex, lty, lwd)
> plot.window(...)"
> [2] "plot.new()"
> [3] "plot.xy(xy, type, ...)"
>
>
> when this could be useful (possibly).
>
> R> # grep("plot\\.", plot.default, after = 2, value = TRUE)
> R> tmp <- tempfile(); sink(tmp) ; print(body(plot.default)); sink();
> system( paste( "grep -A2 plot\\. ", tmp) )
> localWindow <- function(..., col, bg, pch, cex, lty, lwd)
> plot.window(...)
> localTitle <- function(..., col, bg, pch, cex, lty, lwd) title(...)
> xlabel <- if (!missing(x))
> --
> plot.new()
> localWindow(xlim, ylim, log, asp, ...)
> panel.first
> plot.xy(xy, type, ...)
> panel.last
> if (axes) {
> --
> if (frame.plot)
> localBox(...)
> if (ann)
>
>
> BTW, if I call :
>
> R> grep("plot\\.", plot.default)
> Error in as.character(x) : cannot coerce to vector
>
> What about adding that line at the beginning of grep, or something else
> to be able to do as.character on a function ?
>
> if(is.function(x)) x <- body(x)
>
>
> Cheers,
>
> Romain
>>>
>>> Cheers,
>>>
>>> Romain
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD SHLIB fails under Mac OS (PR#9353)
Full_Name: Hendrik Fuß Version: 2.4.0 OS: Mac OS 10.4.8 Submission from: (NULL) (201.27.208.230) R 2.4.0 on Mac OS X cannot seem to build shared libraries using R CMD SHLIB. R CMD SHLIB mylib.o yields an error message: /usr/bin/libtool: unknown option character `m' in: -macosx_version_min I cannot locate the Makefile, so I don't know what's wrong here. cheers Hendrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD SHLIB fails under Mac OS (PR#9353)
On Nov 10, 2006, at 2:04 PM, [EMAIL PROTECTED] wrote: > Full_Name: Hendrik Fuß > Version: 2.4.0 > OS: Mac OS 10.4.8 > Submission from: (NULL) (201.27.208.230) > > > R 2.4.0 on Mac OS X cannot seem to build shared libraries using R > CMD SHLIB. > > R CMD SHLIB mylib.o yields an error message: > /usr/bin/libtool: unknown option character `m' in: -macosx_version_min > Please update your Xcode - the libtool is too old. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in hist.Rd (PR#9355)
'Freedman' is misspelled (as 'Friedman') in
src/library/graphics/man/hist.Rd. As a result, the help page currently
implies that
breaks = "Fried"
is a valid argument to hist, but results in an error:
> hist(rnorm(100), breaks = "Fried")
Error in match.arg(tolower(breaks), c("sturges", "fd", "freedman-diaconis", :
'arg' should be one of sturges, fd, freedman-diaconis, scott
> sessionInfo()
R version 2.5.0 Under development (unstable) (2006-11-06 r39797)
i686-pc-linux-gnu
...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unwarranted warning from hist.default (PR#9356)
> x = rnorm(100) > b = seq(min(x) - 1, max(x) + 1, length = 11) > b [1] -3.4038769 -2.7451072 -2.0863375 -1.4275678 -0.7687980 -0.1100283 [7] 0.5487414 1.2075111 1.8662808 2.5250506 3.1838203 > > invisible(hist(x, breaks = b, include.lowest = TRUE, plot = FALSE)) Warning message: argument 'include.lowest' is not made use of in: hist.default(x, breaks = b, include.lowest = TRUE, plot = FALSE) I don't think a warning is appropriate, since ?hist says: include.lowest: logical; if 'TRUE', an 'x[i]' equal to the 'breaks' value will be included in the first (or last, for 'right = FALSE') bar. This will be ignored (with a warning) unless 'breaks' is a vector. and in this case 'breaks' does qualify as a "vector" by my understanding. Note that the warning goes away with 'plot=TRUE'. This suggests that this might have something to do with this vaguely worded entry in the NEWS for R 2.4.0: o hist(*, plot = FALSE) now warns about unused arguments. Neither the help page nor the NEWS file indicates what arguments are considered 'unused' when 'plot = FALSE', but either possibility --- (1) include.lowest is actually unused and (2) it is used and the warning is wrong --- is a bug. > sessionInfo() R version 2.4.0 Patched (2006-11-03 r39777) i486-pc-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unwarranted warning from hist.default (PR#9356)
[EMAIL PROTECTED] writes:
> > x = rnorm(100)
> > b = seq(min(x) - 1, max(x) + 1, length = 11)
> > b
> [1] -3.4038769 -2.7451072 -2.0863375 -1.4275678 -0.7687980 -0.1100283
> [7] 0.5487414 1.2075111 1.8662808 2.5250506 3.1838203
> >
> > invisible(hist(x, breaks = b, include.lowest = TRUE, plot = FALSE))
> Warning message:
> argument 'include.lowest' is not made use of in: hist.default(x,
> breaks = b, include.lowest = TRUE, plot = FALSE)
>
>
> I don't think a warning is appropriate, since ?hist says:
>
> include.lowest: logical; if 'TRUE', an 'x[i]' equal to the 'breaks'
> value will be included in the first (or last, for 'right =
> FALSE') bar. This will be ignored (with a warning) unless
> 'breaks' is a vector.
>
> and in this case 'breaks' does qualify as a "vector" by my understanding.
>
> Note that the warning goes away with 'plot=TRUE'. This suggests that
> this might have something to do with this vaguely worded entry in the
> NEWS for R 2.4.0:
>
>o hist(*, plot = FALSE) now warns about unused arguments.
>
> Neither the help page nor the NEWS file indicates what arguments are
> considered 'unused' when 'plot = FALSE', but either possibility ---
> (1) include.lowest is actually unused and (2) it is used and the
> warning is wrong --- is a bug.
As I read the code, the purpose is to warn people if they supply plot
arguments (density, xlim, ylim,) while plot=FALSE. There's a stop
list coded by
nf <- nf[is.na(match(nf, c("x", "breaks", "freq", "nclass",
"plot", "probability")))]
and I think the problem is just that "include.lowest" should have been
on the list.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unwarranted warning from hist.default (PR#9356)
On 10 Nov 2006 23:39:14 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > > x = rnorm(100)
> > > b = seq(min(x) - 1, max(x) + 1, length = 11)
> > > b
> > [1] -3.4038769 -2.7451072 -2.0863375 -1.4275678 -0.7687980 -0.1100283
> > [7] 0.5487414 1.2075111 1.8662808 2.5250506 3.1838203
> > >
> > > invisible(hist(x, breaks = b, include.lowest = TRUE, plot = FALSE))
> > Warning message:
> > argument 'include.lowest' is not made use of in: hist.default(x,
> > breaks = b, include.lowest = TRUE, plot = FALSE)
> >
> >
> > I don't think a warning is appropriate, since ?hist says:
> >
> > include.lowest: logical; if 'TRUE', an 'x[i]' equal to the 'breaks'
> > value will be included in the first (or last, for 'right =
> > FALSE') bar. This will be ignored (with a warning) unless
> > 'breaks' is a vector.
> >
> > and in this case 'breaks' does qualify as a "vector" by my understanding.
> >
> > Note that the warning goes away with 'plot=TRUE'. This suggests that
> > this might have something to do with this vaguely worded entry in the
> > NEWS for R 2.4.0:
> >
> >o hist(*, plot = FALSE) now warns about unused arguments.
> >
> > Neither the help page nor the NEWS file indicates what arguments are
> > considered 'unused' when 'plot = FALSE', but either possibility ---
> > (1) include.lowest is actually unused and (2) it is used and the
> > warning is wrong --- is a bug.
>
> As I read the code, the purpose is to warn people if they supply plot
> arguments (density, xlim, ylim,) while plot=FALSE.
That's not exactly what the NEWS entry says though.
> There's a stop
> list coded by
>
> nf <- nf[is.na(match(nf, c("x", "breaks", "freq", "nclass",
> "plot", "probability")))]
>
> and I think the problem is just that "include.lowest" should have been
> on the list.
Yes. And while you are at it, my suggestion would be to either take
'probability' and 'freq' off that list (which would make the NEWS
entry slightly more true) and/or clarify the intent of the warning.
The current help page is silent about the warnings when 'plot =
FALSE', and I don't think that's a good thing. It's not exactly a bug,
so I didn't file a bug report, but I did send a message to r-devel
about it a while back.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Making Solaris 10 x86/x64 build of R available?
Hi Professor Ripley, Thanks for the tip. It worked for me. I'll need to work on packaging next and maybe a bit more testing of the steps on another build machine. I just found out that there is already an older version of R binary for Solaris 10 at http://apstc.sun.com.sg/popup.php?l1=research&l2=projects&l3=s10port&f=applications#R Its readme has compile options: http://apstc.sun.com.sg/downloads/s10/README/R-project-2.2.0-sol10-x86.txt Perhaps we interacted with different R users. I would expect not all R users would want to compile their own R binary, similar to not all Linux users would like to compile their own kernel. Without a choice to download pre-built R on Solaris, there won't be a demand for the pre-build binary. Instead, people would focus on how to build their own or would use a pre-build binary for a different platform as an alternative. With this option, it might generate some demands. Only time will tell and I have no intention to speculate or make a case. Rather, I would like to identify ways to contribute within my ability and attention span. ;) Currently, I am considering different ways to post a build of R with HDF5 support. Hence my first email to check with this alias before I go off doing my own things. Thanks, David Prof Brian Ripley : > On Wed, 8 Nov 2006, Tai-Wei (David) Lin wrote: > >> Hi Folks, >> >> I've been working on a 32bit build of R on Solaris 10 x64. What are the >> steps for validate a build beyond make check? > > make check-all is a more comprehensive test, including of the > recommended packages. > >> Once I am ready to contribute a binary build / HowTo doc, who should I >> contact? > > I doubt if there is a demand for a binary build: AFAIK all Solaris users > of R have the tools to build from the sources. > > We do have a HowTo, the R-admin manual. If you tell us what you did in > the format of the entries there for specific OSes, we will incorporate > the information. (It is pretty much essential to know exactly which > compilers etc you used.) Several other people have built R on Solaris 10 > on x86_64 (which is I presume what you mean) using the current R-admin > instructions, so please tell us about small changes that might be > required on your system (and why). > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
