为科学代码选择前端/解释器

发布于 2024-09-08 00:29:58 字数 1155 浏览 9 评论 0原文

我在过去几年中开发的模拟工具是用 C++ 编写的,目前有一个 tcl 解释的前端。它的编写方式是可以在交互式 shell 中运行,也可以通过传递输入文件来运行。无论哪种方式,输入文件都是用 tcl 编写的(我添加了许多附加的特定于模拟的命令)。这允许非常强大的输入文件(例如,当运行蒙特卡罗模拟时,随机分布可以直接在输入文件中编程为 tcl 过程)。

不幸的是,我发现与更现代的解释语言所提供的功能相比,tcl 解释器变得有些有限,而且它的语法似乎有点神秘。由于计算引擎是作为一个具有 C 兼容 API 的库编写的,因此编写替代前端应该很简单,并且我正在考虑转向新的解释器,但是我有一些时间选择(主要是因为我对许多解释语言没有丰富的经验)。我已经开始探索的选项如下:

继续使用 tcl:
优点:
- 无需更改现有代码。
- 现有的输入文件保持不变。 (尽管我可能会保留 tcl 前端作为一个选项)
- 成熟的语言,有大量的社区支持。
缺点:
- 感觉受到语言语法的限制。
- 收到用户关于学习 tcl 困难的投诉。

Python:
优点:
- 现代口译员,众所周知非常高效。
- 大型、活跃的社区。
- 众所周知的科学和数学模块,例如 scipy。
- 常用于学术科学/工程社区(我的代码的典型用户)
缺点:
- 我从未使用过它,因此需要时间来学习该语言(这也是一个专业人士,因为我已经想学习 python 很长一段时间了)
- 输入文件的严格格式(缩进等)

Matlab:
优点:
- 非常强大且广泛使用的数学工具
- 强大的内置可视化/绘图。
- 可扩展,通过社区提交的代码以及商业工具箱。
- 科学/工程学术界的许多人都熟悉并熟悉 matlab。
缺点:
- 无法作为可执行文件分发 - 需要是一个附加组件/工具箱。
- 需要(?)matlab 编译器(价格昂贵)。
- 需要 Matlab,这也很昂贵。

尽管我对解释语言的经验很少,但我已经能够想到这些优点和缺点。我很想听听对我在这里提出的两种解释器的任何想法,如果列出的这些优点/缺点是合法的,以及我没有想到的任何其他解释器(例如,php 适合这样的事情吗? lua ?)。在代码中嵌入解释器的第一手经验绝对是一个优势!

The simulation tool I have developed over the past couple of years, is written in C++ and currently has a tcl interpreted front-end. It was written such that it can be run either in an interactive shell, or by passing an input file. Either way, the input file is written in tcl (with many additional simulation-specific commands I have added). This allows for quite powerful input files (e.g.- when running monte-carlo sims, random distributions can be programmed as tcl procedures directly in the input file).

Unfortunately, I am finding that the tcl interpreter is becoming somewhat limited compared to what more modern interpreted languages have to offer, and its syntax seems a bit arcane. Since the computational engine was written as a library with a c-compatible API, it should be straightforward to write alternative front-ends, and I am thinking of moving to a new interpreter, however I am having a bit of a time choosing (mostly because I don't have significant experience with many interpreted languages). The options I have begun to explore are as follows:

Remaining with tcl:
Pros:
- No need to change the existing code.
- Existing input files stay the same. (though I'd probably keep the tcl front end as an option)
- Mature language with lots of community support.
Cons:
- Feeling limited by the language syntax.
- Getting complaints from users as to the difficulty of learning tcl.

Python:
Pros:
- Modern interpreter, known to be quite efficient.
- Large, active community.
- Well known scientific and mathematical modules, such as scipy.
- Commonly used in the academic Scientific/engineering community (typical users of my code)
Cons:
- I've never used it and thus would take time to learn the language (this is also a pro, as I've been meaning to learn python for quite some time)
- Strict formatting of the input files (indentation, etc..)

Matlab:
Pros:
- Very power and widely used mathematical tool
- Powerful built-in visualization/plotting.
- Extensible, through community submitted code, as well as commercial toolboxes.
- Many in science/engineering academia is familiar with and comfortable with matlab.
Cons:
- Can not distribute as an executable- would need to be an add-on/toolbox.
- Would require (?) the matlab compiler (which is pricy).
- Requires Matlab, which is also pricy.

These pros and cons are what I've been able to come up with, though I have very little experience with interpreted languages in general. I'd love to hear any thoughts on both the interpreters I've proposed here, if these pros/cons listed are legitimate, and any other interpreters I haven't thought of (e.g.- would php be appropriate for something like this? lua?). First hand experience with embedding an interpreter in your code is definitely a plus!

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

人│生佛魔见 2024-09-15 00:29:58

从预发布开始我就是 Tcl/Tk 的坚定支持者,直到我用它做了一个大型项目并发现它是多么难以维护。不幸的是,由于 Tcl 中的原型非常简单,因此您最终会得到“一次性”脚本,它们会自行发挥作用。

在过去的几个月里采用了 Python,我发现它实现了 Tcl 所承诺的一切,而且还有更多。正如许多 Python 资深人士可以告诉您的那样,源代码缩进最多在第一个小时会很麻烦,然后它似乎不再是一个障碍,而是肯定有帮助。顺便说一句,Tcl 的作者 John Ousterhout 因编写了一种强迫 One True 的语言而受到赞扬和批评。 Tcl 编码器上的大括号样式(我是 1TBS,所以对我来说没问题)。

Python 唯一不能很好处理的 Tcl 构造是任意 eval "${prefix}${command} arg" 构造,它们无论如何都不应该在 Tcl 中使用,但是和 uplevel 类型语句(这是一个好主意,但适合一些繁琐的代码)。事实上,Python 感觉有点反对动态 eval,但我认为这是一件好事。不幸的是,我还没有找到一种既支持 GUI 又支持 Tcl/Tk 的语言; Tkinter 在 Python 中完成了这项工作,但它很痛苦。

我根本无法与 Matlab 对话。

有了几个月的 Python 经验,出于理智的目的,我几乎肯定会将任何正在开发的 Tcl 程序移植到 Python。

I was a strong Tcl/Tk proponent from pre-release, until I did a largish project with it and found how unmaintainable it is. Unfortunately, since prototypes are so easy in Tcl, you wind up with "one-off" scripts taking on lives of their own.

Having adopted Python in the last few months, I'm finding it to be all that Tcl promised and a whole lot more. As many a Python veteran can tell you, source indentation is a bother for the first hour at most and then it seems not a hindrance but affirmatively helpful. Incidentally Tcl's author, John Ousterhout was alternately praised and panned for writing a language that forced the One True Brace Style on Tcl coders (I was 1TBS so it was fine by me).

The only Tcl constructs that aren't handled well by Python are arbitrary eval "${prefix}${command} arg" constructs that shouldn't be used in Tcl anyway but are and the uplevel type statements (which were a nice idea but made for some hairy code). Indeed, Python feels a little antagonistic to dynamic eval but I think that is a Good Thing. Unfortunately, I've yet to come along with a language that embraced its GUI as well as Tcl/Tk; Tkinter does the job in Python but it hurts.

I cannot speak to Matlab at all.

With a few months of Python under my belt, I'd almost certainly port any Tcl program that is in ongoing development to Python for purposes of sanity.

过度放纵 2024-09-15 00:29:58

您考虑过使用 Octave 吗?据我所知,它几乎可以直接替代 matlab 的大部分内容。这可能会让您为那些拥有 matlab 的人提供支持,并为那些没有的人提供免费的替代方案。由于程序的“核心”似乎是用另一种语言编写的,因此性能考虑因素似乎并不像提供具有以下功能的环境那么重要:绘图和可视化功能,跨平台,拥有庞大的用户群,并且学术界和/或参与流体流动建模的几乎每个人都可能已经知道这种语言。 Matlab/Octave 可能拥有所有这些。

Have you considered using Octave? From what I gather, it is nearly a drop-in replacement for much of matlab. This might allow you to support matlab for those who have it, and a free alternative for those who don't. Since the "meat" of your program appears to be written in another language, the performance considerations seem to be not as important as providing an environment that has: plotting and visualization capabilities, is cross-platform, has a big user base, and in a language that nearly everyone in academia and/or involved with modelling fluid flow probably already knows. Matlab/Octave can potentially have all of those.

深海夜未眠 2024-09-15 00:29:58

好吧,除非有任何其他建议,否则我得出的最终答案是使用 Python。

我认真考虑过 matlab/octave,但是当阅读 Octave API 和 matlab API 时,它们有足够的不同,我需要为每个接口构建单独的接口(或者使用宏来发挥创意)。通过 python,我最终得到了一个更容易维护的前端代码库,并且几乎我们认识的每个人都在使用它。感谢大家的提示/反馈!

Well, unless there are any other suggestions, the final answer I have arrived at is to go with Python.

I seriously considered matlab/octave, but when reading the octave API and matlab API, they are different enough that I'd need to build separate interfaces for each (or get very creative with macros). With python I end up with a single, easier to maintain codebase for the front end, and it is used by just about everyone we know. Thanks for the tips/feedback everyone!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文