主页 / coding / 问题 / 78990989
Accepted
mysteriarcha
Asked: 2024-09-17 00:19:21 +0800 CST

将对象包含到列表中并对其进行矢量化时，obj_addr() 输出会随机发生变化

  • 772

当列表本身不改变地址时，lobstr::obj_addr 会出现奇怪的行为，这是由于其对列表进行矢量化所致

我刚刚开始学习 Wickham 的《高级 R》（第二版），并完成了 2.2.2 练习的第一个练习。我认为，鉴于：

a <- 1:10; b <- a; c <- b

它们都将具有与lobstr::obj_addr函数检索到的相同的内存地址。如果我们仅使用 a、b 或 c 作为输入，情况确实如此，但由于我很懒，想一次获得所有值，所以我这样做了：

list(a, b, c) |> lapply(obj_addr) # lapply or sapply

然后，每次运行该函数时，我们都会在不同的名称中获得一组不同的值。如果我们x <- list(a, b, c)在调用函数之前通过lapply、 和进行设置，这种情况仍然会发生obj_addr(x[[1]]) == obj_addr(x[[2]]) == obj_addr(x[[3]]) == obj_addr(a)，因此这不是每次都创建新列表的问题。有人知道这是怎么回事吗？我理解，在某个点上，每次调用都会生成一个具有自己内存地址的新输出对象，但我不知道如何lapply干扰给定对象的常量函数，例如obj_addr。

先感谢您！

2 个回答

  1. Best Answer

    这是由如何lobstr识别环境的一个错误引起的

    MrFlick 在评论中指出x |> lapply(function(x) obj_addr(x))返回正确答案，而x |> lapply(obj_addr)返回错误答案。这表明环境中发生了一些奇怪的事情。问题是这是由lobstr::obj_addr()或引起的lapply()。事实证明，这是由于 的lobstr使用方式rlang导致它在错误的环境中寻找对象。

    做什么lobstr::obj_addr()？

    源代码（略微简化）如下：

    obj_addr <- function(x) {
  x <- enquo(x)
  obj_addr_(quo_get_expr(x), quo_get_env(x))
}

    obj_addr_()是用 C 编写的获取内存地址的主力函数。但是，首先 Robj_addr()使用rlang quosure 工具来访问对象而不增加引用计数。这样可以确保没有对该对象的引用，从而允许垃圾收集稍后正常进行。但是，在 的情况下lapply(x, lobstr::obj_addr)，它无法正确访问 元素的环境x，这就是错误出现的地方。

    环境会发生什么变化lapply()？

    考虑以下函数来获取调用函数的对象的环境：

    f <- function(x) {
    rlang::quo_get_env(rlang::enquo(x))
}

    lapply()我们可以通过两种方式调用它：

    x <- list(a = 1, b = 2, c = 3)

lapply(x, \(y) f(y)) # anonymous function
# $a
# <environment: 0x557c265eb438>

# $b
# <environment: 0x557c265ea910>

# $c
# <environment: 0x557c26e275c8>

lapply(x, f) # function provided directly
# $a
# <environment: R_EmptyEnv>

# $b
# <environment: R_EmptyEnv>

# $c
# <environment: R_EmptyEnv>

    第一组结果是有意义的。lapply()每次调用匿名函数（函数闭包）时都会创建一个临时环境。

    但是，在空环境中运行是没有意义的lapply(x, f)。我们知道可以用 引用全局环境中的对象lapply()。但是空环境根据定义不包含任何对象，也没有父级：

    f_parent <- function(x) {
    e <- rlang::quo_get_env(enquo(x))
    message("Objects in environment: ", length(ls(e)))
    message("Parent environment: ", parent.env(e))
}

lapply(x, f_parent)
# Objects in environment: 0
# Error in parent.env(e) : the empty environment has no parent

    所以显然返回了错误的环境。让我们尝试使用 base Rrlang::quo_get_env(rlang::enquo(x))查找调用函数的父环境：lapply()

    f2 <- function(x) {
    parent.env(environment())
}
lapply(x, f2)
# $a
# <environment: R_GlobalEnv>

# $b
# <environment: R_GlobalEnv>

# $c
# <environment: R_GlobalEnv>

    这更有意义，并为我们了解正在发生的事情提供了线索。

    编写自己的函数来获取指针

    为了排除lapply()这种不一致的根源，让我们写出自己的版本，lobstr::obj_addr()它不会弄乱环境。C级函数的相关行obj_addr_()是将转换SEXP为指针的地方：

    static_cast<void *>(x);

    这是一个类似的函数，用于获取跳过内容的指针rlang：

    get_pointer <- inline::cfunction(
    sig = c(x = "integer"),
    body = '
    // cast SEXP to a void pointer like lobstr
    void* ptr = (void*) x;

    // put the pointer in a character array
    char addr_chr[32];
    snprintf(addr_chr, sizeof(addr_chr), "%p", ptr);

    // put address in character vector and return it
    SEXP addr = PROTECT(allocVector(STRSXP, 1));
    SET_STRING_ELT(addr, 0, mkChar(addr_chr));
    UNPROTECT(1);
    return addr;',
    includes = "#include <stdio.h>"
)

    相比get_pointer()​lobstr::obj_addr()

    让我们x分别定义并检查地址：

    x <- list(a = 1, b = 2, c = 3)

lobstr::obj_addr(x[[1]]) # [1] "0x557c22e8eb28"
lobstr::obj_addr(x[[2]]) # [1] "0x557c22e8eb60"
lobstr::obj_addr(x[[3]]) # [1] "0x557c22e8eb98"

    lobstr现在我们可以比较三种方法的结果。我将使用sapply()而不是，lapply()因为它打印得更好。我们可以看到这sapply(x, lobstr::obj_addr)是不正确的。

    lobstr::obj_addrs(x) # correct
# [1] "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

sapply(x, \(y) lobstr::obj_addr(y)) # correct
#                a                b                c
# "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

sapply(x, lobstr::obj_addr) # incorrect
#                a                b                c
# "0x557c24fdd7a0" "0x557c24fdd8f0" "0x557c24fdda78"

    问题是，如果我们跳过环境部分，我们是否能得到正确的结果。我们可以使用get_pointer()：

    sapply(x, \(y) get_pointer(y)) # correct
#                a                b                c 
# "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

sapply(x, get_pointer) # correct
#                a                b                c 
# "0x557c22e8eb28" "0x557c22e8eb60" "0x557c22e8eb98"

    因此get_pointer()两次都得到了正确的结果。这表明问题出在lobstrrlang quosure 工具的使用上。我实际上不确定这是否是个rlang问题，或者问题是否出在 如何lobstr使用 上。但是，由于这两个包都是r-librlang的一部分，我想提交给其中一个包的错误报告很快就会到达正确的地方。

    • 3

  2. 这种行为似乎是由于在检索其地址之前对参数obj_addr进行了处理（参见函数定义）。因此，我们可以独立于实际的地址检索部分来enquo检查的行为。enquo

    为了检查，我们可以定义一个基于obj_addr检索地址的函数：

    .internal.address = function(.) lobstr:::obj_addr_(rlang::quo_get_expr(.), 
                                                   rlang::quo_get_env(.))

    作为参考，该对象a位于：

    .Internal(inspect(a))
#@58398aa88108 13 INTSXP g1c0 [MARK,REF(65535)]  1 : 10 (expanded)

    当位于闭包主体之外时，enquo返回一些无用的东西以检索对象的地址，因为enquo似乎能够完全评估一个符号（例如与之相反substitute）并返回一个新构造的对象：

    enquo(a)
#<quosure>
#expr: ^<int: 1L, 2L, 3L, 4L, 5L, ...>
#env:  empty
.internal.address(enquo(a))
#[1] "0x5839a29c0018"
.internal.address(enquo(a))
#[1] "0x5839a29c0088"

    然而，在闭包内部，一切都按预期进行：

    f1 = function(x) enquo(x)
f1(a)
#<quosure>
#expr: ^a
#env:  global
.internal.address(f1(a))
#[1] "0x58398aa88108"
.internal.address(f1(a))
#[1] "0x58398aa88108"

    lapply在构造调用期间评估其参数，并且，我们可能可以使用以下方式模拟其行为force（以使其更清楚）：

    force1 = function(x) { force(x); enquo(x)}
force1(a)
#<quosure>
#expr: ^<int: 1L, 2L, 3L, 4L, 5L, ...>
#env:  empty
.internal.address(force1(a))
#[1] "0x5839a2816848"
.internal.address(force1(a))
#[1] "0x5839a2816b58"

    因为enquo不再返回可搜索的符号。

    正如 MrFlick 在评论中指出的那样，用另一层闭包进行包装可以达到预期的效果，因为enquo似乎无法对其论点进行全面的评估：

    force2 = function(y) { force(y); f1(y)}
force2(a)
#<quosure>
#expr: ^y
#env:  0x58399eef63d8
.internal.address(force2(a))
#[1] "0x58398aa88108"

    此外，举个例子，如果我们重新定义obj_addr如下：

    obj_addr2 = function(x) lobstr:::obj_addr_(substitute(x), parent.frame())

    那么lapply就不会造成混淆：

    obj_addr(a)
#[1] "0x58398aa88108"
obj_addr2(a)
#[1] "0x58398aa88108"
lapply(list(a, b), obj_addr)
#[[1]]
#[1] "0x58399a991748"
#
#[[2]]
#[1] "0x58399a9917b8"

lapply(list(a, b), obj_addr2)
#[[1]]
#[1] "0x58398aa88108"
#
#[[2]]
#[1] "0x58398aa88108"
    • 2

相关问题