管理 R 搜索路径 (like postgresql search_path?)

R 的搜索路径是一个层级结构,例如我们可以使用search()查看当前的层级。

> search()
[1] ".GlobalEnv"        "package:stats"     "package:graphics"
[4] "package:grDevices" "package:utils"     "package:datasets"
[7] "package:methods"   "Autoloads"         "package:base" 

说明当前有9个层级,从1开始编号直到9,当然也可以直接使用名字。

例如我们可以使用ls()或objects()看看每个层级的对象:

> ls(1)
[1] "x"
> ls(.GlobalEnv)
[1] "x"
> objects(2)
  [1] "acf"                  "acf2AR"               "add.scope"
  [4] "add1"                 "addmargins"           "aggregate"
  [7] "aggregate.data.frame" "aggregate.ts"         "AIC"
......

现在我们可以创建一个数据框,并使用attach()将数据框绑定到第二个层级,其他层级顺序往后排。

> x <- data.frame(a=1:10,b=100:109,c=101:110)
> x
    a   b   c
1   1 100 101
2   2 101 102
3   3 102 103
4   4 103 104
5   5 104 105
6   6 105 106
7   7 106 107
8   8 107 108
9   9 108 109
10 10 109 110
> attach(x)

现在多了一个搜索路径x

> search()
 [1] ".GlobalEnv"        "x"                 "package:stats"
 [4] "package:graphics"  "package:grDevices" "package:utils"
 [7] "package:datasets"  "package:methods"   "Autoloads"
[10] "package:base"

这个搜索路径的对象有哪些呢?

> ls(x)
[1] "a" "b" "c"
> ls(2)
[1] "a" "b" "c"

正好是数据框x的几个name,是的通过这种方法,可以直接使用数据框的对象,而不需要使用数据框来引用。

> a
 [1]  1  2  3  4  5  6  7  8  9 10
> b
 [1] 100 101 102 103 104 105 106 107 108 109
> c
 [1] 101 102 103 104 105 106 107 108 109 110

这些数据是不会被改变的,例如:

> a <- b
> a
 [1] 100 101 102 103 104 105 106 107 108 109

你看到的这个a是创建在1号搜索路径的,而不是2号搜索路径。

> ls(1)
[1] "a" "x"

所以只要删掉1号搜索路径的a, 又可以查看2号搜索路径的a了。它是没有变化的。

> ls(2)
[1] "a" "b" "c"
> rm(a)
> a
 [1]  1  2  3  4  5  6  7  8  9 10
> ls(1)
[1] "x"

解除数据框的绑定,

> detach(x)
> ls(x)
[1] "a" "b" "c"
> objects(x)
[1] "a" "b" "c"
> search()
[1] ".GlobalEnv"        "package:stats"     "package:graphics"
[4] "package:grDevices" "package:utils"     "package:datasets"
[7] "package:methods"   "Autoloads"         "package:base" 

解除绑定后,无法直接使用数据框中的对象。

> a
Error: object 'a' not found

[参考]

1. http://cran.r-project.org/doc/manuals/r-release/R-intro.html#Lists-and-data-frames

时间: 2024-11-05 17:31:21

管理 R 搜索路径 (like postgresql search_path?)的相关文章

GNU/Linux中动态库的搜索路径的指定方法汇总

动态链接时.执行时搜索路径顺序: 1.编译目标代码时使用-L指定的动态库搜索路径: 2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径: 3.配置文件/etc/ld.so.conf中指定的动态库搜索路径: 4.默认的动态库搜索路径/lib: 5.默认的动态库搜索路径/usr/lib. 以上的3-5步中,不再需要手动地指定动态库搜索路径了, 有一个可以进行配置更新默认的搜索路径的命令: ldconfig ldconfig命令的用途,主要是在默认搜寻目录(/lib和/usr/lib)以及

关于DLL搜索路径顺序的一个问题

DLL的动态链接有两种方法.一种是加载时动态链接(Load_time dynamic linking).Windows搜索要装入的DLL时,按以下顺序:应用程序所在目录→当前目录→Windows SYSTEM目录→Windows目录→PATH环境变量指定的路径.      前天看到这几句,突然设计出一道自认绝妙的笔试题:"如果采用加载时动态链接的方式,Windows搜索要装入的DLL采用怎样的顺序?"这个是基础题,估计你很容易答出(答案就是上面的).呵呵,我还有后着呢:"你是

DLL搜索路径和DLL劫持

DLL搜索路径和DLL劫持   环境:XP SP3 VS2005 作者:magictong         为什么要把DLL搜索路径(DLL ORDER)和DLL劫持(DLL Hajack)拿到一起讲呢?呵呵,其实没啥深意,仅仅是二者有因果关系而已.可以讲正是因为Windows系统下面DLL的搜索路径存在的漏洞才有了后来的一段时间的DLL劫持大肆流行.       最近(其实不是最近,哈,是以前分析过,断断续续的--)简单分析了一个DLL劫持下载者的行为,感觉有必要写点东西说明一下.其实DLL劫

linux gcc 编译时头文件和库文件搜索路径

一.头文件    gcc 在编译时寻找所需要的头文件 :    ※搜寻会从-I开始    ※然后找gcc的环境变量 C_INCLUDE_PATH,CPLUS_INCLUDE_PATH,OBJC_INCLUDE_PATH    ※再找内定目录   /usr/include   /usr/local/include   /usr/lib/gcc-lib/i386-linux/2.95.2/include   /usr/lib/gcc-lib/i386-linux/2.95.2/../../../..

python如何添加模块搜索路径的3个方法

大约有这么几种方法: 1.添加环境变量PYTHONPATH,python会添加此路径下的模块,在.bashrc文件中添加如下类似行: export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/site-packages 2.在site-packages路径下添加一个路径配置文件,文件的扩展名为.pth,内容为要添加的路径即可 3.sys.path.append()函数添加搜索路径,参数值即为要添加的路径. 网上找到另外一篇文章 为Python添

房价网的估价实验:智能搜索路径摸索盈利点

你家的房子值多少钱? 回答这个问题,你不需要花钱请专业的资产评估机构出具报告,也不需要去房产中介一家家询问行情,只要在网上输入小区和门牌号等信息,就能评估出房产当前的市场价. 这正是"房价网"瞄准的生意.这家于 2007年5月成立的网站,通过自主研发的定向搜索以及数据挖掘技术,提供房产估价以及各种市场价格动态走势分析. "经过两年的实验,目前市场反馈的准确率已经达到了85%以上."北极光创投合伙人.阿里巴巴前CTO吴炯告诉记者.作为房价网的天使投资人兼董事长,做搜索

管理Java类路径(UNIX和Mac OS X)

类路径可以连接 Java 运行库和文件系统.它定义编译器和解释器应该在何处查找要加载的 .class 文件.它的基本思想是:文件系统的层次结构反映了 Java 包的层次结构,而类路径则定义了文件系统中的哪个目录可以作为 Java 包层次结构的根. 遗憾的是,通常文件系统非常复杂并依赖于平台,而且和 Java 包也不能很好地匹配.这样一来,不论是新用户还是资深 Java 程序员都深感类路径的棘手.没错,它的确不是 Java 平台好的一面,它让您到了下班的时候还在忙于调试一个顽固的小问题. 当然采用

管理Java类路径(Windows)

类路径可以连接 Java 运行库和文件系统.它定义编译器和解释器应该在何处查找要加载的 .class 文件.它的基本思想是:文件系统的层次结构反映了 Java 包的层次结构,而类路径则定义了文件系统中的哪个目录可以作为 Java 包层次结构的根. 遗憾的是,通常文件系统非常复杂并依赖于平台,而且和 Java 包也不能很好地匹配.尤其是在 Windows 环境中更是如此.Java 是一些 Unix 高手设计的,因而从很多方面来说,这也就意味着它无法很好地与 Windows 约定同步.这样一来,不论

Windows用来定位DLL的搜索路径

  <程序员面试宝典>一书中写到,windows搜索dll文件的顺序为:(1)内存(2)knowndlls(3)清单与.local(4)应用程序目录(5)当前工作目录(6)系统目录(7)路径变量 总觉得不太明白,遂查资料确认一下. 查msdn如下:http://msdn.microsoft.com/zh-cn/library/7d83bc18.aspx 通过隐式和显式链接,Windows 首先搜索"已知 DLL",如 Kernel32.dll 和 User32.dll.Wi