RList


represents an internal form of an R list in RLink.

DetailsDetails

  • The elements elems can be of any valid RLink object type.
  • attributes must have the form RAttributes["name1":>value1,...], where values of attributes can be any R objects handled by RLink.

ExamplesExamplesopen allclose all

Basic Examples  (9)Basic Examples  (9)

In[1]:=
Click for copyable input

Like with RVector, most of the time, you will find it more convenient to use the short form of a list, rather than using directly. For example, a pair of an integer and a real number can be represented simply as:

In[1]:=
Click for copyable input
Out[1]=

Yo can use ToRForm to see the internal form of this list, which would involve :

In[2]:=
Click for copyable input
Out[2]=

One reason to use the head explicitly is when you want to treat some data as a list, which the automatic type detection of RLink would otherwise classify as a vector. For example, consider the following nested list:

In[1]:=
Click for copyable input
Out[1]=

It will be considered as a vector by default:

In[2]:=
Click for copyable input
Out[2]=

To force the list interpretation, you can use the following instead:

In[1]:=
Click for copyable input
Out[1]=

It is now interpreted as a list:

In[2]:=
Click for copyable input
Out[2]=

The same will also happen for a flattened list of data:

In[3]:=
Click for copyable input
Out[3]=

The confusion can only happen for lists representing regular arrays. Ragged lists are always interpreted as R lists:

In[1]:=
Click for copyable input
Out[1]=

You can always check yourself with FromRForm function: the call to ToRForm followed by the call to FromRForm should produce back the short form of your input:

In[2]:=
Click for copyable input
Out[2]=

As with RVector, you can send instances of directly to R:

In[1]:=
Click for copyable input
Out[1]=

You can always check what was sent to R by using REvaluate:

In[2]:=
Click for copyable input
Out[2]=

Also, as with RVector, the case when you assign some extra attributes is treated differently. Consider the following example:

In[3]:=
Click for copyable input
Out[3]=

The short (involving only lists) form of the Wolfram Language representation of your R object is no longer possible, since you have to store the attributes somewhere:

In[4]:=
Click for copyable input
Out[4]=

Note that the same ambiguity can happen here as well:

In[5]:=
Click for copyable input
Out[5]=

As you can see, lists were interpreted as vectors here. Here is the form that will force the list interpretation in this case:

In[1]:=
Click for copyable input
Out[1]=

Now the lists will be interpreted as R lists rather than R vectors:

In[2]:=
Click for copyable input
Out[2]=

Here is an example of a more complex list:

In[1]:=
Click for copyable input
Out[1]=

You can see that generally, it is a lot easier to work with the above short form than with a full internal form:

In[2]:=
Click for copyable input
Out[2]=

Either form can be sent to R:

In[3]:=
Click for copyable input
Out[3]=
In[4]:=
Click for copyable input
Out[4]//Short=

You can check that they are the same in R:

In[5]:=
Click for copyable input
Out[5]=

Which, of course, means that they are the same when pulled back to the Wolfram Language:

In[6]:=
Click for copyable input
Out[6]=

This is a bit tangential to the present discussion, but there are two types of indexing possible for lists in R. Here is an example of the one with the same syntax as array indexing:

In[1]:=
Click for copyable input
Out[1]=

It provides an R list with a given element. The other one is the one with the double square bracket syntax, and it truly extracts the element:

In[2]:=
Click for copyable input
Out[2]=

This is reflected on the Wolfram Language side by the first result being wrapped in an extra List. This is also consistent with the conversion to the internal RLink form:

In[3]:=
Click for copyable input
Out[3]=
In[4]:=
Click for copyable input
Out[4]=

You should keep this difference in mind when working with R lists in RLink.