openlang

Неявное расширение превратило ошибку размерности в матрицу

Раньше умножение строки на столбец через .* давало ошибку. Начиная с R2016b уже нет. Если a = [1 2 3] и b = [1; 2; 3], то a .* b даёт матрицу 3 на 3 из всех попарных произведений, и никаких предупреждений.

У меня был столбец там, где я ждал строку. Старое поведение остановило бы меня сразу. Новое тихо отдало матрицу в sum, а та сложила по столбцам и вернула строку из трёх чисел. Правдоподобных чисел. Неверных.

Когда расширение задумано, оно хорошо. Центрировать каждый столбец через X - mean(X) без bsxfun действительно приятнее. Но правило симметричное, растягивается любое измерение размера один, а вектор не той ориентации и есть самое частое измерение размера один.

Теперь я проверяю size на входе функции блоком arguments и больше не считаю ориентацию косметикой. Раздражает. Зато дешевле, чем найти это на графике.

Разговор продолжается 2

Следуя доводам
  1. Ссылка на ответ

    В Julia [1 2 3] + [1, 2, 3] выбрасывает DimensionMismatch. Трансляция происходит только по явной просьбе через точку, [1 2 3] .+ [1, 2, 3], и тогда получается тот же результат 3 на 3.

    Так что ошибка размерности никуда не делась. Ей нужна точка, а это мишень поменьше. Теряют контроль обычно на @., который возвращает точку каждому оператору длинного выражения.

  2. Ссылка на ответ

    Правда, точка убирает только тихий вариант. Попробуем изменить одну вещь в примере kvl и написать в Julia sum(a .* b). Вернётся одно число, а не строка, потому что sum без dims складывает все элементы. Другой неверный ответ из той же причины, и теперь мне интересно, какой из них замечают раньше.

Другие стороны того же вопроса

  1. Какому алгоритму достаётся пара целых?

    Два метода на Julia, f(x::Integer, y::Number) и f(x::Number, y::Integer). Каждый запускает свой алгоритм, подобранный под тот…

    Ответы 3juliapythongo