Sep. 1st, 2004

fpaint: (Default)
Раздумье затянулось - всё никак не могу сформулировать, как же следует делать сетку. Уже месяц. А с сегодняшнего утра - особенно напряжённо, ибо хочется наконец уже двигаться дальше. Казалось бы, чего проще - матрица объёмов. Да, для ручного забивания числами и последующего любования сойдёт и двумерный массив. Однако если нужно делать модель, если есть несколько величин, для каждой нужна своя нерегулярная сетка, для которой важна геометрия (размеры и координаты каждого узла), и решать для каждого объёма уравнения с величинами из других объёмов и сеток (плюс эффективность, гибкость, простота использования и т.д.), то становится грустно. Принципиальный вопрос - делать ли сложными объёмы, чтобы они могли сами по себе решать заданные для них уравнения (тогда будет множество классов объёмов под каждую величину, и судя по всему, сетки тоже будут разными классами, но при этом вычислительная часть будет простой и понятной), или сделать объёмы простыми и универсальными, а всё самое интересное вынести в классы сеток (тогда классы будет гибче и переюзабельнее, но вычислительная часть усложнится). Или вообще все вычисления делать в классе модели, с универсальной сеткой из универсальных объёмов. Или найти какой то компромис... В общем, всё упирается в то, как будет смотреться код. В первом случае так:

здесь=а1*справа+а2*слева+а3*сверху и т.д. поделить на а0, или что-то в этом духе. Красота, но объёмы специализированы на одной величине, и в каждом из них хранится море "полезной" информации: указатели на соседей, на другие сетки, на модель в целом и т.д. И всё это нужно будет скрупулёзно заполнять в начале, при инициализации. И внимательно следить, чтобы не было ошибок, потому что что-то и будет глючить, то не алгоритм, а данные.

Во втором случае:

ячейка(и,жи)=а1*ячейка(и+1,жи)+... и т.д.

А в третьем и вовсе:

сетка_раз->ячейка(и,жи)=а1*сетка_раз->ячейка(и+1, жи)+.... Другая крайность. Очень легко сделать ошибку в индексе, или, например, сослаться на другую сетку вместо нужной. Сложно будет потом найти, и практически невозможно написать автоматический тест для проверки.

Совсем уж не по себе становится от чтения докторской диссертации на тему разработки универсальной библиотеки сеточных алгоритмов (здесь), где во введении во всех красках расписываются ужасы несовместимости различных сеток, даже от похожих задач, и то как сложно бывает наращивать готовую программу, если в основе алгоритмов сидит неверно выбраная структура данных. Я не совсем уверен, что шаблоны классов и generic programming - это окончательное решение всех проблем. Потому как одна только документация к этой библиотеке весит 25 мегобайт, а сами исходники - 2. При этом упорно не компилируются.

Хочется, чтобы классы были универсальными и все вычисления шли в модели, но при этом код был простой и понятный. А для простоты нужно инициализировать дополнительные переменные на каждой итерации. Если пытаться хранить их где нибудь, то теряется универсальность. Или можно использовать какие ни будь дополнительные классы, как некий интерфейс, что то вроде итерраторов... Не знаю. А вообще, неплохой вариант - не думаю, что инициализация занимает так уж много машинного времени, по сравнению с расчётами. Если сделать для каждой подзадачи отдельный класс, с инициализацией дополнительных переменных в конструкторе и вычислениями внутри какой ни будь из функций (а общие вещи можно вынести в базовый класс). Только опять таки, всё надо проверять и перепроверять...

June 2012

S M T W T F S
     12
3456789
10111213141516
171819202122 23
24252627282930

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 11th, 2025 09:44 pm
Powered by Dreamwidth Studios