Oleg77777ДохтаР,

То есть приспособить мою бд для решения диффуров Методом кон. элементов? В этом совет заключается, да?

Идея интересная, надо будет запомнить. Только штука в том, что у меня уже проекционный алгоритм запрограммирован (типа Качмажа, только круче, параметризованный). Поэтому начать придется с него, чтобы его не забрасывать. Уж больно ловко он матрицы вертит.


Нет , это был намек , на то, что бестолку терять время на поиск похожих матриц.
ИМХО это никому не пригодится в реальных расчетах.

Ибо малые изменения на входе могу быть причиной больших изменений в результате.

Oleg77777ДохтаР
Ибо малые изменения на входе могу быть причиной больших изменений в результате.

Могут быть. А могут и не быть.

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

В общем, всякие бывают задачи.


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

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

Oleg77777ДохтаРпропущено...



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

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


А может, и дадут, в силу специфики задачи. Дело в том, что у меня там 95% решений отбраковывается; если решение признано приемлемым, тем же макаром проводится анализ остатков, то есть разностей между рассчитанной моделью и реал. данными. Потом - анализ остатков остатков и т.д., неск. раз, в целях усложнения модели.
Если на каждом шаге лезть в базу и получать правильное решение (которое, конечно, может испортиться, но вряд ли), то решения будут находиться почти все время.
Собственно, мне уже сейчас приходится использовать базу данных решений, которая представляет собой жеваный листок, с которого я временами беру цифры и прописываю их напрямую в исходники.
Если интересно, речь идет об аппроксимациях Паде, то есть, попросту, модель - дробно-рациональная функция. Чтобы усложнить модель, то есть превратить ее в сумму нескольких дробей, надо анализировать остатки, остатки остатков и т.д.

Вывод: конечно, СЛАУ быстрей решить, не залезая ни в какую базу. Но если огромное число решений отбраковывается, не грех и залезть, авось и попадешь в точку локализации. Практика показывает, что скорей попадешь, чем не попадешь.

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

Это не тема БД , это тема теории нечетких множеств, NP задач и Искуственного Интелекта.
Если у тебя есть мысли на тему формализации выше изложенной тобой логики
заходи ко мне на блог

UkraineМне иногда кажется что ДохтаР высокоинтеллектуальный, высокотехнологичный, но бот.


Бот достаточно простой,
но клапан в гарбарж коллекторе,
да, чуть чуть интелектуальный