[graalvm-users] Setting attributes inconsistencies
Rodrigo Botafogo
rodrigo.a.botafogo at gmail.com
Mon Jul 9 11:00:44 PDT 2018
Lukas,
Thanks a lot for the explanation... things are now clear!
On Mon, Jul 9, 2018 at 1:01 PM Lukas Stadler <lukas.stadler at oracle.com>
wrote:
> R vectors are passed around as immutable values, so that in theory every
> operation will create a new copy of the vector.
> E.g., the assignment function `names<-` returns a vector with a modified
> "names" attribute, so that "names(vect) <- nams)" is equivalent to "vect <-
> `names<-`(vect, nams)".
> Since creating new vectors all the time would be prohibitively expensive,
> R engines internally keep some form of "reference count" to see whether the
> vector is accessible from outside the current scope.
> In the first call to `names<-` in your example, the vector is only
> referenced by the "vect" symbol, so that it can be modified in place.
>
> If you print the vector, the (internally quite complex) printing code will
> force the vector into a "shared" state, which requires a copy-on-write the
> next time it is modified, which in your case is the call to `dim<-`.
> This call will then create a new copy of the vector with the dimensions
> set, but leave the original one (in "vect") unchanged.
>
> Long story short, the update functions (`xyz<-`) shouldn't be called
> directly in R, and (as Stepan said) FastR should mark all objects as
> "shared" when they escape the R context.
>
> - Lukas
>
> On 09.07.2018, at 15:45, Rodrigo Botafogo <rodrigo.a.botafogo at gmail.com>
> wrote:
>
> Hello,
>
> Thanks for all the answers. It just did a bunch of test and it seems to me
> now to either be a bug in Gnu R or just a very strange behavior that I
> don't understand either about R. I will report it to the Gnu R user groups
> and see what they tell me. The important point here is that Graalvm is
> doing exactly the same as Gnu R.
>
> For the curious, here what happens in GNU R. Bellow, two examples. The
> only difference between the two is that I commented a 'print' on the second
> code:
>
> Example 1:
>
> > vect = c(1, 2, 3, 4, 5, 6);
> > nams = c("a", "b", "c", "d", "e", "f");
> > `names<-`(vect, nams);
> a b c d e f
> 1 2 3 4 5 6
> > print(vect);
> a b c d e f
> 1 2 3 4 5 6
> > dims = c(3, 2);
> > `dim<-`(vect, dims);
> [,1] [,2]
> [1,] 1 4
> [2,] 2 5
> [3,] 3 6
> > print(vect);
> a b c d e f
> 1 2 3 4 5 6
>
> As we can see, the vect at the end does not have the dimension property.
>
> Example 2
>
> > vect = c(1, 2, 3, 4, 5, 6);
> > nams = c("a", "b", "c", "d", "e", "f");
> > `names<-`(vect, nams);
> a b c d e f
> 1 2 3 4 5 6
> > # print(vect);
> > dims = c(3, 2);
> > `dim<-`(vect, dims);
> [,1] [,2]
> [1,] 1 4
> [2,] 2 5
> [3,] 3 6
> > print(vect);
> [,1] [,2]
> [1,] 1 4
> [2,] 2 5
> [3,] 3 6
>
> In this example, the first 'print(vect)' is commented out. When printing
> vect on the last line, the dimension is set.
>
>
> On Fri, Jul 6, 2018 at 7:03 PM Benoit Daloze <eregontp at gmail.com> wrote:
>
>> It seems to me it's as Stepan said.
>> R of course does not reassign Ruby variables.
>> And most R operations might or not mutate the receiver in place, with
>> the general model of mutating only if it's unobservable
>> (it is observable here, `vec` is actually a second reference to the
>> initial vector).
>>
>> On Fri, Jul 6, 2018 at 11:31 PM, Chris Seaton <chris.seaton at oracle.com>
>> wrote:
>> > Maybe this is something to do with the `dim<-` method? I don’t know
>> anything about R but I guess that’s called when you do `names(something)
>> =`. Can you try making a simple test case that just tests that these kind
>> of methods can be called correctly? Maybe something about it messes up the
>> arguments?
>> >
>> > Chris
>> >
>> >> On 6 Jul 2018, at 17:41, Rodrigo Botafogo <
>> rodrigo.a.botafogo at gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I'm trying to set attributes to an r object using interop. For some
>> attributes everything works fine and for others the attribute is not set.
>> >>
>> >> Here what I'm trying in R:
>> >>
>> >> R.eval(<<-R)
>> >> vect = c(1, 2, 3, 4, 5, 6);
>> >> names(vect) = c("a", "b", "c", "d", "e", "f");
>> >> print(vect);
>> >> dim(vect) = c(3, 2);
>> >> print(vect)
>> >> R
>> >>
>> >> The first print show the names set:
>> >>
>> >> a b c d e f
>> >> 1 2 3 4 5 6
>> >>
>> >> and the second print shows the dimension change. Changing the "dim"
>> >> attribute erases the names attribute:
>> >> [,1] [,2]
>> >> [1,] 1 4
>> >> [2,] 2 5
>> >> [3,] 3 6
>> >>
>> >> Now, doing this using interop:
>> >>
>> >> # pp to allow printing: already reported bug
>> >> pp = Polyglot.eval("R", "function(x) print(x)")
>> >>
>> >> vec = Polyglot.eval("R", "c").call(1, 2, 3, 4, 5, 6)
>> >> nams = Polyglot.eval("R", "c").call("a", "b", "c", "d", "e", "f")
>> >> Polyglot.eval("R", "`names<-`").call(vec, nams)
>> >> pp.call(vec)
>> >>
>> >> this prints as expected the vector with the names attribute:
>> >>
>> >> a b c d e f
>> >> 1 2 3 4 5 6
>> >>
>> >> dims = Polyglot.eval("R", "c").call(3, 2)
>> >> Polyglot.eval("R", "`dim<-`").call(vec, dims)
>> >> pp.call(vec)
>> >>
>> >> a b c d e f
>> >> 1 2 3 4 5 6
>> >>
>> >> method dim<- does not seem to have worked. There is no error message
>> or anything after calling `dim<-`
>> >>
>> >> Is this a bug or did I do something wrong here? Its strange that some
>> attributes work and others don't.
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Rodrigo Botafogo
>> >>
>> >> _______________________________________________
>> >> GraalVM-Users mailing list
>> >> GraalVM-Users at oss.oracle.com
>> >> https://oss.oracle.com/mailman/listinfo/graalvm-users
>> >
>> >
>> > _______________________________________________
>> > GraalVM-Users mailing list
>> > GraalVM-Users at oss.oracle.com
>> > https://oss.oracle.com/mailman/listinfo/graalvm-users
>>
>
>
> --
> Rodrigo Botafogo
> Integrando TI ao seu negócio
> 21-3010-4802/11-3010-1802
> _______________________________________________
> GraalVM-Users mailing list
> GraalVM-Users at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/graalvm-users
>
>
>
--
Rodrigo Botafogo
Integrando TI ao seu negócio
21-3010-4802/11-3010-1802
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/graalvm-users/attachments/20180709/429ae219/attachment.html
More information about the GraalVM-Users
mailing list