Rubbish values written with zero-length vectors (PR#14217)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Rubbish values written with zero-length vectors (PR#14217)

g.russell-2
Full_Name: George Russell
Version: 2.10.0, 2.11.0 (2009-12-13 r50716)
OS: Windows
Submission from: (NULL) (217.111.3.131)


R trace:
-- cut here --
> v <- integer(0)
> v[[1]] <- v
> v
[1] 20522144
> v <- numeric(0)
> v[[1]] <- v
> v
[1] 4.254131e-314
> sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252  
[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C                  
[5] LC_TIME=German_Germany.1252    

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base    
-- cut here --
Clearly the assignments v[[1]] <- v do not do anything useful, the problem is I
don't understand where the strange values left in v come from.

The same problem occurs with the 2.11.0 release r50716 and --vanilla. For
vanilla in Windows CMD mode I get different values in v, but ones which are to
me equally strange.

Many thanks for your help!

George Russell

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rubbish values written with zero-length vectors (PR#14217)

Henrik Bengtsson
Confirmed behavior on R version 2.10.1 Patched (2010-01-12 r50990) and
R version 2.11.0 Under development (unstable) (2010-02-14 r51138)
[Windows Vista]:

INTEGERS:
> v <- integer(5)
> v
[1] 0 0 0 0 0
> v[[2]] <- integer(0)
> v
[1]       0 2892960       0       0       0
> v[[4]] <- 1L[c()]
> v
[1]       0 2892960       0 2892960       0
> str(v)
 int [1:5] 0 2892960 0 2892960 0

DOUBLES:
> u <- integer(5)
> u
[1] 0 0 0 0 0
> u[[2]] <- integer(0)
> u
[1]       0 2892960       0       0       0
> u[[4]] <- 1L[c()]
> u
[1]       0 2892960       0 2892960       0
> str(u)
 str [1:5] 0 2892960 0 2892960 0

> u[[5]] <- double(0)
> u
[1]  0.000000e+00  3.487453e+07  0.000000e+00  3.487453e+07 4.261222e-314
> str(u)
 num [1:5] 0.00 3.49e+07 0.00 3.49e+07 4.26e-314

The actual "rubbish" values are the same within each R session, but
differ between R sessions.

Certain looks like stray memory cells are assigned.

Wanted behavior should probably be:

> u[[5]] <- double(0)
Error in u[[5]] <- double(0) : replacement has length zero

cf. u[5] <- double(0) and

> u[[5]] <- double(5)
Error in u[[5]] <- double(5) :
  more elements supplied than there are to replace

/Henrik

On Fri, Feb 19, 2010 at 1:45 PM,  <[hidden email]> wrote:

> Full_Name: George Russell
> Version: 2.10.0, 2.11.0 (2009-12-13 r50716)
> OS: Windows
> Submission from: (NULL) (217.111.3.131)
>
>
> R trace:
> -- cut here --
>> v <- integer(0)
>> v[[1]] <- v
>> v
> [1] 20522144
>> v <- numeric(0)
>> v[[1]] <- v
>> v
> [1] 4.254131e-314
>> sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
> [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
> [5] LC_TIME=German_Germany.1252
>
> attached base packages:
> [1] stats     graphics  grDevices datasets  utils     methods   base
> -- cut here --
> Clearly the assignments v[[1]] <- v do not do anything useful, the problem is I
> don't understand where the strange values left in v come from.
>
> The same problem occurs with the 2.11.0 release r50716 and --vanilla. For
> vanilla in Windows CMD mode I get different values in v, but ones which are to
> me equally strange.
>
> Many thanks for your help!
>
> George Russell
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rubbish values written with zero-length vectors (PR#14217)

Peter Dalgaard
In reply to this post by g.russell-2
[hidden email] wrote:

> Full_Name: George Russell
> Version: 2.10.0, 2.11.0 (2009-12-13 r50716)
> OS: Windows
> Submission from: (NULL) (217.111.3.131)
>
>
> R trace:
> -- cut here --
>> v <- integer(0)
>> v[[1]] <- v
>> v
> [1] 20522144
>> v <- numeric(0)
>> v[[1]] <- v
>> v
> [1] 4.254131e-314
>> sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252  
> [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C                  
> [5] LC_TIME=German_Germany.1252    
>
> attached base packages:
> [1] stats     graphics  grDevices datasets  utils     methods   base    
> -- cut here --
> Clearly the assignments v[[1]] <- v do not do anything useful, the problem is I
> don't understand where the strange values left in v come from.

You don't want to understand, believe me! ;-)

It's a bug, probably not the very worst kind, but accessing memory that
isn't yours is potentially harmful (but writing to it is considerably
worse).

Looks like the issue only concerns the right hand side; nothing to do
with the auto-expansion of v. I also get

 > v <- integer(0)
 > u <- integer(1)
 > u[[2]] <-v
 > u
[1]         0 142000760
 > u[[1]] <-v
 > u
[1] 142000760 142000760
 > a <- 1
 > a[[1]] <-v
 > a
[1] 142000760


>
> The same problem occurs with the 2.11.0 release r50716 and --vanilla. For
> vanilla in Windows CMD mode I get different values in v, but ones which are to
> me equally strange.
>
> Many thanks for your help!
>
> George Russell
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


--
    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
~~~~~~~~~~ - ([hidden email])              FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rubbish values written with zero-length vectors (PR#14217)

Seth Falcon-3
On 2/20/10 7:50 AM, Peter Dalgaard wrote:

> You don't want to understand, believe me! ;-)
>
> It's a bug, probably not the very worst kind, but accessing memory that
> isn't yours is potentially harmful (but writing to it is considerably
> worse).
>
> Looks like the issue only concerns the right hand side; nothing to do
> with the auto-expansion of v. I also get
>
>> v <- integer(0)
>> u <- integer(1)
>> u[[2]] <-v
>> u
> [1]         0 142000760
>> u[[1]] <-v
>> u
> [1] 142000760 142000760
>> a <- 1
>> a[[1]] <-v
>> a
> [1] 142000760

I'm thinking this should be an error.  Similar to:

> v = 1
> v[[1]] = integer(3)
Error in v[[1]] = integer(3) :
  more elements supplied than there are to replace

But instead not enough elements supplied.  Perhaps:

> v[[1]] = integer()
Error in v[[1]] = integer() : [[ ]] replacement has zero length

The code in do_subassign2_dflt currently does not check that the
replacement has length > 0 for the nsubs == 1 case.  I think we want:


@@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
SEXP rho)
        if (nsubs == 0 || CAR(subs) == R_MissingArg)
            error(_("[[ ]] with missing subscript"));
        if (nsubs == 1) {
+            if (length(y) == 0)
+                error(_("[[ ]] replacement has zero length"));
            offset = OneIndex(x, thesub, length(x), 0, &newname,
recursed ? len-1 : -1, R_NilValue);
            if (isVectorList(x) && isNull(y)) {
                x = DeleteOneVectorListItem(x, offset);


+ seth

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rubbish values written with zero-length vectors (PR#14217)

Seth Falcon-3
In reply to this post by g.russell-2
On 2/20/10 7:50 AM, Peter Dalgaard wrote:

> You don't want to understand, believe me! ;-)
>
> It's a bug, probably not the very worst kind, but accessing memory that
> isn't yours is potentially harmful (but writing to it is considerably
> worse).
>
> Looks like the issue only concerns the right hand side; nothing to do
> with the auto-expansion of v. I also get
>
>> v <- integer(0)
>> u <- integer(1)
>> u[[2]] <-v
>> u
> [1]         0 142000760
>> u[[1]] <-v
>> u
> [1] 142000760 142000760
>> a <- 1
>> a[[1]] <-v
>> a
> [1] 142000760

I'm thinking this should be an error.  Similar to:

> v = 1
> v[[1]] = integer(3)
Error in v[[1]] = integer(3) :
  more elements supplied than there are to replace

But instead not enough elements supplied.  Perhaps:

> v[[1]] = integer()
Error in v[[1]] = integer() : [[ ]] replacement has zero length

The code in do_subassign2_dflt currently does not check that the
replacement has length > 0 for the nsubs == 1 case.  I think we want:


@@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
SEXP rho)
        if (nsubs == 0 || CAR(subs) == R_MissingArg)
            error(_("[[ ]] with missing subscript"));
        if (nsubs == 1) {
+            if (length(y) == 0)
+                error(_("[[ ]] replacement has zero length"));
            offset = OneIndex(x, thesub, length(x), 0, &newname,
recursed ? len-1 : -1, R_NilValue);
            if (isVectorList(x) && isNull(y)) {
                x = DeleteOneVectorListItem(x, offset);


+ seth

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rubbish values written with zero-length vectors (PR#14217)

Peter Dalgaard
[hidden email] wrote:

Thanks, Seth. Martin Morgan sent a patch for a few lines above yours,
which I didn't have a chance to review until now:

-   if (!isVectorList(x) && LENGTH(y) > 1)
-       error(_("more elements supplied than there are to replace"));
+   if (!isVectorList(x) && LENGTH(y) != 1)
+       if (LENGTH(y) == 0)
+           error(_("fewer elements supplied than there are to replace"));
+       else
+           error(_("more elements supplied than there are to replace"));

I _think_ that you are both right that there is no way for a zero-length
RHS not to be an error. E.g.,

 > x[[0]] <- real(0)
Error in x[[0]] <- real(0) : attempt to select less than one element

The difference between Seth's solution and Martin's is whether to
pre-check for nsubs==1, and I don't think we want that because of

 > x <- matrix(1:4,2,2)
 > x[[2,2]]
[1] 4
 > x[[2,2]] <- integer(0)
 > x
      [,1]      [,2]
[1,]    1         3
[2,]    2 142000760


> On 2/20/10 7:50 AM, Peter Dalgaard wrote:
>> You don't want to understand, believe me! ;-)
>>
>> It's a bug, probably not the very worst kind, but accessing memory that
>> isn't yours is potentially harmful (but writing to it is considerably
>> worse).
>>
>> Looks like the issue only concerns the right hand side; nothing to do
>> with the auto-expansion of v. I also get
>>
>>> v <- integer(0)
>>> u <- integer(1)
>>> u[[2]] <-v
>>> u
>> [1]         0 142000760
>>> u[[1]] <-v
>>> u
>> [1] 142000760 142000760
>>> a <- 1
>>> a[[1]] <-v
>>> a
>> [1] 142000760
>
> I'm thinking this should be an error.  Similar to:
>
>> v = 1
>> v[[1]] = integer(3)
> Error in v[[1]] = integer(3) :
>   more elements supplied than there are to replace
>
> But instead not enough elements supplied.  Perhaps:
>
>> v[[1]] = integer()
> Error in v[[1]] = integer() : [[ ]] replacement has zero length
>
> The code in do_subassign2_dflt currently does not check that the
> replacement has length > 0 for the nsubs == 1 case.  I think we want:
>
>
> @@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
> SEXP rho)
>         if (nsubs == 0 || CAR(subs) == R_MissingArg)
>             error(_("[[ ]] with missing subscript"));
>         if (nsubs == 1) {
> +            if (length(y) == 0)
> +                error(_("[[ ]] replacement has zero length"));
>             offset = OneIndex(x, thesub, length(x), 0, &newname,
> recursed ? len-1 : -1, R_NilValue);
>             if (isVectorList(x) && isNull(y)) {
>                 x = DeleteOneVectorListItem(x, offset);
>
>
> + seth
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



--
    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
~~~~~~~~~~ - ([hidden email])              FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rubbish values written with zero-length vectors (PR#14217)

Peter Dalgaard
OK. I now have a version which seems to do the trick and reuses an
existing error message. Will commit to r-devel if and when make
check-devel succeeds.

-p

Peter Dalgaard wrote:

> [hidden email] wrote:
>
> Thanks, Seth. Martin Morgan sent a patch for a few lines above yours,
> which I didn't have a chance to review until now:
>
> -   if (!isVectorList(x) && LENGTH(y) > 1)
> -       error(_("more elements supplied than there are to replace"));
> +   if (!isVectorList(x) && LENGTH(y) != 1)
> +       if (LENGTH(y) == 0)
> +           error(_("fewer elements supplied than there are to replace"));
> +       else
> +           error(_("more elements supplied than there are to replace"));
>
> I _think_ that you are both right that there is no way for a zero-length
> RHS not to be an error. E.g.,
>
>  > x[[0]] <- real(0)
> Error in x[[0]] <- real(0) : attempt to select less than one element
>
> The difference between Seth's solution and Martin's is whether to
> pre-check for nsubs==1, and I don't think we want that because of
>
>  > x <- matrix(1:4,2,2)
>  > x[[2,2]]
> [1] 4
>  > x[[2,2]] <- integer(0)
>  > x
>      [,1]      [,2]
> [1,]    1         3
> [2,]    2 142000760
>
>
>> On 2/20/10 7:50 AM, Peter Dalgaard wrote:
>>> You don't want to understand, believe me! ;-)
>>>
>>> It's a bug, probably not the very worst kind, but accessing memory that
>>> isn't yours is potentially harmful (but writing to it is considerably
>>> worse).
>>>
>>> Looks like the issue only concerns the right hand side; nothing to do
>>> with the auto-expansion of v. I also get
>>>
>>>> v <- integer(0)
>>>> u <- integer(1)
>>>> u[[2]] <-v
>>>> u
>>> [1]         0 142000760
>>>> u[[1]] <-v
>>>> u
>>> [1] 142000760 142000760
>>>> a <- 1
>>>> a[[1]] <-v
>>>> a
>>> [1] 142000760
>>
>> I'm thinking this should be an error.  Similar to:
>>
>>> v = 1
>>> v[[1]] = integer(3)
>> Error in v[[1]] = integer(3) :
>>   more elements supplied than there are to replace
>>
>> But instead not enough elements supplied.  Perhaps:
>>
>>> v[[1]] = integer()
>> Error in v[[1]] = integer() : [[ ]] replacement has zero length
>>
>> The code in do_subassign2_dflt currently does not check that the
>> replacement has length > 0 for the nsubs == 1 case.  I think we want:
>>
>>
>> @@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
>> SEXP rho)
>>         if (nsubs == 0 || CAR(subs) == R_MissingArg)
>>             error(_("[[ ]] with missing subscript"));
>>         if (nsubs == 1) {
>> +            if (length(y) == 0)
>> +                error(_("[[ ]] replacement has zero length"));
>>             offset = OneIndex(x, thesub, length(x), 0, &newname,
>> recursed ? len-1 : -1, R_NilValue);
>>             if (isVectorList(x) && isNull(y)) {
>>                 x = DeleteOneVectorListItem(x, offset);
>>
>>
>> + seth
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>


--
    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
~~~~~~~~~~ - ([hidden email])              FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel