[Iska]

Это вы мне фортранщику, который десять лет занимался проекционно-сеточными методами пишете ...???... Я не только сам кодировал, но и смотрел/разбирал исходные тексты больших промышленных программных комплексов, --- как америкосы это делают... Как правило за ВСЁ отвечает вызывающий модуль/программа, которая и генерирует данные. Хотя в зависимости от алгоритма порою и вниз задачу спустить можно »

Да, это я Вам, как художник художнику бывший фортранщик (ассемблерщик, бейсиковец, сишник, паскалевец, проложец и фокпровед) фортранщику, пишу: процедура/функция, как программный модуль, должна представлять собой идеальный «чёрный ящик». И, в данном случае, она обязана проверять, что переданный параметр — матрица, и что эта матрица — квадратная.

И мне крайне странно слышать противное от человека, не понаслышке знакомого именно с фортраном: ведь именно в нём были заложены данные базовые основы.

[Tau_0]

я Вам, как художник художнику »

Когда я писал свой предыдущий пост, то имел в виду, что очень накладно и глупо делать проверки там, где ошибок быть в принципе быть не должно… А подпрограмма в цикле из вызывающейй должна обрабатывать десятки тысяч элементов (пусть это будут "квадраты"). А вот почему я из тела основной программы вынес это дело в подпрограмму – значит был резон. Но это слишком далеко в сторону…

Я не видел ни одного человека, который бы додумался при отладке , что-то вводить и выводить с консоли… Эта задачка для кадетов, которых в воспитательных и образовательных целях учат зубной щёткой пол в казарме мыть…
Лично я бы сделал акцент именно на численной стороне алгоритма --- его красивости…

ЗЫ Пиписьками не меряясь, но вот в качестве флуда мои представления:
1. Бейсик --- язык для идиотов…
2. Ассемблер – он и есть ассемблер. Там почти ничего при получении адреса своей системной таблицы не проверишь. Дай Бог хоть с плохим RC назад вернуться, а не "прыгать с парашутом"… В самом начале с ассемблера начинал --- честно отпахал 3 года призыва.
3. На C, С++ кодировал немного --- не понравился. Телеграфный код, а не язык
4. Почти 4 года (ещё под DOS) кодировал на Modula 2. Этоn язык был покрасившее чем учебный Pascal. Из них три года делал дурные ускорители FoxPro
5. А вот Prolog на зуб не пробовал --- это круто…

А любимым остался Fortran и численные методы... А если ещё выше, то Физика и Математика, которые за этим делом стоят.
Язык --- это не самоцель, но системное/логическое программирование это одно, а численные методы это совсем другое.

[Iska]

Когда я писал свой предыдущий пост, то имел в виду, что очень накладно и глупо делать проверки там, где ошибок быть в принципе быть не должно… А подпрограмма в цикле из вызывающейй должна обрабатывать десятки тысяч элементов (пусть это будут "квадраты"). »

Ход Ваших мыслей понятен, но в целом — неверен.

5. А вот Prolog на зуб не пробовал »

Можно просто ради интереса почитать какой-нибудь приличный учебник — язык с машиной вывода сам по себе очень красив. Читается легко.

[Tau_0]

Можно просто ради интереса почитать какой-нибудь приличный учебник — язык с машиной вывода сам по себе очень красив. Читается легко. »

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

Ход Ваших мыслей понятен, но в целом — неверен. »

О моде и вкусах не спорят…, --- это всего касается...

А бессмертные слова Эстера Дейкстры гласят, ---“Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”...

[Iska]

Читать это одно (где-то несколько неплохих книг у меня много лет пыляться...), а пробовать на реальной нужной задаче это совсем другое. Пока такой задачи у меня нет. »

Не спорю. Я просто предлагал почитать, чтобы получить чисто эстетическое наслаждение. Например, хорош Иван Братко.

О моде и вкусах не спорят…, --- это всего касается... »

Это не мода, и не вкус. Это требование.

А бессмертные слова Эстера Дейкстры гласят, ---“Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”... »

А это вовсе не ООП . Это то самое набившее оскомину cтруктурное программирование, к созданию которого и приложил руку Эдсгер.

[Tau_0]

Это то самое набившее оскомину cтруктурное программирование, к созданию которого и приложил руку Эдсгер. »

Тогда мне совсем непонятен полёт Вашей высокой мысли...
Продолжим однако, оно того стОИт… Заодно и проверим фортранщика на зуб…
Вот Вам код подпрограммы всего на двух страничках…
LU_73
LU_74

Это не деЦЦкий код. Это из одного серьёзного пакета для FEM/МКЭ, написанного ещё на легендарном FORTRAN 66 для DEC/VAX. По крайней мере код профилирован, и поверьте мне на слово, более чем удовлетворяет требованиям структурного программирования… Как сверху вниз, так и снизу вверх, а также в любом направлении…

Речь идёт в целом море “квадратов и квадратиков” и подпрограмм в пакете полно… Но ни в одной компоненте не найдёте юниорских, так милых Вашему сердцу проверок…

Добавлено
=======
Нашёл pdf оригинала -- его проще обозреть...
ComputerSolution of Sparse Linear Systems

[XPEHOMETP]

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

[Tau_0]

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

А пример решения этой задачки приведен на кибере
C++ - Проверить является ли квадратная матрица " магическим квадратом"