Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

[Gabriel Becker]

On Sat, May 23, 2020 at 9:59 PM Hervé Pagès  wrote:

> On 5/23/20 17:45, Gabriel Becker wrote:
> > Maybe my intuition is just
> > different but when I collapse multiple character vectors together, I
> > expect all the characters from each of those vectors to be in the
> > resulting collapsed one.
>
> Yes I'd expect that too. But the **collapse** operation in paste() has
> never been about collapsing **multiple** character vectors together.
> What it does is collapse the **single** character vector that comes out
> of the 'sep' operation.
>

I understand what it does, I broke ti down the same way in my post earlier
in the thread. the fact remains is that it is a single function which
significantly muddies the waters. so you can say

paste0(x,y, collapse=",", recycle0=TRUE)

is not a collapse operation on multiple vectors, and of course there's a
sense in which you're not wrong (again I understand what these functions
do), but it sure looks like one in the invocation, doesn't it?

Honestly the thing that this whole discussion has shown me most clearly is
that, imho, collapse (accepting ONLY one data vector) and paste(accepting
multiple) should never have been a single function to begin with.  But that
ship sailed long long ago.




> So
>
>paste(x, y, z, sep="", collapse=",")
>
> is analogous to
>
>sum(x + y + z)
>

Honestly, I'd be significantly more comfortable if

1:10 + integer(0) + 5

were an error too.

At least I'm consistent right?

~G

[[alternative HTML version deleted]]

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

[Rd] R 4.0.1 scheduled for June 6

[Peter Dalgaard via R-devel]

Full schedule is available on developer.r-project.org.

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
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] [External] Re: Surpising behavior when using an active binding as loop index in R 4.0.0

[luke-tierney]

On Sun, 24 May 2020, Deepayan Sarkar wrote:


A shorter reproducible example:

example(makeActiveBinding)
for (fred in 1:3) { 0 }
ls()

Both problems go away if you first do

compiler::enableJIT(2)

So looks like a bug in compiling the for loop.


Not in compiling but in the byte code interpreter. It was not handling
active bindings for the loop variable properly. This was fixed
yesterday in R--devel and R-patched, so will be fixed in R 4.0.1.

Best,

luke



-Deepayan

On Sat, May 23, 2020 at 5:45 PM Thomas Friedrichsmeier via R-devel
 wrote:


Possibly just a symptom of the earlier behavior, but I'll amend my
example, below, with an even more disturbing observation:

Am Sat, 23 May 2020 13:19:24 +0200
schrieb Thomas Friedrichsmeier via R-devel :
[...]

Consider the code below:

makeActiveBinding("i",
  function(value) {
  if (missing(value)) {
  x
  } else {
  print("set")
  x <<- value
  }
  }, globalenv())

i <- 1 # output "set"
print(i)   # output [1] 1

# Surprising behavior starts here:
for(i in 2:3) print(i) # output [1] "set"
   #NULL
   #NULL

print(i)   # output NULL
print(x)   # output NULL

i <- 4 # output "set"
print(i)   # ouput [1] 4
print(x)   # ouput [1] 4


ls()
# Error in ls() :
#  Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'

Regards
Thomas
__
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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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

Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

[Hervé Pagès]

On 5/24/20 00:26, Gabriel Becker wrote:



On Sat, May 23, 2020 at 9:59 PM Hervé Pagès > wrote:


On 5/23/20 17:45, Gabriel Becker wrote:
 > Maybe my intuition is just
 > different but when I collapse multiple character vectors together, I
 > expect all the characters from each of those vectors to be in the
 > resulting collapsed one.

Yes I'd expect that too. But the **collapse** operation in paste() has
never been about collapsing **multiple** character vectors together.
What it does is collapse the **single** character vector that comes out
of the 'sep' operation.


I understand what it does, I broke ti down the same way in my post 
earlier in the thread. the fact remains is that it is a single function 
which significantly muddies the waters. so you can say


paste0(x,y, collapse=",", recycle0=TRUE)

is not a collapse operation on multiple vectors, and of course there's a 
sense in which you're not wrong (again I understand what these functions 
do), but it sure looks like one in the invocation, doesn't it?


Honestly the thing that this whole discussion has shown me most clearly 
is that, imho, collapse (accepting ONLY one data vector) and 
paste(accepting multiple) should never have been a single function to 
begin with.  But that ship sailed long long ago.


Yes :-(



So

    paste(x, y, z, sep="", collapse=",")

is analogous to

    sum(x + y + z)


Honestly, I'd be significantly more comfortable if

1:10 + integer(0) + 5

were an error too.


This is actually the recycling scheme used by mapply():

  > mapply(function(x, y, z) c(x, y, z), 1:10, integer(0), 5)
  Error in mapply(FUN = FUN, ...) :
zero-length inputs cannot be mixed with those of non-zero length

AFAIK base R uses 3 different recycling schemes for n-ary operations:

(1) The recycling scheme used by arithmetic and comparison operations
(Arith, Compare, Logic group generics).

(2) The recycling scheme used by classic paste().

(3) The recycling scheme used by mapply().

Having such a core mechanism like recycling being inconsistent across 
base R is sad. It makes it really hard to predict how a given n-ary 
function will recycle its arguments unless you spend some time trying it 
yourself with several combinations of vector lengths. It is of course 
the source of numerous latent bugs. I wish there was only one but that's 
just a dream.


None of these 3 recycling schemes is perfect. IMO (2) is by far the 
worst. (3) is too restrictive and would need to be refined if we wanted 
to make it a good universal recycling scheme.


Anyway I don't think it makes sense to introduce a 4th recycling scheme 
at this point even though it would be a nice item to put on the wish 
list for R 7.0.0 with the ultimate goal that it will universally adopted 
in R 11.0.0 ;-)


So if we have to do with what we have IMO (1) is the scheme that makes 
most sense although I agree that it can do some surprising things for 
some unusual combinations of vector lengths. It's the scheme I adhere to 
in my own binary operations e.g. in S4Vector::pcompare().


The modest proposal of the 'recycle0' argument is only to let the user 
switch from recycling scheme (2) to (1) if they're not happy with scheme 
(2) (I'm one of them). Switching to scheme (3) or to a new custom scheme 
would be a completely different proposal.




At least I'm consistent right?


Yes :-)

Anyway discussing recycling schemes is interesting but not directly 
related with what the OP brought up (behavior of the 'collapse' operation).


Cheers,
H.



~G


--
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