是否应该为NodeJS编写NumPy插件或NumPy包装器？

Question

我一直在做一些广泛的搜索，但是我发现NumPy和NodeJS之间没有接口。为NumPy编写包装器或NodeJS插件是否有特殊原因？

在我的情况下能够使用NumPy的主要值是在大维矩阵上进行极快的线性代数运算。

我知道一些软件包，例如furiousJS和ndarray，提供多维数组操作，但是NumPy仍然是一个明显的赢家。

如果没有理由为Numpy Wrapper / Addon造成彻底的灾难，我不得不写一个。

Answer 1

可以为nodejs编写numpy包装器。 Numpy实际上有用c编写的核心文件，它使用swig来创建python包装器。所以应该可以这样做。 swig也支持nodejs。

Answer 2

是的，一个可以编写一个Node.js插件，该插件公开了底层的NumPy C API；但是，出于以下原因，是否可以进行此保证是另一回事：

1. 底层的NumPy C API旨在与Python对象很好地配合使用，因此需要进行数据编组和拆组的过程。这些过程通常不能很好地映射到JavaScript数据类型。因此，对于许多C API，任何附加组件都需要包装基础接口，以便将JavaScript数据类型整理为可口的形式。这可能需要大量工作，难以实现自动化，并且可能无法提供可比的性能。
2. 某些Python数据类型在JavaScript中没有等效功能（例如float16，complex等）。为了确保性能，必须仔细考虑为这些数据类型提供支持的任何尝试。复数arrays是这种考虑的一个很好的例子，尤其是在内存布局和返回值形状方面。
3. 即使一个人能够自动执行附加组件生成，我也认为人们会想要维护JavaScript习惯用法（例如，命名约定，参数列表与选项对象等）。再次，这需要包装器API，将需要编写和维护包装器API，以与NumPy和JavaScript共同发展。
4. 自然而然的，NumPy的开发需要花费数百（数千）个小时的时间，并且需要花费很多年的时间，而对重新发明轮子还是持谨慎态度的人是正确的。但是，如果您想要的是性能，以及成语和美学上的一致性，则还应该询问是否应该实现comparable NumPy功能，而不是使用包装器，而是使用JavaScript，Node.js和Java构建，而不是编写包装器。记住Web（包括WebAssembly）。精心设计的API design不仅可以让用户超过NumPy performance，还可以解锁更多符合人体工程学的API。 （正在进行this end的工作。）
5. 任何加载项都必须做出选择：将自定义的NumPy分发版本（即源文件）与该加载项一起发送，或者依赖于已安装的NumPy分发版本的存在。前者消除了不必维护多个事实来源的优势（即，一个人将需要设计机制来避免潜在的API漂移），而后者则将带来更严格的系统依赖性要求（即，一个人将需要特定的要求）。最低版本，这可能与用户的现有安装不兼容，或者可能必须通过处理NumPy版本之间任何API一致性的包装程序根据本地安装的版本进行分支）。简而言之，编写一个直接与NumPy接口的加载项并不像许多人最初想象的那样简单。
6. JavaScript开发已经远离“厨房水槽”样式库，尤其是考虑到小包装和小包装的优先考虑。考虑到NumPy的构成方式，厨房水槽样式库是唯一可能的形式。考虑到如何实现NumPy，如果决定将NumPy“分解”到smaller packages中，这将是一项艰巨的任务。在这一点上，我们回到有关reinventing the wheel是否可能只是更有效地利用时间的问题。

总之，是的，编写附加组件是可能的，但这是否是一个好主意，尚有争议。我的观点是，尽管编写与底层NumPy C API接口可以实现短期目标的插件，但更好的长期解决方案是让JavaScript和Node.js开发人员承担设计和实现NumPy的任务。 JavaScript ，以实现更好的性能，更好的人体工程学和更好的用户体验。

免责声明：我和其他人正在积极开发stdlib，这是JavaScript和Node.js的标准库，重点是科学计算，其中包括许多类似NumPy的{{3 }}用于处理多维数组并对其进行操作。