Изучение С++ с уклоном на численные методы

[fuzzy2006]

Здравствуйте!
Необходимо изучить и понять пролетарскую суть С++ и научиться писать программы ориентированные на математическое моделирование, численные методы решения уравнений в частных производных (метод конечных разностей, метод конечных элементов), решение алгебраических уравнений большой размерности, разряженные матрицы и т.д.
Раньше двухмерные задачи (теплопередача, электромагнетизм) делал в Matlab на основе метода контрольного объема (по Патанкару) и на основе метода конечных разностей.
Более сложные задачи на основе метода конечных элементов решал специализированном пакете для математического моделирования COMSOL Multiphysics.

Для старта в С++ полистал первое что попалось под руку «Шилдт Г. C++ Руководство для начинающих. 2005». Очень скучно – но с чего-то же надо начинать. Что читать дальше и в какой последовательности что бы почуять С++ и особенно ту часть С++, которая нужна будет при освоении численных методов? Какие книжки должен прочесть каждый пишущий на С++?!

Люблю книжки с нетривиальными примерами – так лучше в память заходит и не скучно читать. Почти все, что изложено в книге «Метьюз. Численные методы MATLAB» мне понятно. Хотелось бы такую же книгу на С++, что бы более детально познакомиться с языком С++ и в то же время не скучать.
Стоит ли читать «Седжвик Р. Фундаментальные алгоритмы на C++»?! Или там не показаны «плюсы» С++?
Перед тем как читать книгу «William H. Press et al. Numerical Recipes The Art of Scientific Computing. Third Edition» - какие книги надо пролистать по С++, что бы не испытывать проблем с языком С++, при выполнении этих примеров?
Есть ли еще что-нибудь серьезное на С++ с уклоном на математические алгоритмы, численные методы, решение уравнений в частных производных, обыкновенные дифференциальные уравнения, работу с матрицами и т.д.?! Есть ли по этой теме что-нибудь на русском или только на английском?
На Fortran есть любопытные книжки по численному решению уравнений «Computational Physics-Fortran Version», «Fortran code for the book Computer simulation of liquids», «Numerical recipes in parallel Fortran», кое что на русском, но на С++ что то подобные книги мне не встречались.

Спасибо за внимание!

[Ed_Em]

fuzzy2006 в сообщении #266710 писал(а):

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

Честно говоря, сколько уже работаю с численными методами (в основном, обработка изображений), никогда не видел нужны в С++. Под С хватает разных математических библиотек, и если вам не нужно писать проект на несколько сот страниц кода, ИМХО, С++ не нужен.
С другой стороны, при работе с матрицами мощь С++ может оказаться полезной для введения классов векторов и матриц, перегрузки арифметических операторов и т.п. Есть у меня книжка "астрономия на ПК", так в ней для краткости изложения все примеры на С++.
А вам, думаю, действительно полезно будет почитать "Numerical Recipes", а до этого, для понимания основ С++ - хотя бы того же Лафоре (Страуструпа сразу читать не советую - уж больно много информации на вас свалится, а вот после Лафоре - можно).

[fuzzy2006]

Не могу найти в сети «астрономию на пк». Но нашел « Astronomy on the Personal Computer et al. Astronomy on the Personal Computer. 2nd Edition ». Правда книга старая (94 год) и код там на не С++. Но задачки интересные вроде бы. Это эта книга, но "переписанная" на С++?

Книги с уклоном на математику, матрицы, численные методы по чистому С для начала думаю будут тоже полезны.

В будущем вероятно что чистого С может и не хватить.
Уточняю суть проблемы и интерес к С++. Часто надо рассчитывать различные электротехнологические установки на основе численных методов (математическое моделирование, метод конечных элементов, метод конечных разностей и другие численные методы). Многое считаю используя связку Matlab и специализированный пакет для матмоделирования COMSOL Multiphysics. Но все чаще упираюсь в потолок – то алгоритм решения нелинейных уравнений разработчиками написан дыряво, то идет переполнение памяти (матрица не влазит) при решении задач большой размерности, то не могу заложить нестандартную математическую модель в COMSOL и т.д. Постоянно приходиться плясать с бубном и как то латать дыры. Вот и подумал что надо постепенно, не торопясь, в качестве хобби, нестандартные математические модели рассчитывать/писать на каком-нибудь серьезном языке. Численные методы в основном все на Fortran реализованы. Низнаю с чем это связанно – с тем что на Fortran быстрее создавать приложения или с какими-то ограничениями С++.

В описании на озон.ру к книги «Рыжиков. Современный Фортран» высказывается мнение:
«Автор данного учебника — опытный программист и преподаватель, заслуженный деятель науки РФ. Книга представляет собой апологию современного Фортрана. Автор убедительно доказывает, что лучший язык программирования нестандартных вычислений — это Фортран». Книгу Рыжикова Ю. И. найти в сети не могу, поэтому не знаю аргументации и «убедительного доказательства».

Но я вижу две книги «Langtangen, Computational Partial Differential Equations, Numerical Methods and Diffpack Programming» и «Langtangen, Tveito. Advanced Topics in Computational Partial Differential Equations: Numerical Methods and Diffpack Programming». Вижу какие нестандартные расчеты делали авторы этих книг. Вижу универсальный подход авторов к решению различных задач матмоделирования. Там все на С++, поэтому то и делаю ставку на С++.

Естественно самостоятельно взвесить все плюсы и минусы С++ и Fortran, провести сравнительный анализ этих языков в приложении к задачам математического моделирования и численным методам не могу.

[Ed_Em]

Цитата:

Но нашел « Astronomy on the Personal Computer et al. Astronomy on the Personal Computer. 2nd Edition ». Правда книга старая (94 год) и код там на не С++.
Но задачки интересные вроде бы. Это эта книга, но "переписанная" на С++?

Она. Только перевод более позднего издания (на С++, к книге прилагался диск с исходниками).

[Фантом]

fuzzy2006 в сообщении #267656 писал(а):

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

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

Если хочется что-то похожее на C++, то лучше писать на чистом C. Разницы с точки зрения вида кода почти не будет, но качество компиляторов для вычислительных задач - выше.

А еще лучше пользоваться Фортраном. Во-первых, производительность кода максимальна, во-вторых, язык предназначен именно для вычислительных задач (много мощных встроенных языковых средств, программы лучше читаются и, как следствие, поддерживаются).

fuzzy2006 в сообщении #267656 писал(а):

Численные методы в основном все на Fortran реализованы. Низнаю с чем это связанно – с тем что на Fortran быстрее создавать приложения или с какими-то ограничениями С++.

И то, и другое. Конечно, принципиально на C++ можно написать все, что угодно, но вот сколько времени займет написание и, главное, отладка...

[p51x]

Что можно такое написать на Фортране, что займет значительно больше времени в С++?
И какие проблемы с отладкой?

-- Сб дек 05, 2009 01:26:01 --

Фантом в сообщении #268070 писал(а):

и другое.

Какие же ограничения С++ мешают на нем писать математику?

[Фантом]

p51x в сообщении #268083 писал(а):

Что можно такое написать на Фортране, что займет значительно больше времени в С++?

Напишите, например, банальный метод Гаусса. Скорость счета будет сравнимой, а вот скорость написания...

p51x в сообщении #268083 писал(а):

Какие же ограничения С++ мешают на нем писать математику?

Ну, например, отсутствие инструментария для работы с матрицами. Его, конечно, можно написать и самому - но смысл?

[p51x]

Фантом в сообщении #268090 писал(а):

а вот скорость написания...

Написал минут за 10 со всеми проверками... и с чаем.

Фантом в сообщении #268090 писал(а):

отсутствие инструментария для работы с матрицами

А подробнее?

[nestoklon]

Фантом в сообщении #268070 писал(а):

А еще лучше пользоваться Фортраном. Во-первых, производительность кода максимальна

Ну, по этому пункту неправда ваша. Уже лет 10 как никакой разницы.
Говорят, правда, фортран паралелится проще. Но обычная скорость выполнения уже давно одинакова.

[Фантом]

p51x в сообщении #268116 писал(а):

Написал минут за 10 со всеми проверками... и с чаем.

Результат покажете?

p51x в сообщении #268116 писал(а):

А подробнее?

А Вы Фортран знаете? Если да - подробности и так известны. Если нет - о чем мы спорим?

nestoklon в сообщении #268118 писал(а):

Ну, по этому пункту неправда ваша. Уже лет 10 как никакой разницы.

Ну, ссылаться на личный опыт немного моветон, поэтому посмотрите, например, тут: http://www.cs.rpi.edu/~szymansk/OOF90/performance.html.

[Maslov]

Фантом в сообщении #268282 писал(а):

nestoklon в сообщении #268118 писал(а):
Ну, по этому пункту неправда ваша. Уже лет 10 как никакой разницы.

Ну, ссылаться на личный опыт немного моветон, поэтому посмотрите, например, тут: http://www.cs.rpi.edu/~szymansk/OOF90/performance.html.

Судя по всему, это данные более чем 10-летней давности: последний из используемых источников "To appear in Proc. Eighth SIAM Conference on Parallel Processsing for Scientific Computing, March 14-17, 1997".
Кстати, RS6000 уже 10 лет как не производится.

[Фантом]

Maslov в сообщении #268304 писал(а):

Судя по всему, это данные более чем 10-летней давности: последний из используемых источников "To appear in Proc. Eighth SIAM Conference on Parallel Processsing for Scientific Computing, March 14-17, 1997".

Насколько я помню, это где-то 2001-2002 годы. Но более свежего и при этом достаточно хорошего сравнения мне просто не попадалось.

[Circiter]

2fuzzy2006
Попробуйте полазить по oonumerics.org.

[nestoklon]

Фантом в сообщении #268282 писал(а):

поэтому посмотрите, например, тут: http://www.cs.rpi.edu/~szymansk/OOF90/performance.html.

http://shootout.alioth.debian.org/u32/fortran.php

[Фантом]

nestoklon в сообщении #268391 писал(а):

http://shootout.alioth.debian.org/u32/fortran.php

Я же писал про "достаточно хорошее сравнение". А там этим явно занимались люди, не знающие того, что они сравнивали. Вот, чтобы далеко не ходить, возьмем первый же тест (N-body) на Фортране, первую же процедуру из него:

  subroutine offsetMomentum(k, bodies)
    integer, intent(in) :: k
    type(body), dimension(:), intent(inout) :: bodies
    real*8 :: px, py, pz
    px = 0.0d0
    py = 0.0d0
    pz = 0.0d0
    do i=1,size(bodies)
       px = px + bodies(i)%vx * bodies(i)%mass;
       py = py + bodies(i)%vy * bodies(i)%mass;
       pz = pz + bodies(i)%vz * bodies(i)%mass;
    end do
    bodies(k)%vx = -px/SOLAR_MASS
    bodies(k)%vy = -py/SOLAR_MASS
    bodies(k)%vz = -pz/SOLAR_MASS
  end subroutine offsetMomentum

Это не программа на Фортране. Это "подстрочный перевод" программы на C++ на Фортран, не использующий кучу возможностей последнего.

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

  subroutine offsetMomentum(k, N, mass, velocs)
    integer, intent(in) :: k,N                                      !  номер тела и общее количество
    real(8), dimension(1:N), intent(in) :: mass             ! отдельно массы
    real(8), dimension(1:3,1:N), intent(inout) :: velocs  ! отдельно скорости

    velocs(:,k)=-matmul(velocs,mass)/SOLAR_MASS
  end subroutine offsetMomentum

Все. Содержательная часть состоит из одной строки. Причем очевидно, что в нормальном коде эта процедура вообще не нужна (она там вызывается один раз с одним значением параметра k), так что эту строку проще сразу вставить вместо вызова процедуры. Получившийся "код" (из одной строки ) заметно лучше воспринимается, поскольку это попросту переписывание математической модели "один к одному". Остальную часть программы перелопачивать лень, но, думаю, очевидно, что и там все сворачивается примерно таким же образом.

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