Выбор внешнего интерфейса / интерпретатора для научного кода - PullRequest
6 голосов
/ 02 июля 2010

Инструмент моделирования, который я разработал за последние пару лет, написан на C ++ и в настоящее время имеет интерпретируемый интерфейс tcl.Он был написан так, что его можно запустить либо в интерактивной оболочке, либо путем передачи входного файла.В любом случае, входной файл записывается в tcl (со многими дополнительными командами для моделирования, которые я добавил).Это позволяет использовать довольно мощные входные файлы (например, при запуске сим-карт Монте-Карло случайные распределения могут быть запрограммированы как процедуры tcl непосредственно во входном файле).

К сожалению, я обнаружил, что интерпретатор tcl несколько становитсяограничен по сравнению с тем, что могут предложить более современные интерпретируемые языки, и его синтаксис кажется немного загадочным.Поскольку вычислительный движок был написан как библиотека с c-совместимым API, было бы просто написать альтернативные внешние интерфейсы, и я думаю о переходе на новый интерпретатор, однако у меня есть немного времени на выбор (в основномпотому что у меня нет значительного опыта работы со многими устными языками).Опции, которые я начал исследовать, следующие:

Осталось с tcl:
Плюсы:
- Нет необходимости изменять существующий код.
- Существующий вводфайлы остаются прежними.(хотя я бы, вероятно, оставил интерфейс tcl в качестве опции)
- Зрелый язык с большой поддержкой сообщества.
Минусы:
- Ощущение ограниченности синтаксиса языка.
- Получение жалоб отпользователи относительно сложности изучения tcl.

Python:
Плюсы:
- Современный переводчик, известный своей эффективностью.
- Большое, активное сообщество.
- Хорошо известные научные и математические модули, такие как scipy.
- Обычно используемые в академическом научном / инженерном сообществе (типичные пользователи моего кода)
Минусы:
- Я никогда не использовал егои, следовательно, потребуется время, чтобы выучить язык (это тоже профессионал, так как я давно собирался изучать python)
- строгое форматирование входных файлов (отступы и т. д.)

Matlab:
Плюсы:
- Очень мощный и широко используемый математический инструмент
- Мощная встроенная визуализация / построение графиков.
- Расширяется с помощью кода, представленного сообществом,а также коммercial toolboxes.
- Многие в научных и инженерных кругах знакомы с matlab и знакомы с ним.
Минусы:
- Не может распространяться как исполняемый файл - потребуется дополнение / toolbox.
- Требуется (?) Компилятор Matlab (который дорогой).
- Требуется Matlab, который также дорогой.

Эти плюсы и минусы - вот что я смог придумать,хотя у меня очень мало опыта работы с устными языками в целом.Я хотел бы услышать любые мысли по поводу обоих переводчиков, которые я предложил здесь, если перечисленные плюсы / минусы являются законными, и любых других переводчиков, о которых я не задумывался (например, будет ли php подходить для чего-то подобного? Lua?).Опыт непосредственного использования встроенного интерпретатора в ваш код, безусловно, является плюсом!

Ответы [ 3 ]

5 голосов
/ 02 июля 2010

Я был сильным сторонником Tcl / Tk с предварительного релиза, пока я не сделал с ним большой проект и не обнаружил, насколько он не поддерживается. К сожалению, поскольку прототипы в Tcl настолько просты, вы получаете «одноразовые» сценарии, которые сами по себе живут.

Приняв Python за последние несколько месяцев, я обнаружил, что это все, что обещал Tcl, и многое другое. Как многие ветераны Python могут сказать вам, отступы в исходном коде беспокоят в течение первого часа, и тогда это кажется не помехой, а утвердительно полезным. Между прочим, автора Tcl, Джона Оустерхаута, поочередно хвалили и панировали за то, что он написал язык, который заставил One True Brace Style на Tcl-кодерах (я был 1TBS, так что я был в порядке).

Единственными конструкциями Tcl, которые плохо обрабатываются Python, являются произвольные eval "${prefix}${command} arg" конструкции, которые в любом случае не должны использоваться в Tcl, но есть и операторы типа uplevel (которые были хорошей идеей, но сделаны для некоторых волосатых код). Действительно, Python немного антагонистичен динамическому eval, но я думаю, что это хорошо. К сожалению, я до сих пор не выбрал язык, который охватывал бы его GUI, а также Tcl / Tk; Tkinter делает работу в Python, но это больно.

Я вообще не могу говорить с Матлабом.

За несколько месяцев работы с Python я почти наверняка перенесу любую программу Tcl, которая находится в стадии разработки, на Python для здравомыслия.

3 голосов
/ 02 июля 2010

Рассматривали ли вы использование Octave?Исходя из того, что я понял, это почти заменяющая часть matlab.Это может позволить вам поддерживать matlab для тех, у кого он есть, и бесплатную альтернативу для тех, у кого его нет.Поскольку «мясо» вашей программы, по-видимому, написано на другом языке, соображения производительности, по-видимому, не так важны, как обеспечение среды, которая имеет: возможности построения графиков и визуализации, кросс-платформенные, имеют большую базу пользователейязык, который почти каждый в академических кругах и / или связан с моделированием потока жидкости, вероятно, уже знает.Matlab / Octave потенциально может иметь все это.

0 голосов
/ 06 июля 2010

Ну, если нет других предложений, окончательный ответ, к которому я пришел, - это использовать Python.

Я серьезно рассматривал matlab / octave, но при чтении octave API и matlab API они достаточно различны, поэтому мне нужно было бы создавать отдельные интерфейсы для каждого (или очень креативно с макросами). С Python я получаю единую, более простую в обслуживании кодовую базу для внешнего интерфейса, и она используется практически всеми, кого мы знаем. Спасибо за советы / отзывы всем!

...