Glasgow Haskell Compiler 7.6.3

чота как-то *slow... уже с неделю в оверлее и с пятницы на нём сижу.

Как может быть полезен Haskell в задачах математической физики?
Например, какие математические задачи с помощью него легко решаются? Есть ли на нём реализованные системы символьных вычислений?

Как может быть полезен Haskell в задачах математической физики?

При желании можно использовать, хотя особых преимуществ по сравнению с C++/CUDA + LAPACK + thrust я не заметил. Думаю, стоит обратить внимание на пакет repa.

Есть ли на нём реализованные системы символьных вычислений?

Была одна. Вроде не шевелится.

Как может быть полезен Haskell в задачах математической физики?

Никак. Алгоритмы математической физики противоречат иммутабельности принятой в хаскеле.

Например, какие математические задачи с помощью него легко решаются?

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

Для матфизики скорее важны библиотеки и возможность байтоложества, а не выразительная сила языка.

иммутабельности принятой в хаскеле.

Man ST, man IO.

И примеры чего-либо рабочего убийственного будут?

И примеры чего-либо рабочего убийственного будут?

Например, GHC.

Ну а что-нибудь вне хаскелля? А то прям получается хаскелль супер пупер язык для решения проблем самого хаскелля

xmonad

свободной рабочей группой

Это как?

О боги, Годзилла шевелится!

http://hackage.haskell.org/packages/archive/pkg-list.html

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

слушайте, идите троллить в другое место, хорошо?

Это не троллинг, а факт. Задачи математический физики и функциональное программирование не совместимы. Это я тебе как к.ф.м.н. по специальности 01.01.07 (вычислительная математика) говорю. А если тебе не нравится слышать от меня факты, можешь заигнорить, разрешаю.

Допустим хотя и опять на убийцу не тянет, тайловых WM с куда большим сообществом можно привести минимум 2-3.

Это лишь строительные блоки, а готовые приложения на нем есть? Ведь это есть вполне объективный показатель «убийственности»

факт, в том, что ты не знаешь haskell и его возможностей. А про к.ф.м.н. через полтора года поговорим, когда этот пункт не будет выгодно отличать тебя от меня :P.

Я знаю, что для мутабельности там есть костыли, только выглядит это всё инородно и некрасиво и, самое главное, никаких преимуществ перед фортраном и си не дает.

Я в PR-отделе haskell не состою, денег за рекламу на ЛОРе мне не платят. Ссылку на список большей части приложений я вам дал, дальше судите сами.

я тебе уже сказал, что ты не знаешь haskell, пожалуйста не продолжай меня убеждать в негодности подготовки некоторых специалистов на 01.01.07. Да, написание реализация многих алгоритмов из чиленных методов на haskell требует некоторого опыта и знания, что в прочем верно и для других языков. При этом haskell не вносит никаких фундаментальных ограничений, а так же позволяет использовать нативные либы, т.к. все равно в порядочном числе случаев на любом языке будут использованы они.

При этом haskell не вносит никаких фундаментальных ограничений

Не вносит, но вынуждает танцевать с бубном.

а так же позволяет использовать нативные либы

А зачем тогда хаскель?

Мне кажется, что сейчас самое крутое сообщество у xmonad как раз, на втором месте awesome.

Но полностью согласен, что на «убийцу» не тянет.

Вот если бы accelerate довели до вменяемого состояния, может и появился бы смысл писать численные методы на haskell. Но этого не произойдёт никогда, поскольку там внутри Содом и Гоморра, проще всё выкинуть и написать заново.

haskell в численных методах можно использовать, но не на прямую. Численная программа обычно состоит из однотипных портянок на фортране/си/куде ... так вот, на хаскеле их можно было бы генерить, описывая алгоритмы каким-либо более простым высокоуровневым способом.

Я когда-то такое на схеме писал :)

Не вносит, но вынуждает танцевать с бубном.

Не могу согласиться, если понимаешь что делаешь и зачем, то все просто.

А зачем тогда хаскель?

затем же зачем и яву в тех же задачах рассеяния пользуют - быстрое прототипирование, простой hi-level, при этом низкоуровневые алгоритмы дергать из написанных либ, та же фигня что и с сями + почти теже накладные расходы. Т.е. написать автомат для решения диффуров (matlab-style) мне сильно приятнее на haskell.

Я бы ещё мог поговорить про fusion, dph, accelerate, но я их не умею.

Но этого не произойдёт никогда, поскольку там внутри Содом и Гоморра, проще всё выкинуть и написать заново.

в accelerate?

ну и он так же как и прочие вычисления на GPU подходит лишь для подкласса задач.

так вот, на хаскеле их можно было бы генерить, описывая алгоритмы каким-либо более простым высокоуровневым способом.

accelerate как раз и пример такого подхода. Но эта библиотека написана просто отвратительно, более сильной связности кода я не видел.

ну и он так же как и прочие вычисления на GPU

В принципе, там можно сделать и CPU backend. Но поскольку accelerate копирует Prelude, это не особо-то и нужно.

это совсем не нужно. А я говорил к тому, что не все алгоритмы хорошо ложатся на gpu, часть нужно доводить руками, напр. объединяя много независимых блоков в одну gpu операцию и обучить этому ЯП было бы круто, а для части не сделать ничего (ну или пока не известно что). Само accelerate я почти не трогал, проверил, что gpu работает и забил.

А я говорил к тому, что не все алгоритмы хорошо ложатся на gpu

Внутри accelerate заквазицитированы прототипы CUDA-ядер, реализующие векторные операции, они написаны GPU-friendly образом (хорошо ложатся на GPU). Это хорошая идея. В прототипы этих ядер подставляется код на haskell, полученный заменой всех операторов на аналоги, генерирующие AST. Это плохая идея. Полученное ядро на каждый вызов pretty-принтится и компилируется. Это отвратительная идея.

Внутри accelerate заквазицитированы прототипы CUDA-ядер, реализующие векторные операции, они написаны GPU-friendly образом (хорошо ложатся на GPU).

(хорошо ложатся на GPU).

только в случае достаточного размера.

с остальной частью поста согласен.

чтобы вернуть разговор в нормальное русло. В целом нужно смотреть на компромисы надо идти и какие проблемы вносит RTS haskell. Во-первых это Boxed типы их наличие дает возможность собирать их GC и делать отложенные вычисления, но разносит значения в памяти и добавляет пару тактов на их получение, в целом это не страшно учитывая анализатор строгости, и то, что реально многие переменные сделаются unboxed (unlifted) при этом компилятор их может удобно раскидать по регистрам, во-вторях это то, что целочисленные переменные хранятся в 32bit/64bit в зависимости от разрядности, несмотря на реальный размер, итого, чтобы сделать сжатый массив short-ов, нужно немного попрыгать, а иногда это важно, в-третьих это concurrency модель, которая позволяет дешево запускать кучу конкуретных тредов и спарков, но при этом вносит под вес в случае однопоточной программы в которой надо вычислять всё (я пока не знаю можно ли это преодолеть), в-четвертых это GC сильно ухудшающее жизнь, периодически всплывают статьи о region-based подходах типизированной мапяти, но пока полноценнго production ready подхода нет. Бонусы: возможности fusion (работа над массивами без фактического их создания), dph (только в GHC-HEAD) позволяющее распараллеливать мелкие операции, parallel-strategies - неявный параллелизм, удобные библиотеки типа vector-space. Соответственно писать численные методы можно только нужно сразу выделить для себя чем и за что придется платить и решить стоит ли оно того, вопрос неочевидный и сильно зависит от решаемой задачи.

Замечу, что все вышеперечисленное совершенно ортогонально проблемы мутабельности - иммутабельности, и это являлось причиной моего первого комментария тебе.

qnikst, dmfd, Reset вы как-то не так поставили вопрос. Черт с ней, со скоростью, вменяемой скорости можно почти в любом языке добиться, примеры Self и LuaJIT вам в помощь. Вопрос должен стоять так: «Какие идиомы в Haskell помогут мне существенно упростить разработку программ численного моделирования (и даже конкретно в матфизике)?»

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

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

Если бы вопрос изначально стоял так, как ты его поставил, то я бы предпочел в него не ввязываться, т.к. он подразумевает выяснение технического background-а человека и опыта его работы с другими ЯП и задачами, и в 90% случаев привел бы к тупому холивару. К тому же все примеры, что приводятся в таких спорах это разные helloworld-ы без оценки проблем их использования в масштабном проекте и интерес в них только сказать, что оппонент не прав приводя этот пример и дождаться комментариев людей знающих язык, которые объяснят что в примере не так :)

Естественно, я имел ввиду низкоуровневые алгоритмы, частично реализованные в таких библиотеках как blas и lapack.

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

Именно разработку. То есть, вывод/подбор формул.
Чем может помочь Haskell для символьных вычислений? (не числодробилок) Например, при выводе формул в рамках общей теории относительности.

ну в этом случае я не вижу смысла не использовать blas, lapack, goto, scalapack, (сюда же можно довить ускоспецилизированные либы) а делать что-то свое. Весь вопрос в клее вокруг этих вызовов и всяких операциях этими библиотеками не покрывающимися.

Вопрос не ко мне, я не евангелист хаскеля :)

http://klocwork.com - статический анализ и верификация кода.

Например, при выводе формул в рамках общей теории относительности.

Для этого есть cadabra. Правда я с ней толком не разбирался, поскольку число аналитических решений в ОТО можно пересчитать по пальцам, связности для них проще найти в книжках, а всё остальное сделать на бумажке.

Кто-то говорит, что для веба Yesod все очень любят.

Это я тебе как к.ф.м.н. по специальности 01.01.07 (вычислительная математика) говорю

Для таких заявлений, если уж давите авторитетом, надо бы еще и PhD в Computer Science добавить :)

С вашей точки зрения это лидирующий\монопольный инструмент?

Не монопольный, но один из лидеров, да.

Что реально написано на хаскеле?

Зачем это нужно, если есть Groovy?

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

Man ST, man IO.

+ man STM.

Чем может помочь Haskell для символьных вычислений?

Близко к теме: погугли «автоматическое дифференцирование» для Haskell.