Определитель матрицы в MatLab

[Munin]

Это всё-таки не MatLab, а надстройка. Поскольку он тьюринг-полный, на нём, конечно, можно что угодно написать, вплоть до пакета символьных вычислений. Но не называть же это возможностью самого MatLab-а.

Даже "Mat" в MatLab означает не "математику", а "матрицы", и поэтому пишется не через th.

[photon]

Я Вам скажу, что и без symbolic toolbox Matlab может выполнять символьные операции. Если Вы не в курсе, то лучше не пытайтесь спорить.

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

Даже "Mat" в MatLab означает не "математику", а "матрицы", и поэтому пишется не через th.

Для меня это давно не новость

[ewert]

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

Ошибка возникает из-за всех операций с числами: и сложения, и умножения, и деления. Кстати, от сложения и вычитания - прежде всего.

До тех пор, пока целочисленные значения укладываются в разрядную сетку мантиссы -- операции сложения и умножения округлений не вызывают.

[Munin]

photon в сообщении #602591 писал(а):

Я Вам скажу, что и без symbolic toolbox Matlab может выполнять символьные операции.

Отлично. Верю. Дайте ссылку.

Я ж доверчивый. Даёте ссылку не на то - ну я её и воспринимаю по содержанию.

ewert в сообщении #602615 писал(а):

До тех пор, пока целочисленные значения укладываются в разрядную сетку мантиссы -- операции сложения и умножения округлений не вызывают.

Действительно. Целочисленность я пропустил как-то. Но в общем случае - вызывают.

[photon]

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

Отлично. Верю. Дайте ссылку.

Я ж доверчивый. Даёте ссылку не на то - ну я её и воспринимаю по содержанию.

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

Если Вы имели в виду это, то да, соглашусь - надстройка нужна. Ну так какой язык ни возьми - есть какие-то библиотеки и т.п.

[ewert]

photon в сообщении #602707 писал(а):

Устанавливать тулбокс все равно надо, а использовать можно без него (в смысле, не через него).

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

[photon]

ewert в сообщении #602719 писал(а):

то в каком смысле возможны символьные вычисления не через него?...

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

Что же касается "по умолчанию", то вот на работе у меня нет его - в рамках той лицензии, которая имеется, его нет.

[Munin]

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

[ewert]

Ну, должен получиться ноль; иначе какие ж эти вычисления символьные. Тем более с такой маленькой матрицей -- уж тут-то переполнений рациональной арифметики в принципе не может возникнуть.

[photon]

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

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

Вот с этим сложнее. У меня на работе не установлен symbolic toolbox и при этом выдает в ответе $0$.

A=[1 2 3; 4 5 6; 7 8 9]
A =
     1     2     3
     4     5     6
     7     8     9
>> det(A)
ans =
     0

[ewert]

photon в сообщении #602736 писал(а):

У меня на работе не установлен symbolic toolbox и при этом выдает в ответе $0$.

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

[photon]

Для определенности уточню, что у меня релиз R2007a.

[kopern1k]

У меня R2012a

[ewert]

Хм, а у меня R2009b, и тоже выдаёт ноль. Хотя хэлп уверяет, что детерминант считается с помощью LU-разложения матрицы (на самом деле PLU-разложения) и потом перемножения детерминантов сомножителей. Врёт хэлп: если в лоб вызвать это разложение, то детерминант верхнетреугольного сомножителя вот как раз 6.6613e-16 и выдаёт, а непосредственно det -- всё-таки ноль. Впрочем, хэлп там много чего врёт. Например, он обещает возможность обращений вида [L,U]=lu(A), [L,U,P]=lu(A), [L,U,P,Q]=lu(A) и ещё других, на самом же деле срабатывают только первые два, а на третье уже жалуется "шибко много выходных аргументов".