函数哈希码在原子内部发生变化......为什么会这样?
Hashcode of function changing inside atom...why is this happening?
作为我正在开发的数据可视化应用程序的一部分,我遇到了一些奇怪的错误或者我根本不理解的东西。
我的应用程序的代码采用表示色阶的数据结构,并将它们转换为采用数字和 return 颜色 RGB 值的散列的函数。
渐变色标和范围色标均已实现:
{:type :gradient
:scale [{:bound 0 :r 0 :g 0 :b 0}
{:bound 1 :r 255 :g 0 :b 0}
{:bound 2 :r 0 :g 255 :b 0}]}
{:type :range
:scale [{:bound [[< 0]] :r 250 :g 250 :b 250}
{:bound [[>= 0] [< 1]] :r 0 :g 0 :b 0}
{:bound [[>= 1] [< 2]] :r 255 :g 0 :b 0}
{:bound [[>= 2]] :r 0 :g 255 :b 0}}]
有将这些转化为函数的函数,其用法类似于:
((create-colorscale-fn **GRADIENT-MAP**) 1.5) => {:r 128 :g 128 :b 0}
((create-colorscale-fn **RANGE-MAP**) 1.5) => {:r 255 :g 0 :b 0}
也有一些函数可以在两者之间进行转换,但这个是与我相关的 post:
(defn- gradient-colorscale-to-range
[in]
{:pre [(verify-gradient-colorscale in)]
:post [(verify-range-colorscale %)]}
{:type :range
:scale (into []
(concat
(let [{:keys [bound]} (-> in :scale first)
{:keys [r g b]} {:r 250 :g 250 :b 250}]
[{:bound [[< bound]] :r r :g g :b b}])
(mapv (fn [[a {:keys [r g b]}]] {:bound a :r r :g g :b b})
(partition 2 (interleave
(map (partial apply vector)
(partition 2
(interleave
(map #(vector >= (:bound %)) (-> in :scale))
(map #(vector < (:bound %)) (-> in :scale rest)))))
(-> in :scale))))
(let [{:keys [bound r g b]} (-> in :scale last)]
[{:bound [[>= bound]] :r r :g g :b b}])))})
"verify-range-colorscale" 函数的一部分测试有关不等式运算符的以下条件:
(every? #{< <= > >=} (map first (mapcat #(-> % :bound) (:scale in))))
;;Each bound must consist of either <= < >= >
这是我的问题所在:
出于某种原因,大多数时候,当我 运行 这个函数时,它不会给我任何问题,并且测试适当的不等式运算符 运行s 应该:
(def gradient
{:type :gradient
:scale [{:bound 0 :r 0 :g 0 :b 0}
{:bound 1 :r 255 :g 0 :b 0}
{:bound 2 :r 0 :g 255 :b 0}]})
(#{< <= > >=} (get-in (gradient-colorscale-to-range gradient) [:scale 0:bound 0 0]))
=> #object[clojure.core$_LT 0x550b46f1 "clojure.core$_LT_@550b46f1
但是,色标是在一个原子中设置的,其内容在一个全局变量中。我开发了一些编辑器,可以将色标状态的一部分复制到另一个原子中,然后使用图形编辑器对其进行编辑。当我将梯度转换为原子内部的范围时,将原子的内容关联到全局原子中,然后检查运算符的相等性,由于某些奇怪的原因,测试失败了。
(#{< <= > >=} (get-in (gradient-colorscale-to-range gradient) [:scale 0:bound 0 0]))
=> nil
当我检查失败的原因时,似乎小于函数的哈希码在原子更新期间的某个时刻发生了变化。
(mapv #(format "%x" (.hashCode %)) [< (get-in @xmrg-cache [[0 0] :colorscale :scale 0 :bound 0 0])])
-> ["550b46f1" "74688dde"]
并且由于集合包含显然是根据哈希码测试函数,这导致我的 "verify-range-colorscale" 测试失败。
那么问题来了,为什么我的不等式函数的哈希码在原子更新期间会发生变化?它是在 clojure.core 中定义的一个函数,但似乎在某个时候正在制作它的副本?
编辑以回应 Piotrek:
数据结构存储在命名空间 "inav" 中的全局原子中。
加载 <:
的哈希码时
(format "%x" (.hashCode <)) => "425b1f8f"
当使用转换函数从 repl 更改存储在显示配置原子中的色标时:
(swap! xmrg-cache update-in [[0 0] :colorscale gradient-colorscale-to-range)
(format "%x" (.hashCode (get-in @xmrg-cache [[0 0] :colorscale :scale 0 :bound 0 0]))) => "425b1f8f"
有一个图形色标编辑器,它使用一系列手表在更新活动配置之前编辑临时副本。它是通过单击色标预览图像启动的:
(.addMouseListener colorscale-img-lbl
(proxy [MouseAdapter] []
(mouseClicked [me]
(let [cscale-atom (atom (get-in @xmrg-cache [(find-pane-xy e) :colorscale]))]
(add-watch cscale-atom :aoeu
(fn [k v os ns]
(swap! xmrg-cache assoc-in [(find-pane-xy parent-e) :colorscale] ns)
(redrawing-function)))
(launch-colorscale-editor cscale-atom other-irrelevant-args))))
然后 launch-colorscale-editor 有一堆选项,但相关部分是转换组合框和应用按钮:
(defn- launch-colorscale-editor [cscale-atom & other-irrelevant-args]
(let [tmp-cscale-atom (atom @cscale-atom)
convert-cb (doto (JComboBox. (to-array ["Gradient" "Range"]))
(.setSelectedItem ({:range "Range" :gradient "Gradient"} (:type @tmp-cscale-atom)))
apply-button (JButton. "Apply")]
(add-action-listener convert-cb
(fn [] (let [prev-type (:type @tmp-cscale-atom)
new-type ({"Gradient" :gradient "Range" :range} (.getSelectedItem convert-cb))]
(when (not= prev-type new-type)
(case [prev-type new-type]
[:gradient :range] (swap! tmp-cscale-atom gradient-colorscale-to-range)
;other options blah blah
)))))
(add-action-listener apply-button
(fn [] (reset! cscale-atom @tmp-cscale-atom)
(redrawing-function))))
基本上,当您点击应用时,您是在将 tmp-cscale-atom(#'inav/create-colorscale-editor 内)的内容复制到 cscale-atom(#' 中的 let-block 内) inav/more-grid-options-dialog),这会触发一个手表,该手表会自动将色标从 cscale-atom 复制到 xmrg-cache(全局定义的#'inav/xmrg-cache)。
以这种方式编辑时,< 的哈希码最终变成了这个
(format "%x" (.hashCode (get-in @xmrg-cache [[0 0] :colorscale :scale 0 :bound 0 0]))) => "5c370bd0"
关于此行为的最后说明:
当您从应用按钮动作侦听器的内部调用 "redrawing-function" 时,验证范围色标的尝试成功。
当您随后从应用按钮操作侦听器外部调用 "redrawing-function" 时,验证范围色标的尝试失败。
...我刚刚发现了问题,我正在重新评估色标,作为我刷新色标时调用的重新验证函数的一部分。这把事情搞砸了。
我已经能够通过显式重新加载 clojure.core
并观察函数的哈希码在重新加载命名空间时发生变化,尽管包含该函数的 var 的哈希码clojure.core
时不变。
user> (.hashCode <)
87529528
;; jump to clojure.core and reload namespace
user> (.hashCode <)
228405583
user> (.hashCode #'<)
1242688388
;; jump to clojure.core and reload namespace
user> (.hashCode #'<)
1242688388
我不能用你那里的代码告诉你在你的编辑过程中发生了什么可能导致这些表格被重新评估所以可能还有其他原因。一种解决方法可能是将包含测试函数的 var 存储在映射中,而不是直接存储函数对象。您可以使用 #'
reader-宏来执行此操作。
将 var 作为函数调用会自动调用 var 中的函数,因此不需要在其他地方进行任何更改。
Clojure 中的函数是实现 clojure.lang.IFn
接口的常规 Java 对象。当您加载命名空间(包括 clojure.core
)时,Clojure 将编译函数(生成一个新的 Java class,创建它的实例,并将该实例分配为 var 值)。例如,#'clojure.core/<
var 将获得一个新的 Java 对象实现 clojure.lang.IFn
恰好是小于逻辑。
Clojure 不会覆盖生成函数 class 中的 hashCode
实现,因此它继承了 java.lang.Object
的默认实现。因此,每个新实例都有自己可能不同的哈希码。这导致了您的问题:重新加载名称空间时,vars 将获得新的函数实例,从而获得不同的哈希码。
另一方面,我会检查你的测试是如何工作的:
- 在您的测试执行期间是否重新加载了任何命名空间?
- 您是否存储全局状态(例如
<
全局原子中的函数)
在测试功能范围之外?
也许您应该在测试函数中使用局部作用域作为预期值?
巧合的是,就在上周,我注意到了一个相关的行为。当您定义相同的函数时,它们不会获得相同的哈希码:
(defn ink [x] (+ 1 x))
(spyx (hash ink))
(spyx ink)
(defn ink [x] (+ 1 x))
(spyx (hash ink))
(spyx ink)
(hash ink) => 539734147
ink => #object[tst.clj.core$ink 0x202bb083 "tst.clj.core$ink@202bb083"]
(hash ink) => 757183584
ink => #object[tst.clj.core$ink 0x2d21b460 "tst.clj.core$ink@2d21b460"]
所以每个 defn
都在生成一个带有新散列码的新函数对象(实际上函数对象标签 0x202bb083
只是散列 539734147
的十六进制值)。此行为与创建两个单独的 java Object
实例时看到的行为相同:
(hash (Object.)) => 1706817395
(hash (Object.)) => 969679245
回想一下 Object.hashcode()
的默认实现是简单地从对象的内存地址导出一个整数。
所以结果是我们无法比较函数对象的相等性,即使它们是相同的。因此,我们需要一种解决方法,将令牌存储为映射键,并将函数实例存储为相应的映射值。这是一种方法:
(defn ink [x] (+ 1 x))
(defn dek [x] (- x 1))
(def sym->fn {'++ ink
'-- dek})
(defn runner [form]
(let [[fn-symbol val] form
fn-impl (get sym->fn fn-symbol)
result (fn-impl val)]
result))
(runner '(++ 2)) => 3
(runner '(-- 5)) => 4
作为我正在开发的数据可视化应用程序的一部分,我遇到了一些奇怪的错误或者我根本不理解的东西。
我的应用程序的代码采用表示色阶的数据结构,并将它们转换为采用数字和 return 颜色 RGB 值的散列的函数。
渐变色标和范围色标均已实现:
{:type :gradient
:scale [{:bound 0 :r 0 :g 0 :b 0}
{:bound 1 :r 255 :g 0 :b 0}
{:bound 2 :r 0 :g 255 :b 0}]}
{:type :range
:scale [{:bound [[< 0]] :r 250 :g 250 :b 250}
{:bound [[>= 0] [< 1]] :r 0 :g 0 :b 0}
{:bound [[>= 1] [< 2]] :r 255 :g 0 :b 0}
{:bound [[>= 2]] :r 0 :g 255 :b 0}}]
有将这些转化为函数的函数,其用法类似于:
((create-colorscale-fn **GRADIENT-MAP**) 1.5) => {:r 128 :g 128 :b 0}
((create-colorscale-fn **RANGE-MAP**) 1.5) => {:r 255 :g 0 :b 0}
也有一些函数可以在两者之间进行转换,但这个是与我相关的 post:
(defn- gradient-colorscale-to-range
[in]
{:pre [(verify-gradient-colorscale in)]
:post [(verify-range-colorscale %)]}
{:type :range
:scale (into []
(concat
(let [{:keys [bound]} (-> in :scale first)
{:keys [r g b]} {:r 250 :g 250 :b 250}]
[{:bound [[< bound]] :r r :g g :b b}])
(mapv (fn [[a {:keys [r g b]}]] {:bound a :r r :g g :b b})
(partition 2 (interleave
(map (partial apply vector)
(partition 2
(interleave
(map #(vector >= (:bound %)) (-> in :scale))
(map #(vector < (:bound %)) (-> in :scale rest)))))
(-> in :scale))))
(let [{:keys [bound r g b]} (-> in :scale last)]
[{:bound [[>= bound]] :r r :g g :b b}])))})
"verify-range-colorscale" 函数的一部分测试有关不等式运算符的以下条件:
(every? #{< <= > >=} (map first (mapcat #(-> % :bound) (:scale in))))
;;Each bound must consist of either <= < >= >
这是我的问题所在:
出于某种原因,大多数时候,当我 运行 这个函数时,它不会给我任何问题,并且测试适当的不等式运算符 运行s 应该:
(def gradient
{:type :gradient
:scale [{:bound 0 :r 0 :g 0 :b 0}
{:bound 1 :r 255 :g 0 :b 0}
{:bound 2 :r 0 :g 255 :b 0}]})
(#{< <= > >=} (get-in (gradient-colorscale-to-range gradient) [:scale 0:bound 0 0]))
=> #object[clojure.core$_LT 0x550b46f1 "clojure.core$_LT_@550b46f1
但是,色标是在一个原子中设置的,其内容在一个全局变量中。我开发了一些编辑器,可以将色标状态的一部分复制到另一个原子中,然后使用图形编辑器对其进行编辑。当我将梯度转换为原子内部的范围时,将原子的内容关联到全局原子中,然后检查运算符的相等性,由于某些奇怪的原因,测试失败了。
(#{< <= > >=} (get-in (gradient-colorscale-to-range gradient) [:scale 0:bound 0 0]))
=> nil
当我检查失败的原因时,似乎小于函数的哈希码在原子更新期间的某个时刻发生了变化。
(mapv #(format "%x" (.hashCode %)) [< (get-in @xmrg-cache [[0 0] :colorscale :scale 0 :bound 0 0])])
-> ["550b46f1" "74688dde"]
并且由于集合包含显然是根据哈希码测试函数,这导致我的 "verify-range-colorscale" 测试失败。
那么问题来了,为什么我的不等式函数的哈希码在原子更新期间会发生变化?它是在 clojure.core 中定义的一个函数,但似乎在某个时候正在制作它的副本?
编辑以回应 Piotrek:
数据结构存储在命名空间 "inav" 中的全局原子中。
加载 <:
的哈希码时 (format "%x" (.hashCode <)) => "425b1f8f"
当使用转换函数从 repl 更改存储在显示配置原子中的色标时:
(swap! xmrg-cache update-in [[0 0] :colorscale gradient-colorscale-to-range)
(format "%x" (.hashCode (get-in @xmrg-cache [[0 0] :colorscale :scale 0 :bound 0 0]))) => "425b1f8f"
有一个图形色标编辑器,它使用一系列手表在更新活动配置之前编辑临时副本。它是通过单击色标预览图像启动的:
(.addMouseListener colorscale-img-lbl
(proxy [MouseAdapter] []
(mouseClicked [me]
(let [cscale-atom (atom (get-in @xmrg-cache [(find-pane-xy e) :colorscale]))]
(add-watch cscale-atom :aoeu
(fn [k v os ns]
(swap! xmrg-cache assoc-in [(find-pane-xy parent-e) :colorscale] ns)
(redrawing-function)))
(launch-colorscale-editor cscale-atom other-irrelevant-args))))
然后 launch-colorscale-editor 有一堆选项,但相关部分是转换组合框和应用按钮:
(defn- launch-colorscale-editor [cscale-atom & other-irrelevant-args]
(let [tmp-cscale-atom (atom @cscale-atom)
convert-cb (doto (JComboBox. (to-array ["Gradient" "Range"]))
(.setSelectedItem ({:range "Range" :gradient "Gradient"} (:type @tmp-cscale-atom)))
apply-button (JButton. "Apply")]
(add-action-listener convert-cb
(fn [] (let [prev-type (:type @tmp-cscale-atom)
new-type ({"Gradient" :gradient "Range" :range} (.getSelectedItem convert-cb))]
(when (not= prev-type new-type)
(case [prev-type new-type]
[:gradient :range] (swap! tmp-cscale-atom gradient-colorscale-to-range)
;other options blah blah
)))))
(add-action-listener apply-button
(fn [] (reset! cscale-atom @tmp-cscale-atom)
(redrawing-function))))
基本上,当您点击应用时,您是在将 tmp-cscale-atom(#'inav/create-colorscale-editor 内)的内容复制到 cscale-atom(#' 中的 let-block 内) inav/more-grid-options-dialog),这会触发一个手表,该手表会自动将色标从 cscale-atom 复制到 xmrg-cache(全局定义的#'inav/xmrg-cache)。
以这种方式编辑时,< 的哈希码最终变成了这个
(format "%x" (.hashCode (get-in @xmrg-cache [[0 0] :colorscale :scale 0 :bound 0 0]))) => "5c370bd0"
关于此行为的最后说明:
当您从应用按钮动作侦听器的内部调用 "redrawing-function" 时,验证范围色标的尝试成功。
当您随后从应用按钮操作侦听器外部调用 "redrawing-function" 时,验证范围色标的尝试失败。
...我刚刚发现了问题,我正在重新评估色标,作为我刷新色标时调用的重新验证函数的一部分。这把事情搞砸了。
我已经能够通过显式重新加载 clojure.core
并观察函数的哈希码在重新加载命名空间时发生变化,尽管包含该函数的 var 的哈希码clojure.core
时不变。
user> (.hashCode <)
87529528
;; jump to clojure.core and reload namespace
user> (.hashCode <)
228405583
user> (.hashCode #'<)
1242688388
;; jump to clojure.core and reload namespace
user> (.hashCode #'<)
1242688388
我不能用你那里的代码告诉你在你的编辑过程中发生了什么可能导致这些表格被重新评估所以可能还有其他原因。一种解决方法可能是将包含测试函数的 var 存储在映射中,而不是直接存储函数对象。您可以使用 #'
reader-宏来执行此操作。
将 var 作为函数调用会自动调用 var 中的函数,因此不需要在其他地方进行任何更改。
Clojure 中的函数是实现 clojure.lang.IFn
接口的常规 Java 对象。当您加载命名空间(包括 clojure.core
)时,Clojure 将编译函数(生成一个新的 Java class,创建它的实例,并将该实例分配为 var 值)。例如,#'clojure.core/<
var 将获得一个新的 Java 对象实现 clojure.lang.IFn
恰好是小于逻辑。
Clojure 不会覆盖生成函数 class 中的 hashCode
实现,因此它继承了 java.lang.Object
的默认实现。因此,每个新实例都有自己可能不同的哈希码。这导致了您的问题:重新加载名称空间时,vars 将获得新的函数实例,从而获得不同的哈希码。
另一方面,我会检查你的测试是如何工作的:
- 在您的测试执行期间是否重新加载了任何命名空间?
- 您是否存储全局状态(例如
<
全局原子中的函数) 在测试功能范围之外?
也许您应该在测试函数中使用局部作用域作为预期值?
巧合的是,就在上周,我注意到了一个相关的行为。当您定义相同的函数时,它们不会获得相同的哈希码:
(defn ink [x] (+ 1 x))
(spyx (hash ink))
(spyx ink)
(defn ink [x] (+ 1 x))
(spyx (hash ink))
(spyx ink)
(hash ink) => 539734147
ink => #object[tst.clj.core$ink 0x202bb083 "tst.clj.core$ink@202bb083"]
(hash ink) => 757183584
ink => #object[tst.clj.core$ink 0x2d21b460 "tst.clj.core$ink@2d21b460"]
所以每个 defn
都在生成一个带有新散列码的新函数对象(实际上函数对象标签 0x202bb083
只是散列 539734147
的十六进制值)。此行为与创建两个单独的 java Object
实例时看到的行为相同:
(hash (Object.)) => 1706817395
(hash (Object.)) => 969679245
回想一下 Object.hashcode()
的默认实现是简单地从对象的内存地址导出一个整数。
所以结果是我们无法比较函数对象的相等性,即使它们是相同的。因此,我们需要一种解决方法,将令牌存储为映射键,并将函数实例存储为相应的映射值。这是一种方法:
(defn ink [x] (+ 1 x))
(defn dek [x] (- x 1))
(def sym->fn {'++ ink
'-- dek})
(defn runner [form]
(let [[fn-symbol val] form
fn-impl (get sym->fn fn-symbol)
result (fn-impl val)]
result))
(runner '(++ 2)) => 3
(runner '(-- 5)) => 4