Re: [Rd] back port of Bug 15899 fix missing from R 3.2.1 RC release!!!

[Martin Maechler]

> Jack Howarth 
> on Mon, 15 Jun 2015 22:03:59 -0400 writes:

> Is there a reason why the fix for Bug 15899 - Omitted 'extern' on
> 'R_running_as_main_program' after refactor can cause linker errors for
> applications embedding R...

> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15899

> was never back ported for R 3.3 for the R 3.2.1 release? Restoring
> that omitted 'extern' to the declaration of 'int
> R_running_as_main_program;' in src/Rinterface.h is essential for being
> able to build Rstudio.

from the sources ...(which is unusual, but  I agree that that is
 an important exercise .. if only to implicitly "prove" that
 Rstudio is truly open source...) 

> Jack

I had not ported that change to R-patched because I had not been
100% sure that there were no "bad" implications -- so wanted to wait a
couple of days -- and then forgot... I am sorry.

Still your "reminder" comes very very late in the release
process for R 3.2.1. ... but as an exception, and because it
*is* so minimal (and has not caused any negative effects)
I have ported the change now to the 3.2.1 RC.

Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Add on argument in seq()

[Millot Gael]

ok.

Many thanks for your help !

Best,

Gael.


De : Gabriel Becker [mailto:gmbec...@ucdavis.edu]
Envoyé : lundi 15 juin 2015 23:54
À : Hadley Wickham
Cc : Millot Gael; r-devel
Objet : Re: [Rd] Add on argument in seq()

Millot,

On Mon, Jun 15, 2015 at 9:19 AM, Hadley Wickham 
mailto:h.wick...@gmail.com>> wrote:
Regardless of the value of the other arguments, the first element in
the output of seq() is _always_ `from`.

Indeed, as Hadley says, the output of seq must always start with from. It is a 
sequence starting at from and ending wherever the other arguments cause it to 
end. A sequence starting at from of length one is simply that single value. 
That is the contract I was referring to in my previous email. Apologies if that 
was not clear.
If that isn't the behavior you want when length.out  ends up being 1, your code 
will need to protect against that scenario.
I could see the argument for it being a warning/error if from and to are both 
specified and length.out is one, as a (lesser) part of the contract is that the 
last element of seq should be to, but even though it might make sense I really 
don't see that change going in. If I were you I'd just add an if statement in 
my function to check if length.out is 1 and move on.
Best,
~G


Hadley

On Mon, Jun 15, 2015 at 9:56 AM, Millot Gael 
mailto:gael.mil...@curie.fr>> wrote:
> Thanks for your answer.
>
> The rational behind my proposal is why taking "from" when length.out=1, more 
> than "to" or "NA", or " integer(0) " ?
>
> This question seems basic. But is is not in certain situations, like when 
> length.out =  unpredictable positive integer.
> And I haven't found in ?seq() the particular behavior of this function when 
> length.out = 1.
>
> Thanks for your help !
>
> Best,
>
> Gael.
>
>
> De : Gabriel Becker [mailto:gmbec...@ucdavis.edu]
> Envoyé : lundi 15 juin 2015 16:25
> À : Millot Gael
> Cc : r-devel
> Objet : Re: [Rd] Add on argument in seq()
>
>
> Millot,
>
> I think the problem with that is that what you propose isn't a sequence 
> starting  at from in any meaningful way, and thus does not satisfy the 
> contract of the seq function.
>
> Best,
> ~G
> On Jun 15, 2015 7:12 AM, "Millot Gael" 
> mailto:gael.mil...@curie.fr>>>
>  wrote:
> Hi.
>
> I have a problem with the default behavior of seq(), which gives the argument 
> "from" when the argument length.out = 1.
> This behavior is annoying when the number of value determine in length.out is 
> not predictable.
> Would it be possible to add an argument that propose the median/mean, i.e. 
> (from + to) / 2 when  length.out = 1 ? Examples:
>> seq(from = 1, to =  11, length.out=1) # current method gives "from"
> 1
>
>> seq(from = 1, to =  11, length.out=1) # alternative method gives the 
>> intermediate value of "from" and "to"
> 6
>
> Many thanks for your help.
>
> Best wishes,
>
> Gael Millot.
>
>
> Gael Millot
> UMR 3244 (IC-CNRS-UPMC) et Universite Pierre et Marie Curie
> Equipe Recombinaison et instabilite genetique
> Pav Trouillet Rossignol 5eme etage
> Institut Curie
> 26 rue d'Ulm
> 75248 Paris Cedex 05
> FRANCE
> tel : 33 1 56 24 66 34
> fax : 33 1 56 24 66 44
> Email : 
> gael.mil...@curie.fr>
> http://perso.curie.fr/Gael.Millot/index.html
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org>
>  mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


--
http://had.co.nz/



--
Gabriel Becker, PhD
Computational Biologist
Bioinformatics and Computational Biology
Genentech, Inc.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Add-on argument in sample()

[Peter Meissner]

Am .06.2015, 14:55 Uhr, schrieb Millot Gael :


Hi.

I have a problem with the default behavior of sample(), which performs  
sample(1:x) when x is a single value.

This behavior is well explained in ?sample.
However, this behavior is annoying when the number of value is not  
predictable. Would it be possible to add an argument
that desactivates this and perform the sampling on a single value ?  
Examples:

sample(10, size = 1, replace = FALSE)

10


sample(10, size = 3, replace = TRUE)

10 10 10


sample(10, size = 3, replace = FALSE)

Error


I think the problem here is that the function actually does what you would  
expect it to do given a statistic perspective. A sample of size three from  
a population of one without allowing to draw elements again that were  
drawn already is simply not defined. What shall the function give back?


... You can always wrap your code in a try() like this to prevent errors  
to break loops or functions:


try(sample(...))

... or you might check your arguments before execution:


if ( !replace & length(population) >= size ){
  sample(population, size = size , replace = replace)
}else{
  ...
}




Many thanks for your help.

Best wishes,

Gael Millot.


Gael Millot
UMR 3244 (IC-CNRS-UPMC) et Universite Pierre et Marie Curie
Equipe Recombinaison et instabilite genetique
Pav Trouillet Rossignol 5eme etage
Institut Curie
26 rue d'Ulm
75248 Paris Cedex 05
FRANCE
tel : 33 1 56 24 66 34
fax : 33 1 56 24 66 44
Email : gael.mil...@curie.fr
http://perso.curie.fr/Gael.Millot/index.html


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



Best, Peter

--

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Bugzilla activity?

[Milan Bouchet-Valat]

Hi!

I was wondering whether anybody was looking at the bugs on Bugzilla. I'm
asking because I've seen bugs tackled on the mailing list quite quickly,
but two fully reproducible reports I've filed on Bugzilla haven't
triggered any reaction in several weeks (for the older one).

FWIW, these are:
- Line goes beyond plot region
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16299
- format() does not respect decimal.mark="." when options(OutDec=",")
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16411


Regards

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Code demos via HTML help gives an error

[Henrik Bengtsson]

PROBLEM:
I'm getting error:

Error in order(matches$Position) : argument 1 is not a vector

Whenever I try to access a package's "Code demos" page via the link on
the package HTML index page.


SOME TROUBLESHOOTING:
Looking at for instance the 'stats' package.  The "Code demos" URL
takes the form

 http://127.0.0.1:30200/library/stats/demo

Click on this, takes me to

 http://127.0.0.1:30200/doc/html/Search?package=stats&agrep=FALSE&types=demo


WHERE:
I see this on R devel (2015-06-15 r68521) and R 3.2.1 RC (2015-06-14
r68516) - both on Platform: x86_64-w64-mingw32/x64 (64-bit).  Haven't
checked other platforms.


Regarding the imminent release of R 3.2.1; Sorry, I rarely use demos,
so it's only in this very moment I noticed.

/Henrik

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Bugzilla activity?

[Joris Meys]

Hi Milan,

I can't reproduce your first bug in R 3.2 on Windows 8.1, and I fail to
reproduce that one in R 3.1.2 as well. So that might explain why that one
isn't tackled.

The second bug you reported I can reproduce.

Cheers
Joris

On Tue, Jun 16, 2015 at 9:18 PM, Milan Bouchet-Valat 
wrote:

> Hi!
>
> I was wondering whether anybody was looking at the bugs on Bugzilla. I'm
> asking because I've seen bugs tackled on the mailing list quite quickly,
> but two fully reproducible reports I've filed on Bugzilla haven't
> triggered any reaction in several weeks (for the older one).
>
> FWIW, these are:
> - Line goes beyond plot region
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16299
> - format() does not respect decimal.mark="." when options(OutDec=",")
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16411
>
>
> Regards
>
> __
> 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 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Improving string concatenation

[Joshua Bradley]

Hi, first time poster here. During my time using R, I have always found
string concatenation to be (what I feel is) unnecessarily complicated by
requiring the use of the paste() or similar commands.


When searching for how to concatenate strings in R, several top search
results show answers that say to write your own function or override the
'+' operator.

Sample code like the following from this

page

"+" = function(x,y) {
if(is.character(x) & is.character(y)) {
return(paste(x , y, sep=""))
} else {
.Primitive("+")(x,y)
}}



An old (2005) post
 on r-help
mentioned possible performance reasons as to why this type of string
concatenation is not supported out of the box but did not go into detail.
Can someone explain why such a basic task as this must be handled by
paste() instead of just using the '+' operator directly? Would performance
degrade much today if the '+' form of string concatenation were added into
R by default?



Josh Bradley

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Different behavior of model.matrix between R 3.2 and R3.1.1

[Frank Harrell]

Terry Therneau has been very helpful on r-help but we can't figure out 
what change in R in the past months made extra columns appear in 
model.matrix when the terms object is subsetted to remove stratification 
factors in a Cox model.  Terry has changed his logic in the survival 
package to avoid this issue but he requires generating a larger design 
matrix then dropping columns.


A simple example is below.


strat <- function(x) x
d <- expand.grid(a=c('a1','a2'), b=c('b1','b2'))
d$y <- c(1,3,2,4)
f <- y ~ a * strat(b)
m <- model.frame(f, data=d)
Terms <- drop.terms(terms(f, data=d), 2)
model.matrix(Terms, m)

  (Intercept) aa2 aa1:strat(b)b2 aa2:strat(b)b2
1   1   0  0  0
2   1   1  0  0
3   1   0  1  0
4   1   1  0  1
. . .

The column corresponding to a='a1' b='b2' should not be there
(aa1:strat(b)b2).

This does seem to be a change in R.  Any help appreciated.


Terms attributes factor and term.labels are:

attr(,"factors")
 a a:strat(b)
y0  0
a1  2
strat(b) 0  1
attr(,"term.labels")
[1] "a"  "a:strat(b)"


Frank

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improving string concatenation

[Gábor Csárdi]

On Tue, Jun 16, 2015 at 6:32 PM, Joshua Bradley  wrote:
[...]
> An old (2005) post
>  on r-help
> mentioned possible performance reasons as to why this type of string
> concatenation is not supported out of the box but did not go into detail.
> Can someone explain why such a basic task as this must be handled by
> paste() instead of just using the '+' operator directly?

Well, R-core's reason was in that email thread, quoting:

"The issue is that only coercion between numeric
(broad sense, including complex) types is supported for the arithmetical
operators, presumably to avoid the ambiguity of things like

x <- 123.45
y <- as.character(1)
x + y

Should that be 124.45 or "123.451"?  One of the difficulties of any
dispatch on two arguments is how to do the best matching on two classes,
especially with symmetric operators like "+".  Internally R favours simple
fast rules."

Personally, I am not really convinced by this, because what currently
happens is this:

1 + "1"
#> Error in 1 + "1" : non-numeric argument to binary operator
"1" + 1
#> Error in "1" + 1 : non-numeric argument to binary operator

which is perfectly fine behavior, and it could stay the same with a
'+' string concatenation operator, i.e.:
- if both arguments are characters, call paste(),
- otherwise go on and do whatever is being done right now.
In other words, coercion to string is not important in the '+' operator.

> Would performance
> degrade much today if the '+' form of string concatenation were added into
> R by default?

Personally, I highly doubt it, but I don't have a benchmark to back this up.

Gabor

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improving string concatenation

[Hervé Pagès]

Hi Joshua,

On 06/16/2015 03:32 PM, Joshua Bradley wrote:

Hi, first time poster here. During my time using R, I have always found
string concatenation to be (what I feel is) unnecessarily complicated by
requiring the use of the paste() or similar commands.


When searching for how to concatenate strings in R, several top search
results show answers that say to write your own function or override the
'+' operator.

Sample code like the following from this

page

"+" = function(x,y) {
 if(is.character(x) & is.character(y)) {
 return(paste(x , y, sep=""))
 } else {
 .Primitive("+")(x,y)
 }}


Note that paste0() is a more convenient and more efficient way to
concatenate strings:

  paste0(x, y)  # no need to specify 'sep', no separator is inserted

Related to this, one thing that has always bothered me is the
different/inconsistent recycling schemes used by different binary
operations in R:

> 1:3 + integer(0)
integer(0)

> c("a", "b", "c") >= character(0)
logical(0)

> paste0(c("a", "b", "c"), character(0))
[1] "a" "b" "c"

> mapply(paste0, c("a", "b", "c"), character(0))
Error in mapply(paste0, c("a", "b", "c"), character(0)) :
  zero-length inputs cannot be mixed with those of non-zero length

If I was to override `+` to concatenate strings, I would make it stick
to the recycling scheme used by arithmetic and comparison operators
(which is the most sensible of all IMO).

H.





An old (2005) post
 on r-help
mentioned possible performance reasons as to why this type of string
concatenation is not supported out of the box but did not go into detail.
Can someone explain why such a basic task as this must be handled by
paste() instead of just using the '+' operator directly? Would performance
degrade much today if the '+' form of string concatenation were added into
R by default?



Josh Bradley

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
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...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improving string concatenation

[Gábor Csárdi]

On Tue, Jun 16, 2015 at 8:24 PM, Hervé Pagès  wrote:
[...]
>
> If I was to override `+` to concatenate strings, I would make it stick
> to the recycling scheme used by arithmetic and comparison operators
> (which is the most sensible of all IMO).

Yeah, I agree, paste's recycling rules are sometimes painful. This
could be "fixed" with a nice new '+' concatenation operator, too. :)

Gabor

> H.

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Different behavior of model.matrix between R 3.2 and R3.1.1

[Charles C. Berry]

On Tue, 16 Jun 2015, Frank Harrell wrote:

Terry Therneau has been very helpful on r-help but we can't figure out what 
change in R in the past months made extra columns appear in model.matrix when 
the terms object is subsetted to remove stratification factors in a Cox 
model.  Terry has changed his logic in the survival package to avoid this 
issue but he requires generating a larger design matrix then dropping 
columns.


A simple example is below.


strat <- function(x) x
d <- expand.grid(a=c('a1','a2'), b=c('b1','b2'))
d$y <- c(1,3,2,4)
f <- y ~ a * strat(b)
m <- model.frame(f, data=d)
Terms <- drop.terms(terms(f, data=d), 2)
model.matrix(Terms, m)

 (Intercept) aa2 aa1:strat(b)b2 aa2:strat(b)b2
1   1   0  0  0
2   1   1  0  0
3   1   0  1  0
4   1   1  0  1
. . .

The column corresponding to a='a1' b='b2' should not be there
(aa1:strat(b)b2).

This does seem to be a change in R.  Any help appreciated.


I get the same results with "Trick or Treat" == R 2.15.2, so the change 
must be before late 2012.


HTH,

Chuck

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improving string concatenation

[Joshua Bradley]

One of the poster's on the SO post I linked to previously suggested this
but if '+' were made to be S4 compliant, then adding the ability to concat
strings with '+' would be a relatively simple addition (no pun intended) to
the code base I believe. With a lot of other languages supporting this kind
of concatenation, this is what surprised me most when first learning R.

This is where my (lack of) experience in R starts to show and why I brought
up the question about performance. I'm wondering how bad performance would
be effected by making '+' (or all arithmetic operators in general) S4
compliant.

Josh Bradley

On Tue, Jun 16, 2015 at 8:35 PM, Gábor Csárdi 
wrote:

> On Tue, Jun 16, 2015 at 8:24 PM, Hervé Pagès  wrote:
> [...]
> >
> > If I was to override `+` to concatenate strings, I would make it stick
> > to the recycling scheme used by arithmetic and comparison operators
> > (which is the most sensible of all IMO).
>
> Yeah, I agree, paste's recycling rules are sometimes painful. This
> could be "fixed" with a nice new '+' concatenation operator, too. :)
>
> Gabor
>
> > H.
>
> [...]
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improving string concatenation

[Gábor Csárdi]

On Tue, Jun 16, 2015 at 10:30 PM, Joshua Bradley  wrote:
> One of the poster's on the SO post I linked to previously suggested this but
> if '+' were made to be S4 compliant, then adding the ability to concat
> strings with '+' would be a relatively simple addition (no pun intended) to
> the code base I believe. With a lot of other languages supporting this kind
> of concatenation, this is what surprised me most when first learning R.
>
> This is where my (lack of) experience in R starts to show and why I brought
> up the question about performance. I'm wondering how bad performance would
> be effected by making '+' (or all arithmetic operators in general) S4
> compliant.

I don't know much about S4, but '+' is already generic, so
implementation would be
easy I guess. Also, since it is already generic, I don't think this
would affect performance at all. (But FIXME please.)

The reason why it is not implemented is not because it is difficult.

Gabor

> Josh Bradley

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improving string concatenation

[Gabriel Becker]

On Jun 16, 2015 3:44 PM, "Joshua Bradley"  wrote:
>
> Hi, first time poster here. During my time using R, I have always found
> string concatenation to be (what I feel is) unnecessarily complicated by
> requiring the use of the paste() or similar commands.

I don't follow. In what sense is paste complicated to use? Not in the sense
of it's actual behavior, since what you propose below has identical
behavior. So is your objection simply the number of characters one must
type?

I would argue that having a separate verb makes code much more readable,
particularly at a quick glance. I know a character will come out of paste
no matter what goes in. That is not without value from a code maintenance
perspective. IMHO.

~G

>
>
> When searching for how to concatenate strings in R, several top search
> results show answers that say to write your own function or override the
> '+' operator.
>
> Sample code like the following from this
> <
http://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r
>
> page
>
> "+" = function(x,y) {
> if(is.character(x) & is.character(y)) {
> return(paste(x , y, sep=""))
> } else {
> .Primitive("+")(x,y)
> }}
>
>
>
> An old (2005) post
>  on
r-help
> mentioned possible performance reasons as to why this type of string
> concatenation is not supported out of the box but did not go into detail.
> Can someone explain why such a basic task as this must be handled by
> paste() instead of just using the '+' operator directly? Would performance
> degrade much today if the '+' form of string concatenation were added into
> R by default?
>
>
>
> Josh Bradley
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Improving string concatenation

[Joshua Bradley]

Bad choice of words I'm afraid. What I'm ultimately pushing for is a
feature request. To allow string concatenation with '+' by default. Sure I
can write my own string addition function (like the example I posted
previously) but I use it so often that I end up putting it in every script
I write.

It is ultimately a matter of readability and syntactic sugar I guess. As an
example, I work in the bioinformatics domain and write R scripts for
pipelines with calls to various programs that require a lot of parameters
to be set/varied. Seeing "paste" everywhere detracts from reading the code
(in my opinion).

This may not be a very strong argument, but to give a bit more objective
reason, I claim its more readable/intuitive because other big languages
have also picked up this convention (C++, java, javascript, python, etc.).


Josh Bradley
Graduate Student
University of Maryland

On Tue, Jun 16, 2015 at 11:00 PM, Gabriel Becker 
wrote:

>
> On Jun 16, 2015 3:44 PM, "Joshua Bradley"  wrote:
> >
> > Hi, first time poster here. During my time using R, I have always found
> > string concatenation to be (what I feel is) unnecessarily complicated by
> > requiring the use of the paste() or similar commands.
>
> I don't follow. In what sense is paste complicated to use? Not in the
> sense of it's actual behavior, since what you propose below has identical
> behavior. So is your objection simply the number of characters one must
> type?
>
> I would argue that having a separate verb makes code much more readable,
> particularly at a quick glance. I know a character will come out of paste
> no matter what goes in. That is not without value from a code maintenance
> perspective. IMHO.
>
> ~G
>
> >
> >
> > When searching for how to concatenate strings in R, several top search
> > results show answers that say to write your own function or override the
> > '+' operator.
> >
> > Sample code like the following from this
> > <
> http://stackoverflow.com/questions/4730551/making-a-string-concatenation-operator-in-r
> >
> > page
> >
> > "+" = function(x,y) {
> > if(is.character(x) & is.character(y)) {
> > return(paste(x , y, sep=""))
> > } else {
> > .Primitive("+")(x,y)
> > }}
> >
> >
> >
> > An old (2005) post
> >  on
> r-help
> > mentioned possible performance reasons as to why this type of string
> > concatenation is not supported out of the box but did not go into detail.
> > Can someone explain why such a basic task as this must be handled by
> > paste() instead of just using the '+' operator directly? Would
> performance
> > degrade much today if the '+' form of string concatenation were added
> into
> > R by default?
> >
> >
> >
> > Josh Bradley
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel