gpt4 book ai didi

r - 使用包中的单个函数

转载 作者:行者123 更新时间:2023-12-04 16:59:06 25 4
gpt4 key购买 nike

使用卸载包中的单个函数

随着时间的流逝,我发现自己在 R session 开始时加载了越来越多的包。只是加载 tidyverse 加载的包比我以前的标准要多。正因为如此,我发现自己越来越容易受到函数名冲突的影响。特别是当我在包加载过程中没有注意到这些冲突时,这些冲突会产生令人困惑的结果和奇怪的错误。所以我想知道我是否可以,一般来说,只导入我想要使用的特定函数,而不加载它来自的包。

更准确地说,如果 this_pack是本地安装但未加载的包,this_fn()是 this_pack 中的一个导出函数,我可以放心地期待 this_pack::this_fn()工作,并以与加载整个包时相同的方式工作?我知道它通常会发生,但我想知道是否有时我应该期望它会失败。

有关其他信息,请参阅相关问题的答案:

  • Is it a good practice to call functions in a package via ::
  • Load a package apart from one function

  • 我已经接受了 user2554330 的答案,我认为这不是对所引用的其他问题的答案。尽管如此,它们还是提供了有关使用或不使用::的其他原因的有趣且相关的信息,因此我认为保留交叉引用可能是一个好主意。我已经在上面合并了它们。

    最佳答案

    是的,现在调用 this_pack::this_fn() 应该是安全的。 .如 this_pack未加载,这将加载它(全部)。 (记住加载和附加包是不同的!加载它在内存中,但不在搜索列表中。附加它会将它放在搜索列表中。)这可能会使第一次调用有点慢,但包会保留加载,因此后续调用会更快。曾经是评估::的情况在每次调用中花费了大量时间,但我认为即时编译基本上消除了这一点。但是如果你愿意,你可以使用

    local_copy <- this_pack::this_fn

    然后调用 local_copy()无需支付 ::再次查找。

    因为所有的包都有命名空间,任何由 this_pack::this_fn() 发起的调用(或 local_copy() )会去正确的地方,除非包的作者真的很努力地试图颠覆正常的机制。

    如果您自己编写包,则可以只导入该函数。这意味着加载你的包将触发 this_pack 的加载。 : 所以你的加载会慢一点,但是第一次调用 this_fn()会更快。

    关于r - 使用包中的单个函数,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/54278297/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com