[?]библиотеки для написания dsl на python

к вам вопрос, вы писали «численные методы» на связке cl + c? Как там дела обстоят с распараллеливанием?

> в lisp'е есть нормальный ffi, поэтому такое г-но как numpy там пишется за час

Бгг. Это всё равно, что сказать «у нас есть поъемный кран, поэтому мы построим многоэтажку за день».

> Прочитал нумпай туториал. Если _это_ питонщикам представляется как возвышающее питон над другими языками наивысшее достижение, которым нужно гордиться, то питон в глубокой жопе.

Тоньше надо.

ну не будь клоуном же
fortran подвязывается за час к tcl и пистону (по месту и по надобности)
это даже в доках по нупаю нашкрябали, понимая что объять необъятное невозможно и нереально.

к вам вопрос, вы писали «численные методы» на связке cl + c?

В связке с ocaml делал. Делал на нем кодогенерацию. Сейчас смотрю на lisp, так как пока складывается ощущение, что некоторые вещи на нем будут выглядеть гораздо проще.

Как там дела обстоят с распараллеливанием?

А как в питоне с распараллеливанием? Очевидно, что распараллеливание должно делаться в backend'ах на MPI/OpenMP/CUDA .... Делать такие низкоуровневые вещи как матричная/векторная алгебра на cl я бы не стал, ибо тормозить будет.

ну не будь клоуном же

От зеркала отойди, перестанешь видеть клоуна. А я просто я бреду по колено в Tcl- и CL-клоунах, и меня немного забрызгало.

fortran подвязывается за час к tcl и пистону (по месту и по надобности)

И результатом этого оказывается именно подвязка.

Ни разу не использовал python для параллельных программ, я только видел, что есть несколько библиотек, которые реализуют mpi в питоне http://wiki.python.org/moin/ParallelProcessing ну и вот еще ссылка
http://mail.python.org/pipermail/chicago/2008-February/003607.html

> и меня немного забрызгало.

Ой, не надо ляля тут. Родовые травмы как «забрызгало» уже проходят ))

И результатом этого оказывается именно подвязка.

я даже и не ожидал от тебя ничего по существу.

Достебаться до слов, потребовать невпихуемое , захотеть статическую типизацию ... , что там еще в у нас в арсенале припасено ? ))

Что, на паскаль не похоже?

> Родовые травмы как «забрызгало» уже проходят ))

Я и не говорил, что тебя забрызгало.

И результатом этого оказывается именно подвязка.

я даже и не ожидал от тебя ничего по существу.

Ответа по существу на сравнение numpy и сферического наколеночного биндинга в вакууме? На это невозможно ответить по существу.

Достебаться до слов, потребовать невпихуемое , захотеть статическую типизацию

Я ничего не требовал. Numpy - удобная и полезная библиотека. Сравнивать ее с наколенными биндингами могут только свовсем уж тупые тролли.

Я тут не тролю. Это нормальная реакция человека, которому обычную либу преподносят как вершину программерской мысли.

> Я тут не тролю.

Доо.

Это нормальная реакция человека, которому обычную либу преподносят как вершину программерской мысли.

А где и кто тебе преподнес ее как «вершину программерской мысли»?

Numpy - удобная и полезная библиотека. Сравнивать ее с наколенными биндингами могут только свовсем уж тупые тролли.

Обычно запрещают сравнивать те, кто боится, что их фетиш не выдержит сравнения.

А где и кто

Это был топикстартер. Да и ты тоже как-то слишком рьяно его тут защищаешь.

> И раз уж я общаюсь со специалистом, приведите, пожалуйста, пример такого софта с кодогенерацией. Очень интересно посмотреть.

О существовании подобного софта в открытом доступе мне не известно.

Вот пример. Кодогенераторы для методов типа связанных кластеров (Coupled Clusters). Есть еще ряд примеров, вроде генерации кода для расчетов в high-energy physics (трансляторы диаграмм Фейнмана), но я с ними слабо знаком.

Чувак, у тебя есть ссылка на нумпай. дай ссылку на второго конкурсанта. Не «этоможнонаписатьзачас», а реальные исходники. Тролль, ты еше не наелся?

> Ответа по существу на сравнение numpy и сферического наколеночного биндинга в вакууме? На это невозможно ответить по существу.

носишься как дурень со ступой со своим numpy ))
ну на, удавись:
This project provides the NAP (n-dimensional array processor) extension to Tcl.
http://tcl-nap.sourceforge.net/

хотя, быстрый код для расчетов = fortran + c, а все иное понты и дань моде.

>> Numpy - удобная и полезная библиотека. Сравнивать ее с наколенными биндингами могут только свовсем уж тупые тролли.

Обычно запрещают сравнивать

Болезный, да кто ж тебе запрещает? Сравнивай. Опубликуй свой биндинг, и скажи «вот тут я круче numpy сделал».

их фетиш

Те, у кого есть фетиш, при сравнении своего фетиша с чем угодно выдают стандартный текст: «если $FEATURE представляется как возвышающее $LANGUAGE над другими языками наивысшее достижение, которым нужно гордиться, то $LANGUAGE в глубокой жопе».

Причем, что характерно, $FEATURE представляется как «возвышающее» только самими фетишистами.

> Чувак, у тебя есть ссылка на нумпай. дай ссылку на второго конкурсанта.

Я хоть и не тот «чувак», но дам: Maxima. Написана на LISP, умеет все, что и numpy+scipy+sympy, и, возможно, что-то еще.

а скорость? видел несколько бенчмарков с крайне низкой скоростью максимы

Провожу аналогию: в языке N есть библиотека для решения квадратных уравнений. В других языках такой библиотеки нет. Можно ли отсюда делать какие-то выводы?

Утверждается, что для языков со сколь-нибудь вменяемым FFI (да хоть ctypes) интерфейсы для нужных функций написать столь же просто, как функцию для решения квадратного уравнения. Хватит 2-3 минуты на функцию.

> ну на, удавись:

Только твой возраст не позволяет мне ответить «ПНХ, слабоумный».

This project provides the NAP (n-dimensional array processor) extension to Tcl.

http://tcl-nap.sourceforge.net/

И? Кто-то сказал, что библиотеку работы с массивами можно сделать _только_ для Python? Этого никто не говорил, разговор о numpy и наколенных биндингах. Но вот Numpy существует и развивается, а в списке юзеров Tcl-NAP за последние 2 года - 4 письма, 2 из которых - без ответа.

> Утверждается, что для языков со сколь-нибудь вменяемым FFI (да хоть ctypes) интерфейсы для нужных функций написать столь же просто, как функцию для решения квадратного уравнения. Хватит 2-3 минуты на функцию.

Утверждается, что 2-3 минут не хватит. Утверждается также, что таким интерфейсом будет неудобно пользоваться.

>> Чувак, у тебя есть ссылка на нумпай. дай ссылку на второго конкурсанта.

Я хоть и не тот «чувак», но дам: Maxima

Хороший такой наколенный биндинг :)

> а скорость? видел несколько бенчмарков с крайне низкой скоростью максимы

Э, погоди. Maxima — это DSL для высокоуровневых математических проблем, для прототипизации, если угодно. После того, как задача нахождения алгоритма решена, можно критические части переписать на C/C++/Fortran.

Scipy/numpy, как и matlab — они тоже в основном для прототипизации или задач, которым скорость не критична.

> Что, на паскаль не похоже?
Нет, просто говно. when ... do ... and do... - вот это говно.
Правильный loop - это iterate. Если уж приводить пример, то хоть asdf (хотя тоже говно, но уже в другом отношении, как пример dsl сойдёт).

наконец-то что дельное,а не взаимные оскорбления :) спасибо за ссылку

дай ссылку на второго конкурсанта.

http://www.cliki.net/Mathematics

а реальные исходники.

реальные исходники чего?

> Scipy/numpy, как и matlab — они тоже в основном для прототипизации или задач, которым скорость не критична.

Если можно оставить прототип в роли рабочей программы и избежать переписывания. это весомый плюс.

Опубликуй свой биндинг, и скажи «вот тут я круче numpy сделал».

Я там выше уже три раза публиковал ссылочку на кучу либ, заруливающую нумпай в минуса.

Те, у кого есть фетиш, при сравнении ...

И этот человек обвиняет меня в толстоте!

> Этого никто не говорил, разговор о numpy и наколенных биндингах.

что есть «наколенные биндинги» ? Мне это непонятно.
Есть api языка и вполне квалификация программиста может позволить
использовать что-то более оптимально.
Почему это априори отвергается ? Не суди по себе всех.

Есть 2 варианта — если прототип в основном занимается дерганием библиотек на си/фортране, то ничего и переписывать не надо, хоть на нумпи, хоть на матлабе/мэпле/математике/чем угодно.

Если основная логика сидит на языке высокого уровня, то переписывания не избежать (опять же, не играет роли, с чего переписывать), а потому хорошо бы сей процесс автоматизировать. Для этого и нужна кодогенерация.

% Ваш К.О.

> Но вот Numpy существует и развивается

что там развивается ? ))
возня с мутациями пистона и это еще не развитие.

> Если можно оставить прототип в роли рабочей программы и избежать переписывания. это весомый плюс.

Да, но чаще всего оказывается так, что там, где можно оставить, удобнее пользоваться более высокоуровневыми вещами (тупо меньше набивать и проще отлаживать), а там, где скорость оказывается важной, выгоднее переписать. Так что это вопрос вкуса: numpy может быть равно и «одинаково хорош», и «одинаково плох»

>> Этого никто не говорил, разговор о numpy и наколенных биндингах.

что есть «наколенные биндинги» ? Мне это непонятно.

Это биндинги, написанные в рамках решения конкретной задачи, используемые только при ее решении, не опубликованные и не проверенные на широком классе задач.

Есть api языка и вполне квалификация программиста может позволить

использовать что-то более оптимально.

Почему это априори отвергается ?

Это не отвергается. Просто использование стандартных, готовых и удобных средств должно рассматриваться первым. И только в случае, когда эти средства не подходят, пишутся свои.

а скорость?

Если тебе важна скорость --- забудь про питон. Ибо этот тормоз, судя по http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest... в пятнадцать раз тормознее лиспа.

> если прототип в основном занимается дерганием библиотек на си/фортране, то ничего и переписывать не надо, хоть на нумпи

Эээ... речь шла не об этом. Речь шла о «готовый numpy против 2-3минуты на обертывание функции».

Это биндинги, написанные в рамках решения конкретной задачи,

Если они задачу решили, значит это хороший, нужный биндинг. Чего ты на них тогда взъелся.

when ... do ... and do... - вот это говно.

Будь любезен развить мысль подробнее.

> Речь шла о «готовый numpy против 2-3минуты на обертывание функции».

Right, именно так. Лапак ведь можно дернуть и из C++ программы, написав прототип или тупо стянув готовый из интернета

Тут в треде 2 темы для обсуждения — 1) прототипирование и кодогенерация; 2) numpy и другие обертки.

Что касается 2-3 минут, я в этом вообще проблему не вижу. Что касается удобства пользования биндингами, то здесь и нужны DSL-и и расширения языка. Все как-то дружно забыли, что numpy — не только и не столько биндинги, сколько расширение питона для многомерных массивов. Откровенно говоря, как расширение оно смотрится не очень.

> Это биндинги, написанные в рамках решения конкретной задачи, используемые только при ее решении, не опубликованные и не проверенные на широком классе задач.

А что, бывает очень грамотные решения в рамках закрытых проектах.
И отладка по сдаче работ бывает более эффективна чем опенсорный «щаляй валяй, и авось кто-то умный после меня подгребет, когда-то и при случае»

>> Это биндинги, написанные в рамках решения конкретной задачи,

Если они задачу решили, значит это хороший, нужный биндинг.

Я на них не взъедался - они слишком абстрактны. Меня смешит сравнение абстрактного биндинга с numpy; и я ставлю под сомнение необходимость написания этого биндинга.

Да вопрос-то с библиотеками этими имхо так ставить надо: есть задача, ресурсоемкость которой неизвестна до конца(раньше никто не делал, тк такой подход был очень ресурсоемкий(а сейчас например открылся новый алгоритм из другой области + компы помощнее стали), то есть неизвестно с какой точностью надо считать, то есть не известна ресурсоемкость).
Какую систему выгоднее предпочесть lisp + c/fortran, maxima + с/fortran, matlab, или numpy python + с/fortran, для прототипирования в случае если есть довольно высокая вероятность, что производительности высокоуровнего кода не хватит, но есть потребность обкатать быстро различные алгоритмы. Понятно, что этот вопрос зависит от конкретной задачи, но все-таки что бы предпочли вы и почему?
Да, языки одинаково знакомы/не знакомы.

биндинг --- это хорошо. С его помощью один хороший язык может использовать библиотеку на другом хорошем языке. А нумпай не нужен совсем. Это же очевидно, раз питон не нужен, то и питонолиба не нужна тоже.

> numpy — не только и не столько биндинги, сколько расширение питона для многомерных массивов.

Я бы назвал это «библиотекой».

Откровенно говоря, как расширение оно смотрится не очень.

А что не так? Не скажу, что глубоко знаю numpy (ну, другая у меня специальность), но, когда я его использую, никаких проблем не вижу.

> если есть довольно высокая вероятность, что производительности высокоуровнего кода не хватит, но есть потребность обкатать быстро различные алгоритмы

Тогда тебе нужен язык, позволяющий вести быструю разработку и компилироваться в быстрый нативный код. Из перечисленного выше — только лисп (конкретно — CL либо специально заточенный вариант схемы).

А почему ты не смотришь в сторону хаскеля/ML ? Они все генерят нормальный нативный код (порядка 0.5-0.7 от Си), но сразу предупреждаю — у окамля нет ffi, т.е. придётся обертки писать.

> биндинг --- это хорошо. С его помощью один хороший язык может использовать библиотеку на другом хорошем языке. А нумпай не нужен совсем. Это же очевидно, раз питон не нужен

Разговаривать с тобой - как разговаривать с мразматиком (это диагноз такой, а не метафора). Вроде иногда ты произносишь осмысленные фразы, но сразу после этого скатываешься в обычный бред.

lisp + c/fortran, maxima + с/fortran, matlab, или numpy python + с/fortran

КЛ (в редакции sbcl) --- самый быстрый из высокоуровневых языков. Скорость его отставания от С колеблется от процентов до разов, вместо десятичных порядков как в случае питона. Так что вполне возможно, чистый КЛ будет наилучшим выбором.

это диагноз такой

У вас есть диплом врача и разрешение на частную практику?