[C++?] Серьезный вопрос.

>Чтобы творить чудеса с большими матрицами надо уметь хорошо работать с кешем. Никакой чудодейственный компилятор тут не поможет.

Да вот Мейерс пишет что в свое время APL был чудом, а секрет в том что он вычислял только то что явно затребовано, т.е использовал "ленивое" вычисление.

>В моём линуксе даже скомпиленные кутешные проги не запускаюца :(

В моем тоже, но я знаю, что если поставить libQt-чего-то-там, то все заработает. Что надо ставить для WPF? Windows не предлагать.

>Да вот Мейерс пишет что в свое время APL был чудом, а секрет в том что он вычислял только то что явно затребовано, т.е использовал "ленивое" вычисление.

Ну раз пошли такие пироги, у меня для тебя есть хорошая новость: идеальный язык программирования HL и его продвинутая модификация HL++. Великолепно подходят для эзотерики вроде "программы, выводящей свой исходный код на экран дисплея".

s/экран дисплея/дисплей/

>>Да вот Мейерс пишет что в свое время APL был чудом, а секрет в том что он вычислял только то что явно затребовано, т.е использовал "ленивое" вычисление.

>Ну раз пошли такие пироги, у меня для тебя есть хорошая новость: идеальный язык программирования HL и его продвинутая модификация HL++.

Взял, процитировал мнение известного эксперта по С++ и активного участника c.l.c++.moderated и получил в ответ ерничание. Ну хорошо, этап виляния и придирания к мелочам мы уже видимо миновали.

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

Если ты за свою жизнь не написал ни одного не сегфолтящегося приложения на олдскульных C/C++/Pascal, то с чего же ты взял, что нет таких людей, которые пишут на C и без сегфолтов?

Так говорит огромная куча софта, которая написана неплохими вроде программистами, но тем не менее сегфолтится.

Это следует понимать как: «Я совсем ничего не пишу, поэтому сегфолтится нечему»?

Почти. Я ничего не пишу на языках, проги на которых сегфолтятся.

Специально для похапешников я еще «белые экраны» упомянул.

На похапе я тоже не пишу. Есть и более другие языки.

Теперь нас 3-4.

Welcome.

>где математические библиотеки, поддерживающие быстрое перемножение матриц

http://hackage.haskell.org/package/hmatrix http://hackage.haskell.org/package/hmatrix-static

>вычисление коэффициентов преобразования Фурье

FFTW написан на связке OCaml и С. я понимаю, что это не библиотека для Haskell (хотя и там её попользовать можно) и что это не чистое ФП (ну да чистого ФП нет почти нигде), однакона применимость подхода всё же намекает - кто у нас тут быстрей FFTW и чтобы на C++ есть, а? было бы интересно посмотреть

>где поддержка математических типов данных

http://hackage.haskell.org/package/numeric-prelude

покажи мне библиотеку на C++, в который была бы хотя б половина. ну или аналог вот такого:

http://www.haskell.org/docon/

я понимаю, символьные алгебраические вычисления это не числодробилка, однако ты что - правда будешь утверждать, что C или C++ для этой цели подходят лучше, чем Haskell или ~APL (J, например)?

>где компиляторы, эффективно оптимизирующие математические операции?

возьми вот это, например:

http://www.cs.uu.nl/wiki/UHC/WebHome

и напиши нужные тебе оптимизации

>если тебе надо посчитать поле скоростей нефти в трубе

для такой задачи я возьму yorick и не буду сношать себе мозг

> с 13:36 kemm не появлялся, видимо всё еще пишет умножение матриц на хаскеле, языке, который "лучше подходит для этой задачи" :)

Я кому-то обещал писать код на хаскелле? Или просто этот "кто-то" слил доказательство своего утверждения о числодробилках как нише C++ и теперь пытается неумело перевести стрелки?

> кто у нас тут быстрей FFTW и чтобы на C++ есть, а? было бы интересно посмотреть

Моя собственная fft библиотека, заточенная исключительно под разложение действительной периодической функции по синусам и косинусам уделывала fftw.

> покажи мне библиотеку на C++, в который была бы хотя б половина. ну или аналог вот такого:

вместо качества берем количеством?

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

значит твои слова про хаскель были газификацией лужи, так и запишем

Ты что-то путаешь. Газификация луж -- твои утверждения про числодробилки как нишу C++.

>FFTW написан на связке OCaml и С.

google: ocaml site:www.fftw.org не подтверждает этой гипотезы, а вот ./configure --help рассказывает нам о том, что эта библиотека поддерживает фортран. Это я к разговору о числодробильных языках и имеющихся в них инструментах.

>http://hackage.haskell.org/package/numeric-prelude

В монадах не разбираюсь. Можно в двух словах, чего там такого клевого?

>покажи мне библиотеку на C++, в который была бы хотя б половина. ну или аналог вот такого...

В монадах не разбираюсь (см выше), но google("C++ symbolic algebra system") приводит нас к http://www.ginac.de/

>возьми вот это, например

"Сделай сам"? :D Нет, спасибо, это приведет к заключению, что классическая машина Тьюринга замечательно подходит для реализации разностных схем решения дифуров, ведь это _можно_ на ней сделать.

>ocaml site:www.fftw.org не подтверждает этой гипотезы

http://www.fftw.org/faq/section2.htm

>вместо качества берем количеством?

реагирую на шлангование. нечего говорить, что библиотек нет, если они есть; более того, как раз в смысле алгебры хороших библиотек будет уж точно не меньше

да и при чём здесь количество? это - минимум, основные алгебраические конструкции. где этот минимум для C или C++, каким бы хорошим он ни был? покажи его нам - сравним, оценим, вместе погорюем о количестве и качестве математических библиотек для Haskell

>Моя собственная fft библиотека, заточенная исключительно под разложение действительной периодической функции по синусам и косинусам уделывала fftw

ты это сейчас серьёзно сказал, или это шутка такая? а давай ещё библиотеку нелинейной оптимизации, заточенную под квадратичные функции, сравним c общими алгоритмами и убедимся в том, что они сливают?

>вместо того чтобы словоблудить

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

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

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

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

>для такой задачи я возьму yorick и не буду сношать себе мозг

Прости за тупой вопрос, но я просто не знаю, что такое yorick: а он позволяет эффективно реализовывать специально разработанные разностные схемы для решения частных случаев систем дифуров? Ты же должен понимать, что проблемы, встающие в реальном мире, не описаны в вузовских учебниках, откуда позаимствованы подходы для решения дифуров в таких вычислительных системах?

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

Еще мне вспоминается, что в студенчестве я присутствовал на лекции одного инженера (?) из Франции (?), который рассказывал свою историю успеха о том, как он вывел дифференциальные уравнения, описывающие какой-то там производственный процесс, а затем писал на C++ приблуду для поиска численного решения, ибо существующие матлабы как-то не справлялись с объемами данных. Пардон за отсутствие конкретики, но дело было лет 5 назад.

Дислексия? Я тебе написал, что ни один из этих, с позволения сказать, "аргументов" не является специфичным для плюсов. Ссылку дать? Сегодня демпингую, отмотка тредов по $5/сообщение.

>В монадах не разбираюсь (см выше), но google("C++ symbolic algebra system") приводит нас к http://www.ginac.de/

надо же, ты открыл для себя ginac! судя по удивлённому взгляду, с вопросом обсуждения ты вообще не знаком. ну открой тогда для себя ещё libmatheval и yacas, потом сходи по ссылкам и попробуй всё-таки почитать хотя бы статьи (там больше художественного текста чем кода, будет опять же несложно), а потом возвращайся да поговорим

>не подтверждает этой гипотезы

т.е. с FFTW ты тоже не работал

>"Сделай сам"

ну, тебе ж это надо, не мне

>Прости за тупой вопрос, но я просто не знаю, что такое yorick

http://yorick.sourceforge.net/

http://www.maumae.net/yorick/doc/index.php

>Ты же должен понимать, что проблемы, встающие в реальном мире

веришь - понимаю

>Еще мне вспоминается

мне тоже много чего вспоминается на предмет численных методов. к сути вопроса это отношения не имеет

> реагирую на шлангование. нечего говорить, что библиотек нет, если они есть; более того, как раз в смысле алгебры хороших библиотек будет уж точно не меньше

Это называется передергивание. Я утверждал, что к хаскелю гемморойно прикручивать уже имеющиеся библиотеки (промышленные обрацы, вылизываемые годами: lapack, arpack, umfpack, blas, superlu...) и писать с нуля алгоритмы вычислительной линейной алгебры.

> ты это сейчас серьёзно сказал, или это шутка такая? а давай ещё библиотеку нелинейной оптимизации, заточенную под квадратичные функции, сравним c общими алгоритмами и убедимся в том, что они сливают?

Нахера мне общие алгоритмы, если нужен был частный работающий супербыстро и не имеющий идиотической GPL лицензии ?

> примеры матричных операций есть по приведённым мной ссылкам, не поленись сходить

Мне лень тратить время на вкуривание всякой мути. Я привел программу, давай аналог на Хаскеле. Аналог должен быть полностью на Хаскеле, а не в виде сишных либ к нему. Кстати как реализованы приведенные либы это еще вопрос.

C, C++ и FORTRAN, если быть точным.

Странно, но в бытность студентом специальности "Прикладная математика", мне не приходилось сталкиваться с проблемами решения задач численных методов на джава и прочих похапе. Хотя с тех пор гигагерцы подросли и, возможно, реализация численного решения системы линейных дифференциальных на Python сегодня будет всего лишь в 3-4 раза медленнее, чем нативная сишная/фортрановая реализация тогда.

>моё дело - прокомментировать твои "четыре пункта"

не твои, ошибся. это к linuxfan в таком случае было, прошу прощения, недоглядел

Начинаем по новому кругу. Кажется у кого-то туго с памятью. Я сказал, что мне нахер не нужно по языку который может делать только что-то одно. То что ты предлашаешь это равносильно тому, что программу печатающую "Hello world" писать на 11 языках программирования, каждый из которых будет печатать одну букву.

> C, C++ и FORTRAN, если быть точным.

Слушай, от Reset'а что-то внятное я получить уже отчаялся, может ты ответишь -- что такого есть в плюсовке для числодробилок, что оно принципиально удобнее С?

> Хотя с тех пор гигагерцы подросли и, возможно, реализация численного решения системы линейных дифференциальных на Python сегодня будет всего лишь в 3-4 раза медленнее, чем нативная сишная/фортрановая реализация тогда.

Без пруфлинков не катит. Это не сильно лучше утверждений про 1000 лет расчётов погоды на завтра.

На java еще с натяжкой можно, современная jvm работает очень быстро. Но вот когда дело доходит до параллельности тут то и начинается свистопляска.

> Я ничего не пишу на языках, проги на которых сегфолтятся.

Это всего лишь значит, что сегфолты твоих программ иначе называются.

У кого-то туго с чтением. В хаскелле, вроде, есть всё, тобой запрошенное. Сколько раз ещё повторить?

> Слушай, от Reset'а что-то внятное я получить уже отчаялся, может ты ответишь -- что такого есть в плюсовке для числодробилок, что оно принципиально удобнее С?

Если бы ты осилил мои пункты, то ты бы знал, что это шаблоны, ОО (только не надо рассказывать про ОО в Си), stl, человеческая работа с памятью.

>надо же, ты открыл для себя ginac! судя по удивлённому взгляду, с вопросом обсуждения ты вообще не знаком.

Судя по всему, ты упускаешьиз виду один простой факт: в жизни аналитические решения требуются гораздо реже численных. Точнее, за аналитическое решение многих систем дифуров тебя бы расцеловали, выписали нобелевку, любили и уважали, но реалии таковы, что получение символьного результата столь нетревиально, что даже за годную численную аппроксимацию тебя будут носить на руках. И пара человек в данном треде хочет донести до остальных простую мысль: для реализации этих самых численных аппроксимаций лучше всего подходят либо специальные числодробильные языки (FORTRAN), либо универсальная затычка в виде C/C++. Остальное слишком высокоуровнево и слишком медленно.

Если у тебя по-прежнему остаются какие-то сомнения в моей вменяемости, можешь заняться визуализацией какого-нибудь решения уравнения мелкой воды (да-да, это дифуры, описывающие, как будут расходиться волны на поверхности водоема при задании начальной формы волны). Попробуй посчитай его для области 1000x1000 точек на своем любимом интерпретируемом языке, а потом на C, тогда и поговорим.

Без работающего примера не катит.

>Я утверждал, что к хаскелю гемморойно прикручивать уже имеющиеся библиотеки (промышленные обрацы, вылизываемые годами: lapack, arpack, umfpack, blas, superlu...) и писать с нуля алгоритмы вычислительной линейной алгебры.

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

в том, что касается общеалгебраических библиотек, я свои аргументы привел: хороших рабочих аналогов на C, C++ или FORTRAN просто нет. да и ни к чему они там, это как раз область, в которой нужен язык с развитой системой типов - вроде Haskell или вообще какого-нибудь Epigram

>Нахера мне общие алгоритмы

а нахера тогда такой пример приводить? если отношения к делу он не имеет, аналогом FFTW не является, и никаких преимуществ подхода не предоставляет?

>Мне лень тратить время на вкуривание всякой мути

в таком случае чем ты тут занимаешься? пытаешься доказать превосходство одного метода над другим, но знаешь при этом только один - а на второй тебе тупо "лень тратить время"? ну так и зачем с тобой вообще что-либо обсуждать? и так ясно что позиция твоя при таких раскладах не изменится никогда

>Аналог должен быть полностью на Хаскеле, а не в виде сишных либ к нему

с какого хера такое условие? это типа выпендрится, да? пофиг на практическое применение, давайте поиграемся в термины. ты ещё "чистого-пречистого ФП" потребуй внутре, а то нетёплое ведь уже будет, да и неламповое

>человеческая работа с памятью.

Да не ты ли как-то жаловался что с Linux-овым malloc-ом память фрагментируется, а с BSD-шным все тормозит?

> Без работающего примера не катит.

Отлично, ты только что ещё раз слил свои же аргументы. Так что я продолжаю ждать доказательств тезиса "числодробилки -- ниша C++".

Это всего лишь значит, что сегфолты твоих программ иначе называются.

И иначе обрабатываются и ведут к другим последствиям. А так да, почти то же самое.

> И иначе обрабатываются и ведут к другим последствиям.

И к каким же "другим" последствиям они ведут? Программа продолжает работать из неопределенного состояния?

>т.е. с FFTW ты тоже не работал

Не далее чем пол-года назад я ставил коллекцию LADSPA плагинов, некоторым из которых требовалась эта самая libfftw. И не поверишь, как у меня не было окамля, так его до сих пор и нет, а libfftw.so есть и фильтры, использующие ее, работают. Тебе есть что сказать или ты хочешь, чтобы я поискал элементы окамля в ее исходных кодах?

>ну, тебе ж это надо, не мне

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

>ты упускаешьиз виду один простой факт: в жизни аналитические решения требуются гораздо реже численных

нет, не упускаю. просто для численных решения есть уже лет эдак 50, и некоторые из них (вроде GAMESS) работают в неизменном виде и по наши дни. в том же, что касается аналитического, проявляется сильная сторона "абсолютно бесполезного" Haskell и иже с ним

>для реализации этих самых численных аппроксимаций лучше всего подходят либо специальные числодробильные языки (FORTRAN), либо универсальная затычка в виде C/C++

дык я с этим и не спорю, вроде. не надо читать между строк

>Попробуй посчитай его для области 1000x1000 точек на своем любимом интерпретируемом языке, а потом на C, тогда и поговорим.

на сайте Yorick'а есть пример имитационного моделирования движения поверхности барабана; я на нём в своё время с успехом считал гибродинамику. не думай, что интерпретируемый = медленный, он очень неплохо заточен под описываемые тобой задачи

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

> Тебе есть что сказать или ты хочешь, чтобы я поискал элементы окамля в ее исходных кодах?

Дык этта, ссылку на faq fttw уже давали. Там, правда, 'l' в конце потеряли, но это не численные методы всё-таки, можно было догадаться... 8))

> зачем нужно писать с нуля алгоритмы вычислительной линейной алгебры, если они и так уже есть и хорошо работают,- мне, видимо, так и не понять :( тупой, видимо, что поделаешь

Потому что не все реализовано или реализовано не оптимально. В частности, вылизаны только алгоритмы для заполненных матриц.

> с какого хера такое условие? это типа выпендрится, да?

Нет, потому что в противном случае этот аналог будет написан не на хаскеле, а только запускаться из хаскеля. Если я свою программу запускаю из баша, то я же не говорю, что она написана на баше.

> в том, что касается общеалгебраических библиотек

Что подразумевается под этим словом? Что стоит за словом "хорошесть" ? Если численная библиотека не может загрузить core i7 на максимум, то я считаю её плохой.

>Тебе есть что сказать или ты хочешь, чтобы я поискал элементы окамля в ее исходных кодах?

слушай, хватит шланговать. FFTW написан связкой OCaml и C в том смысле, что сишный код в нём _генерируется_ программой, написанной на OCaml. да, я могу ткнуть тебя в исходники на OCaml - сделать, или таки сам найдёшь?

>Так вот, я не собираюсь писать даже простейший симплекс-метод на вашем петуне/похапе/руби/эрланге, потому что он: а) заведомо не будет быстрее существующих сишных библиотек; б) его еще надо писать, а для C/C++ он уже есть готовый, написанный, быстро работающий

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

>> И иначе обрабатываются и ведут к другим последствиям.

>И к каким же "другим" последствиям они ведут? Программа продолжает работать из неопределенного состояния?

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

Программа продолжает работать из неопределенного состояния?

Ммм... Я, видимо, ещё не настолько опытен. Затрудняюсь подобное представить.

сишных библиотек

C/C++

Так С или С++?

>Слушай, от Reset'а что-то внятное я получить уже отчаялся, может ты ответишь -- что такого есть в плюсовке для числодробилок, что оно принципиально удобнее С?

Вообще-то, он уже сказал о template, но ты, видимо, не слушал. Эти сраные угловые скобки позволяют писать эффективные обобщенные алгоритмы (да-да, те самые, которые позволяют легко перейти от long double к double или float там, где точность не столь критична, а производительность проседает). Также благодаря какой-то там тьюринг-полноте угловых скобок, становится возможным производить некоторые расчеты во время компиляции, что тоже может быть крайне полезным. И да, эти расчеты сложнее (1+3)/2.

Чтобы не быть совсем голословным, давай я скажу, что написать quick sort на C можно, но его придется оборачивать в макрос/переписывать для сортировки целочисленных или вещественных массивов. В C++, благодаря template<typename ValueT>, ты будешь иметь эффективный qsort без необходимости ручного заката солнца.

>Без пруфлинков не катит. Это не сильно лучше утверждений про 1000 лет расчётов погоды на завтра.

Поскольку для тебя "не катит" отсутствие пруфлинков, а затем существующие ты признаешь неудовлетворительными, можешь помочь камраду jtootf в исследовании уравнения мелкой воды. Ты пишешь на любимом хаскелле, он на своем любимом питоне, потом вы скидываетесь интеллектом и порождаете вариант на C, который не сегфолтится и рвет ваши функциональные поделки, как тузик грелку.

> на сайте Yorick'а есть пример имитационного моделирования движения поверхности барабана

Не знаю кто это, но ты что всерьез думаешь, что это сделано на javascript ?

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

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

Не поверю :) Это те последствия, которые вы _замечали_.

Впрочем, вспоминая твои слова "все программы написаны через жопу" %)

> В клиентской части, гуйне то есть, NPE почти всегда приводит к тому что "при нажатии на кнопку ничего не происходит".

Какая мелочь - подумаешь, программа не работает. Перезапуск всё исправит.

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

ну тогда надо придумывать новые алгоритмы и проверять их на той парадигме, на которую они лучше ложатся. в чём суть спора?

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

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

>Что стоит за словом "хорошесть"

применимость, само собой. близость к оригинальному матаппарату, полнота реализации. удобство использования

>Если численная библиотека не может загрузить core i7 на максимум, то я считаю её плохой.

я буду считать её плохой для core i7, и только в том случае, если мне _действительно_ не хватает её производительности в таком случае. загрузить core i7 в принципе и вечными циклами можно - мне привычней оценивать качество результата, а не процесса