Re: [Rd] "+" operator on characters revisited
Gabor Grothendieck writes:
> On Sat, Jan 22, 2011 at 3:08 PM, Vitalie S. wrote:
>>
>> Hello everyone!
>>
>> Motivated by the recent post on SO
>>
> http://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r>
>> I wonder what is the current state of argument on making "+" to
>> concatenate character vectors. The "+" method is still sealed for
>> signature("character", "character") in the current version of R.
>>
>> The 4 years old R-devel thread
>> https://www.stat.math.ethz.ch/pipermail/r-devel/2006-August/038991.html>
>> on the same topic, stopped without reaching any definite conclusion.
>>
>> The only definite argument occurred in the thread against "+" operator
>> was the lack of commutativity (as if one have to prove algebraic
>> theorems in R).
>>
>> Yet another useful suggestion of introducing cat0() and paste0(), for
>> the common use of cat and paste with sep="" was not absorbed by the
>> core R either.
>
> The gsubfn package has always had a paste0 function and I would be
> happy to remove it if the core adds it.
>
> Also the gsubfn supports quasi perl style string interpolation that
> can sometimes be used to avoid the use of paste in the first place.
> Just preface the function in question by fn$ like this:
>
> library(gsubfn)
> fn$cat("pi = $pi\n")
Thanks for the tip. Not bad indeed.
Almost as readable as
cat("pi = " + pi + "\n")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "+" operator on characters revisited
On Sun, Jan 23, 2011 at 6:56 AM, Vitalie S. wrote:
> Gabor Grothendieck writes:
>
>> On Sat, Jan 22, 2011 at 3:08 PM, Vitalie S. wrote:
>>>
>>> Hello everyone!
>>>
>>> Motivated by the recent post on SO
>>>
>> http://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r>
>>> I wonder what is the current state of argument on making "+" to
>>> concatenate character vectors. The "+" method is still sealed for
>>> signature("character", "character") in the current version of R.
>>>
>>> The 4 years old R-devel thread
>>> https://www.stat.math.ethz.ch/pipermail/r-devel/2006-August/038991.html>
>>> on the same topic, stopped without reaching any definite conclusion.
>>>
>>> The only definite argument occurred in the thread against "+" operator
>>> was the lack of commutativity (as if one have to prove algebraic
>>> theorems in R).
>>>
>>> Yet another useful suggestion of introducing cat0() and paste0(), for
>>> the common use of cat and paste with sep="" was not absorbed by the
>>> core R either.
>>
>> The gsubfn package has always had a paste0 function and I would be
>> happy to remove it if the core adds it.
>>
>> Also the gsubfn supports quasi perl style string interpolation that
>> can sometimes be used to avoid the use of paste in the first place.
>> Just preface the function in question by fn$ like this:
>>
>> library(gsubfn)
>> fn$cat("pi = $pi\n")
>
> Thanks for the tip. Not bad indeed.
> Almost as readable as
>
> cat("pi = " + pi + "\n")
To me the + can be substantially less readable. The need to
repeatedly quote everything makes it just as bad as paste. Compare
the following and try to figure out if there is an error in quoting in
the + and paste solutions. Trying to distinguish the single and
double quotes is pretty difficult but simple in the fn$ and sprintf
solutions. Even if there were no quotes the constant need to
interpose quotes makes it hard to read.
library(sqldf) # also pulls in gsubfn which has fn$ and paste0
plant <- "Qn1"
treatment <- "nonchilled"
# using +
# sqldf("select * from CO2 where Plant = '" + plant + "' and Treatment
= '" + treatment + "' limit 10")
# using paste0, also from gsubfn
sqldf(paste0("select * from CO2 where Plant = '", plant, "' and
Treatment = '", treatment, "' limit 10"))
# using paste, almost the same as last one
sqldf(paste("select * from CO2 where Plant = '", plant, "' and
Treatment = '", treatment, "' limit 10", sep = ""))
# With the perl-like interpolation you don't need the repeated quoting
in the first place so its much clearer.
# using perl-like interpolation from gsubfn
fn$sqldf("select * from CO2 where Plant = '$plant' and Treatment =
'$treatment' limit 10")
# sprintf is nearly as good as the perl-like interpolation except you
have to match up % codes and arguments which is a bit of nuisance #
and there are more parentheses. On the other hand it does have the
advantage that there is the facility for fancier formatting codes
# (though this example does not illustrate that aspect):
# using sprintf
sqldf(sprintf("select * from CO2 where Plant = '%s' and Treatment =
'%s' limit 10", plant, treatment))
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] feature request: additional hook in plot.new()
Request: An additional hook in plot.new() that is called prior to the call to
.Internal(plot.new()).
Reason: To allow the hook to set up or modify a graphics device that the new
plot will appear in.
The code change needed for this is simple - just 4 new lines of R code in
src/library/graphics/R/plot.R:plot.new()
Current definition of plot.new() in src/library/graphics/R/plot.R:
plot.new <- function()
{
.Internal(plot.new())
for(fun in getHook("plot.new")) {
if(is.character(fun)) fun <- get(fun)
try(fun())
}
invisible()
}
New definition of plot.new() in src/library/graphics/R/plot.R:
plot.new <- function()
{
for(fun in getHook("plot.prenew")) {
if(is.character(fun)) fun <- get(fun)
try(fun())
}
.Internal(plot.new())
for(fun in getHook("plot.new")) {
if(is.character(fun)) fun <- get(fun)
try(fun())
}
invisible()
}
In src/library/graphics/man/frame.Rd after the existing sentence beginning "There is
a hook..." in the DETAILS section, the following sentence could be added:
"There is another hook called \code{"plot.prenew"} which is called before advancing
the frame. This hook can be used to create a new plot "
The name of the hook is not very important -- I've suggested "plot.prenew" here. Another
possibility could be "plot.new0".
More detail on the reason:
In a tabbed graphics widget
(https://r-forge.r-project.org/projects/tabbedplots/ ), having this hook would
enable it to operate in a mode where a new tab is automatically created for
each new plot.
thanks for your consideration,
Tony Plate
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "+" operator on characters revisited
> Yet another useful suggestion of introducing cat0() and paste0(), for > the common use of cat and paste with sep="" was not absorbed by the > core R either. stringr has str_c which is a replacement for paste with sep = "" and automatic removal of length 0 inputs. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "+" operator on characters revisited
On Jan 22, 2011, at 21:08 , Vitalie S. wrote: > The only definite argument occurred in the thread against "+" operator > was the lack of commutativity (as if one have to prove algebraic > theorems in R). I think the real killer was associativity, combined with coercion rules: Is "x"+1+2 supposed to be equal to "x12" or "x3"? -- Peter Dalgaard 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
Re: [Rd] "+" operator on characters revisited
Consider the following from Python 2.6.5: >>> 'abc'+ 2 Traceback (most recent call last): File "", line 1, in 'abc'+ 2 TypeError: cannot concatenate 'str' and 'int' objects >>> 'abc'+'2' 'abc2' >>> Spencer On 1/23/2011 8:09 AM, Hadley Wickham wrote: Yet another useful suggestion of introducing cat0() and paste0(), for the common use of cat and paste with sep="" was not absorbed by the core R either. stringr has str_c which is a replacement for paste with sep = "" and automatic removal of length 0 inputs. Hadley -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "+" operator on characters revisited
On 1/23/2011 8:50 AM, peter dalgaard wrote: On Jan 22, 2011, at 21:08 , Vitalie S. wrote: The only definite argument occurred in the thread against "+" operator was the lack of commutativity (as if one have to prove algebraic theorems in R). I think the real killer was associativity, combined with coercion rules: Is "x"+1+2 supposed to be equal to "x12" or "x3"? Excellent: This seems like a good reason to follow Python: Allow "a+b" with a character vector "a" only if "b" is also a character vector (or factor?). This example raises another question: If we allow "a+b" for "a" and "b" both character vectors (and give an error if one is numeric), what do we do with factors? If "a" is a factor, return a factor? Spencer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "+" operator on characters revisited
On 23/01/2011 11:50 AM, peter dalgaard wrote: On Jan 22, 2011, at 21:08 , Vitalie S. wrote: The only definite argument occurred in the thread against "+" operator was the lack of commutativity (as if one have to prove algebraic theorems in R). I think the real killer was associativity, combined with coercion rules: Is "x"+1+2 supposed to be equal to "x12" or "x3"? As I pointed out at the time, we don't even have associativity for integer addition. For example in -1L + .Machine$integer.max + 1L the two possibilities (-1L + .Machine$integer.max) + 1L and -1L + (.Machine$integer.max + 1L) give different results. When I try it now without parentheses, I get the same answer as the first one, but I don't believe we guarantee that that will always be so. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] feature request: additional hook in plot.new()
Hi Tony,
On Sunday 23 January 2011, you wrote:
> Request: An additional hook in plot.new() that is called prior to the call
> to .Internal(plot.new()). Reason: To allow the hook to set up or modify a
> graphics device that the new plot will appear in.
for what it's worth, you can work around the lack of this hook by modifying
plot.new(). Here's what we do in RKWard (in order to add a plot history
feature):
"plot.new" <- function ()
{
# [your code goes here]
eval (body (.rk.plot.new.default))
}
formals (plot.new) <- formals (graphics::plot.new)
.rk.plot.new.default <- graphics::plot.new
# Note: This needs to be called *after* the package has been loaded
assignInNamespace ("plot.new", plot.new, envir=as.environment
("package:graphics"))
Note that at least persp() also sets up a new plot, _without_ calling
plot.new(). So you'll want to catch that as well.
In RKWard we use this technique at a number of places to insert "hooks" where
there are none, regularly.
Regards
Thomas
signature.asc
Description: This is a digitally signed message part.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows script editor and locale
On Jan 21, 2011, at 10:57 AM, Prof Brian Ripley wrote: > There is no support for files in alternative encodings in RGui's menus: not > to source files nor to load into a pager or the script editor. (I believe > all of those long predate any support for encodings in R.) > > Such provision is rather rare on Windows: files are almost everywhere assumed > to be in the current Windows codepage (or sometimes WinANSI, as in the > 'Command prompt' terminal) or in so-called Unicode (usually UCS-2LE, possibly > UTF-16LE, with a BOM). > > I think you could equally ask the same question in reverse: AFAICS the R.app > GUI has no support for Latin-1 nor UCS-2LE files. At least in our UK > experience, the proportion of non-Windows users is so low that it is those > (including this instructor) who expect to adjust. > I have added a) encoding choice to the Save panel so you can save a file in a wide range of encodings and b) auto-detection of Unicode files (UTF-16LE with BOM) so they will be handled transparently. Note that R is always run in a UTF-8 locale so this only affects the read/save operations of R documents. There are a few loose ends I want to tackle later next week and document re-interpretation code is included but without a GUI yet (the idea is that if you fall-back to MacRoman you can re-interpret it in any other of the 8-bit character encodings like latin1 if you wish). Cheers, Simon > What might make some sense is for file.edit() to gain a 'fileEncoding' > argument so this could at least be done from the command-line. > > On Fri, 21 Jan 2011, peter dalgaard wrote: > >> Maybe I'm just overlooking something, but I can't figure out how to >> set/change the locale of a file loaded into the built-in script editor on >> Windows. >> >> The generic issue is that if I make a teaching script on a Mac, save it to a >> USB stick, and open it in the script editor in a classroom, then special >> Danish characters in the comments come out as two-byte sequences, which are >> pretty unsightly. I know that I can convert the file with iconv (or >> iconv()), but then I'd have to maintain two copies of the same file for the >> two operating systems, if I want the students to access it. Would be nice if >> there was something like a set-coding-system to call up via a menu item. >> >> Any pointers? >> >> -- >> Peter Dalgaard >> 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 >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > 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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] feature request: additional hook in plot.new()
On Jan 23, 2011, at 10:44 AM, Tony Plate wrote:
> Request: An additional hook in plot.new() that is called prior to the call to
> .Internal(plot.new()).
> Reason: To allow the hook to set up or modify a graphics device that the new
> plot will appear in.
>
> The code change needed for this is simple - just 4 new lines of R code in
> src/library/graphics/R/plot.R:plot.new()
>
> Current definition of plot.new() in src/library/graphics/R/plot.R:
>
> plot.new <- function()
> {
>.Internal(plot.new())
>for(fun in getHook("plot.new")) {
>if(is.character(fun)) fun <- get(fun)
>try(fun())
>}
>invisible()
> }
>
> New definition of plot.new() in src/library/graphics/R/plot.R:
>
> plot.new <- function()
> {
>for(fun in getHook("plot.prenew")) {
>if(is.character(fun)) fun <- get(fun)
>try(fun())
>}
>.Internal(plot.new())
>for(fun in getHook("plot.new")) {
>if(is.character(fun)) fun <- get(fun)
>try(fun())
>}
>invisible()
> }
>
> In src/library/graphics/man/frame.Rd after the existing sentence beginning
> "There is a hook..." in the DETAILS section, the following sentence could be
> added:
>
> "There is another hook called \code{"plot.prenew"} which is called before
> advancing the frame. This hook can be used to create a new plot "
>
> The name of the hook is not very important -- I've suggested "plot.prenew"
> here. Another possibility could be "plot.new0".
>
> More detail on the reason:
>
> In a tabbed graphics widget
> (https://r-forge.r-project.org/projects/tabbedplots/ ), having this hook
> would enable it to operate in a mode where a new tab is automatically created
> for each new plot.
>
Just note on the latter: I would expect this to be usually better handled by
the device/UI as you will be in conflict with things like plot history, already
supported tabbed devices etc. Do you have a use case where the above has any
benefits over separate devices in tabs? (The website has little detail so I'm
just guessing what you're up to ..).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "Simulate" package namespace at development stage
Dear list, I was wondering if it is possible to create and use a package namespace at the development stage of a package. To clarify, I would like to make sure that my package functions (and not some other functions that happen to have identical names) are called by prepending function names appropriately (e.g. my.package::foo()). Is that possible before a package is actually build and loaded? If so, could you tell me how to do it? Thanks a lot! Janko __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "+" operator on characters revisited
Spencer Graves writes:
> On 1/23/2011 8:50 AM, peter dalgaard wrote:
>> On Jan 22, 2011, at 21:08 , Vitalie S. wrote:
>>
>>> The only definite argument occurred in the thread against "+" operator
>>> was the lack of commutativity (as if one have to prove algebraic
>>> theorems in R).
>> I think the real killer was associativity, combined with coercion rules:
>>
>> Is "x"+1+2 supposed to be equal to "x12" or "x3"?
>>
> Excellent: This seems like a good reason to follow Python: Allow
> "a+b" with a character vector "a" only if
> "b" is also a character vector (or factor?).
>
> This example raises another question: If we allow "a+b" for "a" and
> "b" both character vectors (and give an
> error if one is numeric), what do we do with factors? If "a" is a factor,
> return a factor?
If we define custom %+% as:
`%+%` <- function(a, b){
if(is.character(a) || is.character(b))
paste(as.character(a), as.character(b), sep="")
else
a + b
}
because of higher precedence of %any% operators over binary + we have:
"a" %+% 1 %+% 2
## [1] "a12"
and
str("a" %+% factor(1:2))
## chr [1:2] "a1" "a2"
so if + on characters would behave "as if" having slightly higher priority than
other + operators that might solve reasonably the problem.
Vitalie.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "+" operator on characters revisited
On 1/23/2011 12:15 PM, Vitalie S. wrote:
Spencer Graves writes:
On 1/23/2011 8:50 AM, peter dalgaard wrote:
On Jan 22, 2011, at 21:08 , Vitalie S. wrote:
The only definite argument occurred in the thread against "+" operator
was the lack of commutativity (as if one have to prove algebraic
theorems in R).
I think the real killer was associativity, combined with coercion rules:
Is "x"+1+2 supposed to be equal to "x12" or "x3"?
Excellent: This seems like a good reason to follow Python: Allow "a+b" with a
character vector "a" only if
"b" is also a character vector (or factor?).
This example raises another question: If we allow "a+b" for "a" and "b"
both character vectors (and give an
error if one is numeric), what do we do with factors? If "a" is a factor,
return a factor?
If we define custom %+% as:
`%+%`<- function(a, b){
if(is.character(a) || is.character(b))
paste(as.character(a), as.character(b), sep="")
else
a + b
}
because of higher precedence of %any% operators over binary + we have:
"a" %+% 1 %+% 2
## [1] "a12"
and
str("a" %+% factor(1:2))
## chr [1:2] "a1" "a2"
so if + on characters would behave "as if" having slightly higher priority than
other + operators that might solve reasonably the problem.
Vitalie.
No: 'a' %+% (1 %+%2) != ('a' %+% 1) %+% 2, as Peter Dalgaard noted:
'a3' != 'a12'.
__
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
