blocks|key|768067|text|你的问题中已经包含了部分答案:如果可以预期列(变量)具有不同的类型(数字/字符/逻辑等)，则使用数据框。矩阵用于相同类型的数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|768068|因此，只有当您有相同类型的数据时，选择矩阵/data.frame才会有问题。|768069|答案取决于您将如何处理data.frame/matrix中的数据。如果要将其传递给其他函数，则这些函数的参数的预期类型决定了选择。|768070|另外：|768071|矩阵的内存效率更高：|768072|m+=+matrix(1:4,+2,+2)
d+=+as.data.frame(m)
object.size(m)
#+216+bytes
object.size(d)
#+792+bytes|code-block|syntax|javascript|768073|如果您计划执行任何线性代数类型的运算，矩阵都是必需的。|768074|如果您经常通过名称引用数据框的列(通过紧凑的$运算符)，则会更方便。|768075|数据框还可以更好地报告(打印)表格信息，因为您可以对每一列单独应用格式。|768076|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|11|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Part of the answer is contained already in your question: You use data frames if columns (variables) can be expected to be of different types (numeric/character/logical etc.). Matrices are for data of the same type. 

Consequently, the choice matrix/data.frame is only problematic if you have data of the same type.

The answer depends on what you are going to do with the data in data.frame/matrix. If it is going to be passed to other functions then the expected type of the arguments of these functions determine the choice.

Also:

Matrices are more memory efficient:

<pre><code>m = matrix(1:4, 2, 2)
d = as.data.frame(m)
object.size(m)
# 216 bytes
object.size(d)
# 792 bytes
</code></pre>

Matrices are a necessity if you plan to do any linear algebra-type of operations.

Data frames are more convenient if you frequently refer to its columns by name (via the compact $ operator).

Data frames are also IMHO better for reporting (printing) tabular information as you can apply formatting to each column separately.

blocks|key|983220|text|@Michal没有提到的一件事是，使用矩阵不仅比等效的数据帧小，而且使用矩阵可以使您的代码比使用数据帧更有效率，而且通常是相当高的。这就是为什么在内部，许多R函数会强制转换为数据帧中的矩阵数据的原因之一。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|983221|数据帧通常要方便得多；并不总是只有原子数据块。|983222|请注意，您可以有一个字符矩阵；在R中构建矩阵不一定要有数字数据。|983223|在将数据帧转换为矩阵时，请注意有一个data.matrix()函数，该函数通过将因子转换为基于内部级别的数值来适当地处理因子。如果任何因子标签不是数字，则通过as.matrix()进行强制将产生字符矩阵。比较：|offset|length|style|CODE|983224|>+head(as.matrix(data.frame(a+=+factor(letters),+B+=+factor(LETTERS))))
+++++a+++B++
[1,]+"a"+"A"
[2,]+"b"+"B"
[3,]+"c"+"C"
[4,]+"d"+"D"
[5,]+"e"+"E"
[6,]+"f"+"F"
>+head(data.matrix(data.frame(a+=+factor(letters),+B+=+factor(LETTERS))))
+++++a+B
[1,]+1+1
[2,]+2+2
[3,]+3+3
[4,]+4+4
[5,]+5+5
[6,]+6+6|code-block|syntax|javascript|983225|我几乎总是使用数据框架来执行数据分析任务，因为我的数据分析任务通常不仅仅是数字变量。当我为包编写函数时，我几乎总是强制转换为矩阵，然后将结果格式化为数据帧。这是因为数据帧很方便。|983226|entityMap^0|0|0|0|I|D|27|B|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@$H|Y|I|Z|J|K]|$H|10|I|11|J|K]]|9|@]|A|$]]|$1|L|3|M|5|N|7|12|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

Something not mentioned by @Michal is that not only is a matrix smaller than the equivalent data frame, using matrices can make your code far more efficient than using data frames, often considerably so. That is one reason why internally, a lot of R functions will coerce to matrices data that are in data frames.

Data frames are often far more convenient; one doesn't always have solely atomic chunks of data lying around.

Note that you can have a character matrix; you don't just have to have numeric data to build a matrix in R.

In converting a data frame to a matrix, note that there is a <code>data.matrix()</code> function, which handles factors appropriately by converting them to numeric values based on the internal levels. Coercing via <code>as.matrix()</code> will result in a character matrix if any of the factor labels is non-numeric. Compare:

<pre><code>&gt; head(as.matrix(data.frame(a = factor(letters), B = factor(LETTERS))))
 a B 
[1,] "a" "A"
[2,] "b" "B"
[3,] "c" "C"
[4,] "d" "D"
[5,] "e" "E"
[6,] "f" "F"
&gt; head(data.matrix(data.frame(a = factor(letters), B = factor(LETTERS))))
 a B
[1,] 1 1
[2,] 2 2
[3,] 3 3
[4,] 4 4
[5,] 5 5
[6,] 6 6
</code></pre>

I nearly always use a data frame for my data analysis tasks as I often have more than just numeric variables. When I code functions for packages, I almost always coerce to matrix and then format the results back out as a data frame. This is because data frames are convenient.

blocks|key|768157|text|矩阵实际上是一个带有附加方法的向量。而data.frame是一个列表。区别在于向量和列表。为了提高计算效率，请坚持使用矩阵。如果有必要，可以使用data.frame。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|768158|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The matrix is actually a vector with additional methods. while data.frame is a list.
The difference is down to vector vs list. for computation efficiency, stick with matrix. Using data.frame if you have to.

blocks|key|983286|text|@Michal:矩阵并没有真正提高内存效率：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|983287|m+<-+matrix(1:400000,+200000,+2)
d+<-+data.frame(m)
object.size(m)
#+1600200+bytes
object.size(d)
#+1600776+bytes|code-block|syntax|javascript|983288|..。除非您有大量的列：|983289|m+<-+matrix(1:400000,+2,+200000)
d+<-+data.frame(m)
object.size(m)
#+1600200+bytes
object.size(d)
#+22400568+bytes|983290|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

@Michal: Matrices aren't really more memory efficient:

<pre><code>m &lt;- matrix(1:400000, 200000, 2)
d &lt;- data.frame(m)
object.size(m)
# 1600200 bytes
object.size(d)
# 1600776 bytes
</code></pre>

... unless you have a large number of columns:

<pre><code>m &lt;- matrix(1:400000, 2, 200000)
d &lt;- data.frame(m)
object.size(m)
# 1600200 bytes
object.size(d)
# 22400568 bytes
</code></pre>

blocks|key|768322|text|我再强调不过两者之间的效率差异了！虽然DFs在某些特别是数据分析的情况下确实更方便，但它们也允许异类数据，并且有些库只接受它们，除非您为特定任务编写一次性代码，否则这些都是次要的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|768323|让我给你举个例子。有一个函数可以计算MCMC方法的2D路径。基本上，这意味着我们取一个初始点(x，y)，并在每一步迭代一个特定的算法来找到一个新的点(x，y)，以这种方式构建整个路径。该算法涉及到计算一个相当复杂的函数，并在每次迭代中生成一些随机变量，所以当它运行12秒时，我认为考虑到它在每一步做了多少事情，这是很好的。也就是说，该函数收集了构建路径中的所有点以及3列data.frame中目标函数的值。因此，3列并不是那么大，并且步数也超过了合理的10,000+(在这类问题中，长度为1,000,000的路径通常是1,000,000，所以10,000不是什么)。所以，我认为DF10000x3绝对不是问题。使用DF的原因很简单。在调用函数之后，调用ggplot()来绘制结果(x，y)-path。并且ggplot()不接受矩阵。|768324|然后，出于好奇，我决定改变函数，将路径收集到一个矩阵中。幸运的是，DFs和矩阵的语法是相似的，我所做的就是将指定df作为data.frame的代码行改为将其初始化为矩阵的代码行。这里我还需要提到，在初始代码中，DF被初始化为具有最终大小，因此在稍后的函数代码中，只有新值被记录到已经分配的空间中，并且不存在向DF添加新行的开销。这使得比较更加公平，也让我的工作变得更简单，因为我不需要在函数中进一步重写任何东西。从初始分配所需大小的data.frame到相同大小的矩阵，只有一行更改。为了使函数的新版本适用于ggplot()，我将现在返回的矩阵转换为data.frame，以便在ggplot()中使用。|768325|在我重新运行代码后，我不敢相信结果。代码在几秒钟内就能运行！而不是大约12秒。同样，该函数在10,000次迭代期间只对DF+(现在是矩阵)中已分配的空间进行读写操作。这种差异也适用于合理的(或更小的)+10000x3大小。|768326|因此，如果使用DF的唯一原因是为了使其与诸如ggplot()之类的库函数兼容，那么您总是可以在最后时刻将其转换为DF+--只要您觉得方便，就使用矩阵。另一方面，如果有更充分的理由使用DF，例如您使用一些数据分析包，否则需要在矩阵和DFs之间进行常量转换，或者您自己不做任何密集的计算，而只使用标准包(其中许多实际上在内部将DF转换为矩阵，完成自己的工作，然后将结果转换回来--因此它们为您完成了所有效率工作)，或者只做一次工作，这样您就不需要关心DFs，您就不应该担心效率问题。|768327|或者一个不同的更实用的规则:如果你有一个问题，比如在OP中，使用矩阵，所以只有当你没有这样的问题时，你才会使用DFs+(因为你已经知道你必须使用DFs，或者因为你并不真正关心代码是一次性的，等等)。|768328|但一般来说，请始终将这一效率点作为优先事项牢记在心。|768329|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I cannot stress out more the efficiency difference between the two! While it is true that DFs are more convenient in some especially data analysis cases, they also allow heterogeneous data, and some libraries accept them only, these all is really secondary unless you write a one-time code for a specific task. 

Let me give you an example. There was a function that would calculate the 2D path of the MCMC method. Basically, this means we take an initial point (x,y), and iterate a certain algorithm to find a new point (x,y) at each step, constructing this way the whole path. The algorithm involves calculating a quite complex function and the generation of some random variable at each iteration, so when it run for 12 seconds I thought it is fine given how much stuff it does at each step. That being said, the function collected all points in the constructed path together with the value of an objective function in a 3-column data.frame. So, 3 columns is not that large, and the number of steps was also more than reasonable 10,000 (in this kind of problems paths of length 1,000,000 are typical, so 10,000 is nothing). So, I thought a DF 10,000x3 is definitely not an issue. The reason a DF was used is simple. After calling the function, ggplot() was called to draw the resulting (x,y)-path. And ggplot() does not accept a matrix. 

Then, at some point out of curiosity I decided to change the function to collect the path in a matrix. Gladly the syntax of DFs and matrices is similar, all I did was to change the line specifying df as a data.frame to one initializing it as a matrix. Here I need also to mention that in the initial code the DF was initialized to have the final size, so later in the code of the function only new values were recorded into already allocated spaces, and there was no overhead of adding new rows to the DF. This makes the comparison even more fair, and it also made my job simpler as I did not need to rewrite anything further in the function. Just one line change from the initial allocation of a data.frame of the required size to a matrix of the same size. To adapt the new version of the function to ggplot(), I converted the now returned matrix to a data.frame to use in ggplot(). 

After I rerun the code I could not believe the result. The code run in a fraction of a second! Instead of about 12 seconds. And again, the function during the 10,000 iterations only read and wrote values to already allocated spaces in a DF (and now in a matrix). And this difference is also for the reasonable (or rather small) size 10000x3. 

So, if your only reason to use a DF is to make it compatible with a library function such as ggplot(), you can always convert it to a DF at the last moment -- work with matrices as far as you feel convenient. If on the other hand there is a more substantial reason to use a DF, such as you use some data analysis package that would require otherwise constant transforming from matrices to DFs and back, or you do not do any intensive calculations yourself and only use standard packages (many of them actually internally transform a DF to a matrix, do their job, and then transform the result back -- so they do all efficiency work for you), or do a one-time job so you do not care and feel more comfortable with DFs, then you should not worry about efficiency. 

Or a different more practical rule: if you have a question such as in the OP, use matrices, so you would use DFs only when you do not have such a question (because you already know you have to use DFs, or because you do not really care as the code is one-time etc.). 

But in general keep this efficiency point always in mind as a priority.

When should one use a <code>data.frame</code>, and when is it better to use a <code>matrix</code>?

Both keep data in a rectangular format, so sometimes it's unclear.

Are there any general rules of thumb for when to use which data type?

Should I use a data.frame or a matrix?

数据分析

什么时候应该使用data.frame，什么时候使用matrix更好两者都以矩形格式保存数据，因此有时不清楚。对于何时使用哪种数据类型，有什么通用的经验法则吗？

问我应该使用data.frame还是一个矩阵？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我应该使用data.frame还是一个矩阵？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我应该使用data.frame还是一个矩阵？
EN