gpt4 book ai didi

data-structures - 函数的哈希码在原子内部发生变化......为什么会发生这种情况?

转载 作者:行者123 更新时间:2023-12-04 11:19:59 24 4
gpt4 key购买 nike

作为我正在开发的数据可视化应用程序的一部分,我遇到了一些奇怪的错误,或者我根本不理解某些东西。

我的应用程序的代码采用表示色阶的数据结构,并将它们转换为采用数字并返回颜色 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}

也有在两者之间转换的函数,但这是与我的帖子相关的函数:
(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 <= < >= >

这是我的问题所在:

出于某种原因,大多数情况下,当我运行此函数时,它不会给我任何问题,并且对适当不等式运算符的测试按原样运行:
(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"]

由于 set 包含显然是基于它们的哈希码测试函数,这会导致我的“验证范围颜色标度”测试失败。

所以问题是,为什么我的不等式函数的哈希码在原子更新期间会发生变化?它是 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"

有一个图形色阶编辑器,它使用一系列 watch 在更新事件配置之前编辑临时副本。它是通过单击色阶预览图像启动的:
  (.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(在 #'inav/more 中的 let-block 内部) -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"

关于此行为的最后说明:

当您从应用按钮操作监听器的 INSIDE 调用“重绘功能”时,验证范围色标的尝试成功。

当您之后从应用按钮操作监听器的外部调用“重绘功能”时,验证范围色标的尝试失败。

...我刚刚发现了问题,我正在重新评估色阶,作为刷新色阶时调用的重新验证函数的一部分。这是把事情搞砸了。

最佳答案

Clojure 中的函数是实现 clojure.lang.IFn 的常规 Java 对象。界面。当您加载一个命名空间(包括 clojure.core )时,Clojure 将编译函数(生成一个新的 Java 类,创建它的一个实例,并将该实例分配为一个 var 值)。例如,#'clojure.core/< var 将获得一个新的 Java 对象实现 clojure.lang.IFn这恰好是小于逻辑的。

Clojure 不会覆盖 hashCode生成的函数类中的实现,因此从 java.lang.Object 继承了默认的一个.因此,每个新实例都有自己可能不同的哈希码。这会导致您的问题:当命名空间被重新加载时,vars 将获得新的函数实例,从而获得不同的哈希码。

另一方面,我会检查你的测试是如何工作的:

  • 在测试执行期间是否重新加载了任何命名空间?
  • 您是否存储全局状态(例如 < 全局原子中的函数)
    在测试功能范围之外?

  • 也许您应该在测试函数中使用本地范围作为预期值?

    关于data-structures - 函数的哈希码在原子内部发生变化......为什么会发生这种情况?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44291920/

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