Netlogo 在 Python 中绘图后暂停，需要关闭绘图才能继续

发布于 2025-01-18 11:53:00 字数 360 浏览 4 评论 0原文

我的代码在python绘制后停止，直到我关闭绘图后才继续。

我正在使用matplotlib进行绘图。

to plot-in-python
  (py:run   
      "import matplotlib.pyplot as plt"
      "time = [0, 1, 2, 3]"
      "position = [0, 100, 200, 300]"
    
      "plt.plot(time, position)"
      "plt.xlabel('Time (hr)')"
      "plt.ylabel('Position (km)')"
      "plt.show()" 
  )
end

原文

My code pauses after plotting in python, and won't continue until I close the plot.

I am using matplotlib for plotting.

to plot-in-python
  (py:run   
      "import matplotlib.pyplot as plt"
      "time = [0, 1, 2, 3]"
      "position = [0, 100, 200, 300]"
    
      "plt.plot(time, position)"
      "plt.xlabel('Time (hr)')"
      "plt.ylabel('Position (km)')"
      "plt.show()" 
  )
end

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

A君 2025-01-25 11:53:00

问：
_{" 我的代码在用 python 绘图后暂停，直到我关闭绘图后才会继续。 "}

答：
结果是一个自然的产物，因为 matplotlib 进入 .show() 方法，该方法会阻塞（直到关闭），并且整个 Python 解释器生态系统都会停止，直到发生这种情况。如果不使用这种“交互式”（Python 阻塞）模式中的绘图，而是将最终生成的图形场景存储到 PDF 或其他格式的文件中，稍后使用非阻塞查看器进行检查，则整个 ( py:run ... )-范围将按预期终止，不会出现“挂起”-Python 阻塞，并且 NetLogo 世界可以进一步继续其演化流程。

问：
_{" 我希望让数字保持不变并随着 Netlogo 的每次循环而更新（这是因为 Netlogo 中的数字不太好）我知道 .ion() 应该创建交互式绘图（即可更新的绘图），但无论出于何种原因它对我不起作用......我尝试在 .这样与 Netlogo 一样吗？ href="https://stackoverflow.com/users/15228682/belief-desire-intent">信念-欲望-intent 2小时前< /a>“}

A：
好吧，我不认为这种拥有实时图表的愿望是愚蠢的。关键是，如何实现这一目标。

70 年代末，帕洛阿尔托研究中心（及其附属机构，如 PARCplace）内部形成的“正偏差岛”中涌现出了许多奇妙的系统）。我们非常感谢这些聪明的人，他们当时受聘为施乐研究机构工作。模块化交互式 GUI、文字处理软件、Smalltalk 语言、计算机鼠标和许多其他发明的概念都是在那里诞生的。

GUI 概念具有许多参与者，其中一些是机器驱动的，其中一些反映了人机交互，例如您希望 NetLogo 生成实时图表，这些图表存在于 Python-matplotlib 外系统中，确实很难进行编程，直到 PARCplace 人员将主要职责分离的系统概念引入 MVC 系统：
其中
M 代表 MODEL：保持状态完整表示的部分的正在审查的问题，
V 代表 VISUAL：生成 PuR 状态的视觉表示的部分，
C 代表 CONTROLLER ：收集人机交互和所有其他“传感器”的部分，基于此，PuR 状态（模型）会连续获得（嗯，以某种离散的时间顺序事件收集和反射处理方式）已更新。

必须先说这一点，以便现在能够声称，您的愿望正在导致所谓的“分布式”形式的 MVC 模型，NetLogo 正在其中做 M- odel 部分，驱动 PuR 状态的多智能体演化，并命令“远程”-GUI-V-isual 部分，并且必须接收输入（如果有的话）从再次“远程”-GUI-C-控制器。

如果我们尝试在一些不太整合的地方实现相同的需求，那么这可能听起来很糟糕，但也不是那么丑陋，如果与混乱相比的话。经过时间考验的时尚。

考虑到 NetLogo 的强大功能，我们可以使用 ( py:run ... )-scope(s) 为此类“分布式”GUI-MVC 系统实际提供所有所需的粘合逻辑。

我们可以
(a) 使用（最好只有一个）非阻塞 ( py:run ... )-scope 注入 NetLogo M-odel 更新，
(b) 在我们的本地主机上保留一个（或多个，如果需要）Python 解释器，甚至在某些远程网络主机上作为 V-isual 处理程序，显示图表（ s) 和
(c) 保留一个（或更多，如果需要）我们的本地主机或远程网络主机上的 Python 解释器作为 C 控制器，反馈另一个 NetLogo 非阻塞 ( py:run ... )-scope(s)，接收“远程”输入（如果需要）以在 NetLogo M-odel 更新循环中使用它们。

无论这听起来多么复杂，它都可以使用任何位于 localhost 的可用 Python 解释器单会话或多 Python 解释器会话，无论它们都是 localhost 并置，甚至网络分布式，使用分布式计算工具，我们可以直接插入，pynng, pyzmq 提供新型智能传输服务，允许其他自治节点设置“宏观规模”分布式 MVC，并顺利地传达所有需要的更改（以消息形式组成）。

如果更专业一点，还有其他 NetLogo 原生工具可以提供更好、更流畅（不太容易出现不稳定的控制循环）的方法来实现“远程”/“分布式”协同集成GUI-s。只是提一下内置的 HubNet 模型，一个轻量级的 Java / Scala-extension 更好 &更顺畅地服务 M-odel 到 V-isual（半持久）-链接（没有 ( py:run ... ) 的缺点-scope(s)' 对 Python 解释器（本地|远程）进程和 IPC 管理的依赖和限制（控制循环延迟 + 抖动可能会令人烦恼，如果 MVC 循环因此失去更多功能）循环的“紧密性”）

远程进程更新 GUI 提示
协同集成 GUI 提示
远程 GUI .mainloop() 控制器提示
控制循环的“紧密性”提示

Q :
_{" My code pauses after plotting in python, and won't continue until I close the plot. "}

A :
The result is a natural product, as the matplotlib enters into a .show()-method, which blocks ( until closed ) and the whole Python Interpreter ecosystem stops until such happens. Without using the plot inside this "interactive"-(Python-blocking) mode and if instead rather storing the final produced graph-scene into a PDF or otherwise formatted file, later inspectable using a non-blocking viewer, the whole ( py:run ... )-scope will terminate as expected, without a "hanging"-Python blocking and the NetLogo-world can continue its evolution-flow further on.

Q :
_{" I was hoping to have the figure remain up and update with each loop of Netlogo (this is because the figures in Netlogo are not great). I understand that .ion() is supposed to create interactive plots (i.e., updatable plots), but for whatever reason it does not work for me... Am I foolish to try and use Python in this way with Netlogo? – belief-desire-intent 2 hours ago "}

A :
Well, I would not consider such a desire to have live-graphs be foolish for a single moment. The key is, how to achieve this to happen.

In late 70-ies, there were wonderful inventions that have sprung out of the "Island of positive deviation" that has evolved inside Palo Alto Research Center (and its spin-offs like PARCplace systems). We owe a lot to these smart people, hired by then to work for this XEROX research facility. Concepts of modular interactive GUI, word-processing software, Smalltalk language, computer mouse and many other inventions took place right there.

The GUI concepts, having many-actors, some of which are machine-driven, some of which are reflecting man-machine interactions, -like your wish to have NetLogo generating live-graphs, that live inside Python-matplotlib exosystem- were indeed hard to program until PARCplace people brought in a methodic concept of principal separation of responsibilities - into an MVC-system :
where
M stands for MODEL: the part, that keeps state-full representation of the Problem-under-Review,
V stands for VISUAL: the part, that generates visual representation of the PuR-state, and
C stands for CONTROLLER: the part, that collects Man-Machine-Interactions and all other "sensors", based on which the PuR-state ( The Model ) gets continuously ( well, in some sort of discrete time-ordered events collecting and reflective-processing manner ) updated.

This had to have been said first, so as to now be able to claim, that your wish is leading to a so called "distributed"-form of the MVC-model, where NetLogo is doing M-odel part, driving the multi-agent evolution of the PuR-state, and commands the "remote"-GUI-V-isual part and has to receive inputs ( if any would be intended to be so ) from the again "remote"-GUI-C-ontroller.

This might sound awful, yet not so ugly, if compared with a mess if we would try to implement the same need in some less consolidated & time-proven fashion.

Given the powers of NetLogo, we can use ( py:run ... )-scope(s) to actually provide all the needed glue-logic for such a "distributed"-GUI-MVC system.

We can
(a) inject NetLogo M-odel updates using (best only one) non-blocking ( py:run ... )-scope,
(b) keep one (or more, if need be) Python Interpreter(s) on our localhost or even on some remote network host(s) as the V-isual handler, showing the graph(s), and
(c) keep one (or more, if need be) Python Interpreter(s) on our localhost or remote network host(s) as the C-ontroller, that feedback(s) another NetLogo non-blocking ( py:run ... )-scope(s), that receive(s) "remote"-inputs (if any needed) to consume them inside the NetLogo M-odel update loops.

No matter how complicated this might sound, it will work, using any of the available localhost located Python Interpreter single-session or multi-Python Interpreter sessions, be them all localhost colocated, or even network-distributed, using distributed-computing tools that we can just plug-in, be it pynng, pyzmq to provide a new breed of smart transport-services to allow otherwise autonomous nodes to setup a "macro-scale" distributed-MVC and communicate smoothly all needed changes, composed as messages.

If going a bit more professional into it, there are also other NetLogo native tools for better and smoother ( less prone to choppy stick-slick-stick-slick control-loop ) ways how to implement "remote"/"distributed" co-integrated GUI-s. Just mentioning a built-in HubNet model, a lightweight Java / Scala-extension to better & smoother serve the M-odel to V-isual (semi-persistent)-links ( without weaknesses of ( py:run ... )-scope(s)' relying on and limitations carrying Python Interpreter (local|remote)-process & IPC management ( control-loop latency + jitter thereof can annoy & matter, if the MVC-loop thus looses more of its "tightness" of loop )