Re: Программирование научных программ на C.
On Wed, Feb 12, 2014 at 03:55:04PM +0900, Fedor Zuev wrote: > On Wed, 12 Feb 2014, Sergey B Kirpichev wrote: > > SBK>On Mon, Feb 10, 2014 at 11:26:05PM +0900, Fedor Zuev wrote: > SBK>> Ну так я вроде же указал на PDL, подражанием которому > SBK> > SBK>Из машины времени что-ли? ;) > SBK> > SBK>> (не доделанным и наполовину, если я правильно помню) является numpy. > SBK> > SBK>Мягко говоря, недоделанным выглядит больше PDL. Достаточно > SBK>сравнить > SBK>http://pdl.perl.org/?page=reference > SBK>http://docs.scipy.org/doc/ > Э, и что это должно иллюстрировать? Что больше "доделано". > Что у питона нет встроенной документации? С чего вы взялись утверждать подобный идиотизм? Стесняюсь, но придется спросить: вы вообще python использовали? > Numpy примерно соответствует (за вычетом разной странной фигни, > которая в PDL не нужна, потому что гораздо лучшая функциональность > в Перле изкоробки) первым четырем модулям PDL: Core, > Basic,Ops,Ufunc. Ну, плюс еще CallExt, уж коли мы заговорили о > фортране. Но в PDL-то этих модулей - шестьдесят! Плюс еще десятка > два модулей для PDL отдельно, на CPAN-е. В scipy-стеке есть еще ряд проектов (http://www.scipy.org/), собственно на документацию самого scipy я указал. numpy - это лишь ядро численных пакетов. Ну а "внешних модулей" - тоже на pypi... Есть на CPAN сопоставимый аналог theano? > И да, я впечатлился, каких чудовищных плясок с бубном (судя по > документации) требует NumPy там где в PDL вообще ничего делать не > надо (потому что соответствующая функциональность прозрачна). Например? Странно, что люди выбирают "пляски с бубном"... Для сравнения: https://www.ohloh.net/p/pdl https://www.ohloh.net/p/numpy - популярнее на 2 (!) порядка. (Ну а другая статистика - показывает что проект скорее мертв чем жив...) Ерунда, конечно, но и финансируются проекты scipy ощутимее, и ссылаются на них чаще в публикациях... В общем, я вряд-ли навру если скажу что это решение - популярнее. > Ну так поймите, в перле - в отличии от - вызов внешней библиотеки, > причем не в специально для этого написанном модуле со CPANа, а прямо > из прикладной программы - редчайшая экзотика. Если вам это > понадобилось - значит либо вы пишете что-то глубоко системное, либо > у вас неправильная постановка задачи. Либо вы хотите использовать хорошие численные алгоритмы, за которыми стоят годы разработки и тестирования. Жаль, но приходится признать - я был прав в догадке, что будет "зачем нам фортран?". А это признак того, что ваши потребности, мягко говоря, cпецифичны. > Поскольку, как я уже говорил, второе драли с первого. Покажите сперва машину времени в PDL, чтобы "драть". -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212092914.ga19...@darkstar.order.hcn-strela.ru
Re: Программирование научных программ на C.
Sergey B Kirpichev writes: >(Ну а другая статистика - показывает что проект скорее мертв чем >жив...) > > Ерунда, конечно, но и финансируются проекты scipy ощутимее, и > ссылаются на них чаще в публикациях... В общем, я вряд-ли навру если > скажу что это решение - популярнее. Эдак Wolfram Mathematica лучше, чем Maxima. Потому что финансируется ощутимие, и ссылаются на неё чаще. Так, что ли? С чего бы это популярность и финансирование для Вас является показателем качества и "жизни"? PS: Такое впечатление, что в этом споре немного не хватает сдержанности. pgpGJzOwCO6e_.pgp Description: PGP signature
Re: Программирование научных программ на C.
On Wed, Feb 12, 2014 at 03:26:26PM +0400, Dmitrii Kashin wrote: > Sergey B Kirpichev writes: > > >(Ну а другая статистика - показывает что проект скорее мертв чем > >жив...) > > > > Ерунда, конечно, но и финансируются проекты scipy ощутимее, и > > ссылаются на них чаще в публикациях... В общем, я вряд-ли навру если > > скажу что это решение - популярнее. > > Эдак Wolfram Mathematica лучше, чем Maxima. Технически, увы - лучше. Их возможности на данный момент, мягко говоря, несопоставимы. Глупо игнорировать факты, до такой степени вопиющие. > Потому что финансируется ощутимие, и ссылаются на неё чаще. Во-первых - Matematica вообще финансируется принципиально иначе. Это коммерческий продукт. > Так, что ли? С чего бы это > популярность и финансирование для Вас является показателем качества и > "жизни"? А почему нет? Оба показателя - вполне объективны. Мертворожденный или нафиг никому не нужный проект - вряд-ли получит грант. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212120554.ga23...@darkstar.order.hcn-strela.ru
Re: Программирование научных программ на C.
On Wed, 12 Feb 2014, Sergey B Kirpichev wrote: SBK>> SBK>http://pdl.perl.org/?page=reference SBK>> SBK>http://docs.scipy.org/doc/ SBK>> Э, и что это должно иллюстрировать? SBK> SBK>Что больше "доделано". SBK> SBK>> Что у питона нет встроенной документации? SBK> SBK>С чего вы взялись утверждать подобный идиотизм? Вы сами дали мне ссылку на пучок каких-то кривых и косноязычных PDF-ов, утверждая что это-то и есть документация. Из этого я делаю вывод, что другой, нормальной документации, аналогичной, скажем, перловскому POD - у вас там нет. Если я ошибся, и Вы имели в виду что - то другое - что ж, прекрасно. SBK> SBK>Стесняюсь, но придется спросить: вы вообще python использовали? Я? Боже упаси! Мне приходилось немного править скрипты на питоне, писанные другими. Для того чтобы оценить прелести и ароматы сего явления этого вполне достаточно, ящетаю. SBK> SBK>> Numpy примерно соответствует (за вычетом разной странной фигни, SBK>> которая в PDL не нужна, потому что гораздо лучшая функциональность SBK>> в Перле изкоробки) первым четырем модулям PDL: Core, SBK>> Basic,Ops,Ufunc. Ну, плюс еще CallExt, уж коли мы заговорили о SBK>> фортране. Но в PDL-то этих модулей - шестьдесят! Плюс еще десятка SBK>> два модулей для PDL отдельно, на CPAN-е. SBK> SBK>В scipy-стеке есть еще ряд проектов (http://www.scipy.org/), SBK>собственно на документацию самого scipy я указал. numpy - это лишь SBK>ядро численных пакетов. Ну а "внешних модулей" - тоже на pypi... SBK>Есть на CPAN сопоставимый аналог theano? Поиск показывает, что наиболее популярным пакетом в этой области является Math::Symbolic. О его сравнительных достоинствах ничего сказать не могу, никогда не пользовался. Мне вообще не вполне понятно, зачем кому-то может понадобиться программировать символьные вычисления на скриптовом языке. SBK> SBK>> И да, я впечатлился, каких чудовищных плясок с бубном (судя по SBK>> документации) требует NumPy там где в PDL вообще ничего делать не SBK>> надо (потому что соответствующая функциональность прозрачна). SBK> SBK>Например? Например преобразования типов, работа со срезами и подмножествами массивов, вообще итераторы, управление памятью. Функция ввода-вывода текстовых таблиц в NumPy очень смешная. Ну и вообще, когда арифметические действия над массивами (векторами, матрицами итд) записываются именно как арифметические действия, а не как нагромождение функций и методов с лавиной скобок - оно, знаете ли, изрядно повышает удобочитаемость и эффективность. SBK>Для сравнения: SBK>https://www.ohloh.net/p/pdl SBK>https://www.ohloh.net/p/numpy Простите, что это? SBK>> Ну так поймите, в перле - в отличии от - вызов внешней библиотеки, SBK>> причем не в специально для этого написанном модуле со CPANа, а прямо SBK>> из прикладной программы - редчайшая экзотика. Если вам это SBK>> понадобилось - значит либо вы пишете что-то глубоко системное, либо SBK>> у вас неправильная постановка задачи. SBK> SBK>Либо вы хотите использовать хорошие численные алгоритмы, за которыми SBK>стоят годы разработки и тестирования. Жаль, но приходится признать - SBK>я был прав в догадке, что будет "зачем нам фортран?". А это признак SBK>того, что ваши потребности, мягко говоря, cпецифичны. Если это _хорошие_ численные алгоритмы, то они давно уже опубликованы, входят в состав популярных, широко используемых пакетов и все биндинги к ним давно уже написаны, причем не по одному разу. А при работе с разного рода унаследованным внутриучрежденческим хламом, к которому принадлежит 80% ныне используемого фортрановского кода, потратить полчаса на описание интерфейса - это как бы наименьшая из связанных с этим кодом проблем. Я так понимаю, вы решили тут прихвастнуть знакомством с темами, которые знаете сильно понаслышке? SBK> SBK>> Поскольку, как я уже говорил, второе драли с первого. SBK> SBK>Покажите сперва машину времени в PDL, чтобы "драть". Вы уже который раз повторяете фразу про "машину времени", но я так и не понял, что Вы этим хотите сказать. PDL существует с 1996 года. К 2007 году (моменту первого релиза NumPy) PDL существовал уже больше десятилетия и в своей основе практически не отличался от современного. Последние лет пять-семь ядро PDL для Perl5 действительно практически не развивается - потому что его встраивают в Perl6 как часть языка и основное развитие идет там. Но вы сперва то что есть освойте, ага. Ну или переходите на Perl6. С точки зрения перловода там сейчас исчезающе скудный выбор пакетов, но в сравнении с Питоном - более чем.
Re: Программирование научных программ на C.
On Wed, Feb 12, 2014 at 10:09:52PM +0900, Fedor Zuev wrote: > Вы сами дали мне ссылку на пучок каких-то кривых и косноязычных > PDF-ов, утверждая что это-то и есть документация. Там есть обычные HTML, если не нравится PDF. А что, для перла является проблемой собрать штатную документацию в любом формате? > SBK>Стесняюсь, но придется спросить: вы вообще python использовали? > > Я? Боже упаси! Мне приходилось немного править скрипты на > питоне, писанные другими. Для того чтобы оценить прелести и ароматы > сего явления этого вполне достаточно, ящетаю. Понятно. Тогда я уже ничему не удивляюсь, раз вы даже встроенную документацию в процессе "правки" не нашли... Впрочем, c религиозными фанатиками дело я стараюсь не иметь, простите, если более не отвечу. > SBK>Есть на CPAN сопоставимый аналог theano? > > Поиск показывает, что наиболее популярным пакетом в этой > области является Math::Symbolic. В какой "этой области"? Как аналог theano?! - бред. Как "CAS на perl" - еще более смешно, оно ж вовсе ничего не умеет... > Мне вообще не вполне > понятно, зачем кому-то может понадобиться программировать символьные > вычисления на скриптовом языке. Черт его знает. Наверно, чтобы задачи решать. Вы спросите на досуге Wolfram Research, например. > SBK>Например? > > Например преобразования типов, работа со срезами и > подмножествами массивов, вообще итераторы, управление памятью. "Например все", я понимаю. Можно конкретнее? > Функция ввода-вывода текстовых таблиц в NumPy очень смешная. Чем? > Ну и вообще, когда арифметические действия над массивами > (векторами, матрицами итд) записываются именно как арифметические > действия, а не как нагромождение функций и методов с лавиной > скобок - оно, знаете ли, изрядно повышает удобочитаемость и > эффективность. Что именно вы подразумеваете под "арифметическими действиями"? Можете описать это математическими терминами (напр., арифметика - это вообще-то про числа), а не цитированным сяо? В качестве ликбеза: http://en.wikipedia.org/wiki/Operation_%28mathematics%29 vs http://en.wikipedia.org/wiki/Arithmetic_operation#Arithmetic_operations Если вы об использовании операторов вместо функций для операций сложения, умножения и проч. - то пожалуйста. В зависимости от типа (array, matrix), смысл операторов, конечно, различный. PDL, насколько я вижу, делает то же самое (только для матричного умножения перегрузили оператор "x", а не "*"). Или я что-то пропустил и перл (реальный, а не perl6) уже научился *создавать* новые операторы? > А при работе с разного рода унаследованным > внутриучрежденческим хламом, к которому принадлежит 80% ныне > используемого фортрановского кода, потратить полчаса на описание > интерфейса - это как бы наименьшая из связанных с этим кодом > проблем. Вот почему, оказывается, NASA numpy использует... > Я так понимаю, вы решили тут прихвастнуть знакомством с > темами, которые знаете сильно понаслышке? А то... > Вы уже который раз повторяете фразу про "машину времени", но > я так и не понял, что Вы этим хотите сказать. PDL существует с 1996 > года. А Numpy - с 1995. Только назывался он вначале иначе. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140212204458.ga9...@darkstar.order.hcn-strela.ru
