Волновое уравнение в КР: условие устойчивости и визуализация

[Pphantom]

byulent в сообщении #1078289 писал(а):

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

Так скорость движения графика (по крайней мере у меня) определяется задержкой, выставляемой между кадрами в gif-ке, реальный счет идет на порядки быстрее. А вот почему он у Вас через ноль не проходит - надо искать, и именно в коде, а не в алгоритме.

[Munin]

byulent в сообщении #1078283 писал(а):

А что здесь может быть не так? Я делал всё по алгоритму. Если вы говорите, что вам якобы сложно разбирать код, то тут собственно вся модель находится в 3 методах: конструкторе, UAllocate и getNext.

Залез всё-таки в вашу кашу. Людям, не имеющим опыта в ООП, лучше ООП не применять. Особенно там, где ООП не к месту, например, в чисметодах.

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

Во-вторых, у вас нарушена инкапсуляция: вы выдаёте клиенту внутренние массивы объекта.

В-третьих, это, видимо, и ведёт к глюкам: в getNext вы понятия не имеете, что переданный в аргументе массив double *a может совпадать с одним из внутренних массивов объекта, и в результате, ваши итерации могут приобретать какой угодно, самый неожиданный и фантастический смысл.

[byulent]

Munin в сообщении #1078350 писал(а):

byulent в сообщении #1078283 писал(а):

А что здесь может быть не так? Я делал всё по алгоритму. Если вы говорите, что вам якобы сложно разбирать код, то тут собственно вся модель находится в 3 методах: конструкторе, UAllocate и getNext.

Залез всё-таки в вашу кашу. Людям, не имеющим опыта в ООП, лучше ООП не применять. Особенно там, где ООП не к месту, например, в чисметодах.

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

Во-вторых, у вас нарушена инкапсуляция: вы выдаёте клиенту внутренние массивы объекта.

В-третьих, это, видимо, и ведёт к глюкам: в getNext вы понятия не имеете, что переданный в аргументе массив double *a может совпадать с одним из внутренних массивов объекта, и в результате, ваши итерации могут приобретать какой угодно, самый неожиданный и фантастический смысл.

1. А что делает ООП неуместным в чисметодах? Тем более, это графическое приложение, а раз уж при проектировании ГП нельзя обойтись без ООП, дай-ка, думаю, и матмодель в класс заверну...
2. Держите:

Используется синтаксис C++

void Plot::setData()
{
    n = obj->getN()+1;
    x = new double[n];
    U = new double[n];
    for (int i=0; i<n; i++)
    {
        x[i] = 0+i*(obj->getDx());
        U[i] = (obj->getPrev())[i];
    }
    curve->setSamples(x, U, n);
}

void Plot::redraw()
{
    if (fabs(tcurr-obj->getDt())<0.000001) U=obj->getBeg();
    else U = obj->getNext(U, n);
    curve->setSamples(x, U, n);
    replot();
}

3. А разве использование геттеров - это нарушение инкапсуляции?

[arseniiv]

byulent в сообщении #1078398 писал(а):

А что делает ООП неуместным в чисметодах?

Ничего, но от ООП, как и любого инструмента, могут быть и плюсы, и минусы. В объект можно «завернуть» разный набор данных и функций, и не всякий способ этого можно назвать полезным. Иногда полезный способ потребует много оверхеда и т. п..

byulent в сообщении #1078398 писал(а):

А разве использование геттеров - это нарушение инкапсуляции?

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

Итак, у вас действительно упомянутая Munin ошибка тогда. Строка

Unext[​​i]=k*(a[​​i+1]-2*a[​​i]+a[​​i-1])+2*a[​​i]-Uprev[​i];

получается после самой первой итерации («внешней», из предыдущего фрагмента) эквивалентна

Unext[​i]=k*(Unext[​​i+1]-2*Unext[​​i]+Unext[​​i-1])+2*Unext[​​i]-Uprev[​i];

В выделенном куске вы используете изменённое в предыдущей «внутренней» (в методе) итерации значение.

Вообще не следовало вытаскивать из класса ту «внешнюю» итерацию, её тоже надо оформить как метод. Тогда не будет необходимости выдавать массивы наружу.
Плюс, вычисления не должны зависеть от отображения. Иногда есть смысл делать один кадр на несколько шагов вычисления или вообще пустить их в разных потоках. Можно копировать состояние внутреннего массива в переданный специальному методу внешний, или что-то ещё такое.

-- Вт дек 01, 2015 00:12:37 --

(Оффтоп)

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

-- Вт дек 01, 2015 00:18:20 --

arseniiv в сообщении #1078405 писал(а):

ошибка

Может, и ещё есть — не присматривался.

[byulent]

arseniiv в сообщении #1078405 писал(а):

Итак, у вас действительно упомянутая Munin ошибка тогда. Строка

Unext[​​i]=k*(a[​​i+1]-2*a[​​i]+a[​​i-1])+2*a[​​i]-Uprev[​i];

получается после самой первой итерации («внешней», из предыдущего фрагмента) эквивалентна

Unext[​i]=k*(Unext[​​i+1]-2*Unext[​​i]+Unext[​​i-1])+2*Unext[​​i]-Uprev[​i];

То есть проблема в том, что мой метод делает Unext из него самого?

[arseniiv]

Если выражаться неаккуратно, можно сказать и так. Проблема-то не в этом, а в том, что в вычислениях элементов попадаются «разные версии» значений. Не, в методе Зейделя, например, так и задумано, но не везде кроме.

[Munin]

byulent в сообщении #1078398 писал(а):

дай-ка, думаю, и матмодель в класс заверну...

Сначала стоило его написать и протестировать, а потом уже раскладывать по разным единицам инкапсуляции. У вас же "непрозрачно", чего происходит, из-за того, что часть метода в одном объекте, а часть - в другом. Это можно и без ООП совершить, конечно, но отвлекаясь на ООП - особенно легко.

[arseniiv]

(Оффтоп)

Я бы ещё кое-что отметил, о чём в прошлом посте умолчал: у вас есть некоторая куча констант, которые константами именно времени компиляции быть вовсе не обязаны. Раз уж вы имели намерение выделить в класс вычисления, можно было сделать некоторые из тех констант параметрами конструктора. Для каждого объекта при этом их можно хранить в полях и не менять, но для разных объектов они смогут быть разными. Они не выглядят чем-то хуже сделанного параметром количества элементов струны.

Но это уже оффтоп здесь, как и вопрос, почему было не сделать сразу двумерную (или, о Диэдр, параметризованную размерностью) симуляцию.

(Оффтоп №2.)

Вообще, конечно, как выделять и называть функции/методы/классы, не всегда ясно даже по прошествию некоторого времени. Тут полезно смотреть на чужой (но и проверенный на удобство обращения с ним) код. Потому современные IDE (опять же не будем поминать противников IDE) имеют средства, сильно упрощающие рефакторинг. Все нужные механические замены и проверку их корректности. Можно легко рефакторить и проверять, желаемо или нет.

[Munin]

byulent в сообщении #1078416 писал(а):

То есть проблема в том, что мой метод делает Unext из него самого?

Да, причём заметьте, сами вы этого не заметили, а увидели только после того, как вам arseniiv показал. Это и есть минус ООП (поспешного ООП).

Ну, не считая всяких "мелочей" типа потери памяти, и т. п.

[arseniiv]

Munin в сообщении #1078425 писал(а):

Это и есть минус ООП (поспешного ООП).

Так можно было бы написать и без ООП и даже на языке, который не позволяет с массивами того, что позволяет C++. Всё-таки логика неправильно разделена, даже в виде одних только функций утаскивать ту большую итерацию отдельно и соединять с отображением не стоит. Рисование и вычисление не должны друг друга вызывать, пускай их вызывает что-то третье. Отсюда можно уже далеко и безболезненно утанцевать.

-- Вт дек 01, 2015 01:11:03 --

Кстати, я верно понял, что tcurr — это системное время? Это тоже нехорошо. Не надо связывать себе руки. Да и вся конструкция с ним странная. Если надо сначала показать начальное положение, это стоит делать безусловно, а не по сравнению разницы времён с магическим числом (если шаг по времени уменьшить, можно всё поломать, опять же).

А и даже если не системное, всё равно не нужно, если шаг по времени не меняется — а он здесь и не меняется, плюс, опять же, если оно нужно, это общее время должно быть полем того объекта. Предположите, что объектов живёт несколько, и станет немного яснее, что должно быть в них, что быть статическим и одним на класс, а что вообще браться извне.

А ещё в getNext зачем-то параметр n, хотя есть уже соответствующее и одноимённое поле.

[byulent]

Попытался исправить:

Используется синтаксис C++

void Plot::redraw()
{
    for (int i=0; i<n; i++){
        if (fabs(tcurr-obj->getDt())<0.000001) U[i]=(obj->getBeg())[i];
        else U[i] = (obj->getNext(U, n))[i];
    }
    curve->setSamples(x, U, n);
    replot();
}

Не помогло. Гонит мне величины $\to0$, и все положительные.

Используется синтаксис Text

6.70436e-07 1.33992e-06 2.00755e-06 2.67267e-06 3.33463e-06 3.99278e-06 4.64647e-06 5.29506e-06 5.93791e-06 6.5744e-06 7.20389e-06 7.82579e-06 8.43947e-06 9.04434e-06 9.6398e-06 1.02253e-05 1.08002e-05 1.13641e-05 1.19162e-05 1.24562e-05 1.29835e-05 1.34975e-05 1.39978e-05 1.44839e-05 1.49553e-05 1.54116e-05 1.58524e-05 1.62771e-05 1.66855e-05 1.70771e-05 1.74515e-05 1.78084e-05 1.81474e-05 1.84683e-05 1.87707e-05 1.90543e-05 1.93189e-05 1.95643e-05 1.97901e-05 1.99963e-05 2.01825e-05 2.03487e-05 2.04947e-05 2.06203e-05 2.07165e-05 2.08194e-05 2.08908e-05 2.09342e-05 2.0957e-05 2.09591e-05 2.09405e-05 2.09012e-05 2.08414e-05 2.0761e-05 2.06603e-05 2.05392e-05 2.03979e-05 2.02367e-05 2.00556e-05 1.98548e-05 1.96346e-05 1.93952e-05 1.91369e-05 1.88599e-05 1.85645e-05 1.8251e-05 1.79198e-05 1.75712e-05 1.72054e-05 1.6823e-05 1.64243e-05 1.60097e-05 1.55797e-05 1.51346e-05 1.46749e-05 1.42011e-05 1.37137e-05 1.32131e-05 1.26999e-05 1.21746e-05 1.16376e-05 1.10896e-05 1.05311e-05 9.96269e-06 9.38485e-06 8.79821e-06 8.20336e-06 7.60088e-06 6.99137e-06 6.37545e-06 5.75373e-06 5.12682e-06 4.49534e-06 3.85993e-06 3.22121e-06 2.57982e-06 1.93639e-06 1.29155e-06 6.45954e-07 

Вот это он на одной из итераций учудил.

[arseniiv]

Нет предела совершенству.

Т. е. есть ещё что исправлять. (Или с нуля переписать?‥ )

[Pphantom]

byulent в сообщении #1078398 писал(а):

1. А что делает ООП неуместным в чисметодах?

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

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

byulent в сообщении #1078398 писал(а):

Тем более, это графическое приложение,

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

arseniiv в сообщении #1078437 писал(а):

(Или с нуля переписать?‥ )

Скорее всего. Заодно можно и над другими деталями реализации подумать (ну, например, чтобы не заниматься постоянно умножением чего-то там на pow(dt,2)/pow(dx,2), вычисляя это отношение квадратов для каждого узла сетки заново).

[aa_dav]

byulent в сообщении #1078398 писал(а):

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

Тут еще много недоразумений исторически сложилось. "Завернуть матмодель в класс" это вообще не ООП.
Это синтаксический сахарок над структурами. Причём он очень может быть уместен в мат-моделировании - допустим завернуть комплексное число в класс std::complex, перестать страдать ручным выделением памяти и таки использовать std::vector в качестве контейнера чисел, перемножать матрицы на вектора опять таки с помощью классов с перегруженными операторами. И т.п.
Но это не ООП. И вы неумело завернули мат-модель в класс, ага.

[Munin]

aa_dav в сообщении #1078547 писал(а):

"Завернуть матмодель в класс" это вообще не ООП.

+1.

Хотя инкапсуляция - это уже какое-никакое ООП, но вот она-то тут как раз не нужна.