Comments 22
Вот здесь, кстати, есть занятные бенчмарки и немного рекомендаций по этому вопросу.
Спасибо за статью!
Спасибо за статью!
Сам не пользуюься матлабом. Расскажите, действительно ООП требуется? И для каких задач?
Мне тоже интересно зачем оно там. Если учесть, что большая часть пользователей матлаба — инженера, которых попробуй к простому программированию без каких-либо примудростей приучить…
Но в любом случае спасибо за статью!
Но в любом случае спасибо за статью!
Инженера да, бестолковый народ, необучаемый. То ли дело экономисты и юристы.
Я ни в коем случае не хотел обидеть инженеров и я не говорю, что они глупые. Скорее уж инертные, если человек делает что-то вполне хорошо в экселе, то его сложно пересадить на матлаб, даже если там проще. А уж пересадить еще и на ооп… Собственно многие люди такие, это нормально.
Кстати, а что считают в матлабе юристы? Экономистов я еще могу представить, хотя мне казалось, что обычно они используют другие средства, но юристы для меня загадка.
Кстати, а что считают в матлабе юристы? Экономистов я еще могу представить, хотя мне казалось, что обычно они используют другие средства, но юристы для меня загадка.
На самом деле, с инертностью вы тоже очень зря. Даже инженеры возрастом 70+ отлично владеют матлабом и вполне неплохо программируют. Не все, естественно, многим это вовсе не надо, но не об этом речь — если задача требует использования таких средств разработки, поверьте, хороший инженер все это освоит и будет использовать.
Про экономистов и юристов была ирония. Сомневаюсь, что 99% вообще знают, что это такое. Я не принижаю чьи-то способности — им просто это не нужно
Про экономистов и юристов была ирония. Сомневаюсь, что 99% вообще знают, что это такое. Я не принижаю чьи-то способности — им просто это не нужно
Возможно мне такие попадаются:), но я довольно долго пытался заставить многих инженеров (студентов и аспирантов) перейти из экселя в матлаб и упростить себе жизнь. Поэтому такое мнение и сложилось. Т.е. когда вариантов других нет, то они пользуются матлабом, а когда привыкли к чему-то другому, пусть и не столь эффективному, тогда все тяжко.
я — экономист. 90% времени по своей работе сижу в матлабе. что со мной не так?
Это же не java, использование ООП не обязательно.
Лично мне так проще, и я очень рад, что его туда добавили.
Лично мне так проще, и я очень рад, что его туда добавили.
Ну, задачи на матлабе решаются разные, иногда очень нужно ООП, хотя бы взять банальный пример какого-нибудь игрового алгоритма или, как скажем один из моих преподавателей, писал на матлабе симуляцию прохождения флюида через пористую среду с визуализацией. Как только задача разрастается, а таких алгоритмов просто полно, сразу ООП способно дать ощутимую пользу.
Чтобы быть менее абстрактным, рассмотрим пример оптимизационной задачи с ограничениями в виде граничной задачи. Тут совершенно легко строится, возможно не самая лучшая, объектная модель, которая отделяет, скажем представление оптимизационной задачи от представления граничной задачи, плюс классы для того, чтобы доставать данные из базы, плюс класс, который управляет расчетами на разных машинах. Класс, отвечающий за визуализацию и т.д. Вопросов много. Повторюсь, что это не модель как я ее вижу, а пример просто.
Конечно, как уже писали, что не многие инженеры готовы писать код, но такие есть и по моему мнению таких не так уж и мало. А задачи встречаются очень сложные, которые, конечно, можно решить иначе, но ООП дает просто удобный инструмент для этого. Можно, конечно, рассмотреть функциональный подход, но такового, насколько я знаю в матлабе особенно и нет, а структурное программирование только все усложнит. Как-то так)
Чтобы быть менее абстрактным, рассмотрим пример оптимизационной задачи с ограничениями в виде граничной задачи. Тут совершенно легко строится, возможно не самая лучшая, объектная модель, которая отделяет, скажем представление оптимизационной задачи от представления граничной задачи, плюс классы для того, чтобы доставать данные из базы, плюс класс, который управляет расчетами на разных машинах. Класс, отвечающий за визуализацию и т.д. Вопросов много. Повторюсь, что это не модель как я ее вижу, а пример просто.
Конечно, как уже писали, что не многие инженеры готовы писать код, но такие есть и по моему мнению таких не так уж и мало. А задачи встречаются очень сложные, которые, конечно, можно решить иначе, но ООП дает просто удобный инструмент для этого. Можно, конечно, рассмотреть функциональный подход, но такового, насколько я знаю в матлабе особенно и нет, а структурное программирование только все усложнит. Как-то так)
Хотя я, на данный момент, если нет каких-то прямо требований именно к матлабу, так как подавляющее большинство задач можно решить и без него, отдал бы предпочтение связке pythhon+SciPy+matplotlib. Понятно, что это не серебряная пуля, но часто этого более чем достаточно, а python все-таки поинтереснее и мощнее язык, чем матлабовские скрипты. Да и стоит это в… да ничего не стоит) Вот, в убунте уже предустановлено) Сиди и хреначь)
Т.е. по сути для борьбы с чрезмерной сложностью системы?
Приходилось по учёбе писать симулятор СМО с кучей генераторов. Чтобы не запутываться в безмерном количестве массивов и жутких доступах к ним — пришлось из идеологических соображений применить ООП.
Не знаю, зачем там использовать ооп (наследование и инкапсуляцию). Объектный паттерн делается на структурах и функциях
Я очень плотно использую перекрытие функций. У меня множество классов «портфель пассива» (страховая специфика), у каждого портфеля свои формулы рассчёта каких-то величин, которые в конечном итоге нужно вместе будет обработать (суммировать наши обязательства, например). Самое интуитивное решение — класс «портфель пассивов» с набором общих и абстрактных функций, которые потом каждый реализует по-своему. А вызывающий всё это общий класс не заморачивается, какие именно портфели обрабатываются сегодня.
Вообще, определение интерфейсов (абстрактных классов в жаргоне ООП MatLab) очень помоает разделить работу. написал интерфейс, отдал реализацию одному программисту, затем stub на интерфейс — реализацию другой стороны можно отдать второму программисту. Когда оба закончат работать, скорее всего их коды сложатся в одну программу без какой-то дополнительной доработки. И во время работы у них полная независимость друг от друга.
Вообще, определение интерфейсов (абстрактных классов в жаргоне ООП MatLab) очень помоает разделить работу. написал интерфейс, отдал реализацию одному программисту, затем stub на интерфейс — реализацию другой стороны можно отдать второму программисту. Когда оба закончат работать, скорее всего их коды сложатся в одну программу без какой-то дополнительной доработки. И во время работы у них полная независимость друг от друга.
Хех, наткнулся на этот тред в гугловыдаче. Тогда ответ почему-то пропустил.
Матлаб — динамический язык, если что-то сломается, то сломается в рантайме. Поэтому все эти абстрактные классы мало чему помогут, они придуманы для проверки типов во время компиляции. Нужны тесты. ООП в матлаб добавили про принципу ПХП — тупо склонировали яву на динамическую почву потому что очень просили. На самом деле достаточно объектов в стиле SICP.
function A = constructorA(a, b, c)
%конструктор
A.a = a;
A.b = b;
A.c = c;
%методы
function f = foo(x)
f = a + b + c + x
end
function b = bar(y)
b = foo(y) + 1;
end
%foo — публичный метод
A.foo = foo;
%bar — приватный, потому что мы не выносим его в словарь
end
Наследование делается так:
function B = constructorB(a, b, c, d)
B = constructorA(a, b, c);
B.d = d;
%baz — статический метод, он не захватывает B
B.baz = baz;
end
Возможности тут те же самые, но есть и плюсы гибкости словарей — не нужны все эти фабрики из явы и прочее (см. презентацию lack of design patterns in python). Можно, например, написать функцию Logger, которая из любого такого объекта будет делать логируемый: a = Logger(constructorA(1,2,3)). Перловый скрипт для документации придется выдумать самому конечно.
Для описания интерфейсов в динамических языках удобнее писать тесты, просто потому что безтиповые интерфейсы мало чему помогают.
Наконец, в большинстве случаев достаточно просто писать функции, принимающие ФВП, как сделано в большинстве тулбоксов. Для реализации расчетов самое то, потому что если я использую матлаб, я хочу иметь возможность написать
fminsearch(@(x) foo(1,2,3,4)), а не городить класс Foo1234SearchStrategy. Подозреваю, что в вашей предметной области функциональная декомпозиция лучше объектной.
Матлаб — динамический язык, если что-то сломается, то сломается в рантайме. Поэтому все эти абстрактные классы мало чему помогут, они придуманы для проверки типов во время компиляции. Нужны тесты. ООП в матлаб добавили про принципу ПХП — тупо склонировали яву на динамическую почву потому что очень просили. На самом деле достаточно объектов в стиле SICP.
function A = constructorA(a, b, c)
%конструктор
A.a = a;
A.b = b;
A.c = c;
%методы
function f = foo(x)
f = a + b + c + x
end
function b = bar(y)
b = foo(y) + 1;
end
%foo — публичный метод
A.foo = foo;
%bar — приватный, потому что мы не выносим его в словарь
end
Наследование делается так:
function B = constructorB(a, b, c, d)
B = constructorA(a, b, c);
B.d = d;
%baz — статический метод, он не захватывает B
B.baz = baz;
end
Возможности тут те же самые, но есть и плюсы гибкости словарей — не нужны все эти фабрики из явы и прочее (см. презентацию lack of design patterns in python). Можно, например, написать функцию Logger, которая из любого такого объекта будет делать логируемый: a = Logger(constructorA(1,2,3)). Перловый скрипт для документации придется выдумать самому конечно.
Для описания интерфейсов в динамических языках удобнее писать тесты, просто потому что безтиповые интерфейсы мало чему помогают.
Наконец, в большинстве случаев достаточно просто писать функции, принимающие ФВП, как сделано в большинстве тулбоксов. Для реализации расчетов самое то, потому что если я использую матлаб, я хочу иметь возможность написать
fminsearch(@(x) foo(1,2,3,4)), а не городить класс Foo1234SearchStrategy. Подозреваю, что в вашей предметной области функциональная декомпозиция лучше объектной.
Если проект сложный, с множеством отдельных блоков, каждый из блоков может быть реализован несколькими разными способами, и хочется всё это сделать достаточно элегантно, чтобы не переписывать код перед каждым запуском с новой конфигурацией — я не вижу, как сделать это без ООП.
Ну и у меня вообще привычка, очень давно программирую, 20 лет с ООП, с трудом представляю, как можно делать иначе :-)
Ну и у меня вообще привычка, очень давно программирую, 20 лет с ООП, с трудом представляю, как можно делать иначе :-)
Так зачем может понадобиться ООП — понятно =) Не совсем понятно, зачем оно вместе с МатЛабом, а не отдельно.
Наверное главное преимущество в использовании существующих библиотек и наработок.
С другой стороны и для других ЯП с поддержкой парадигмы ООП существуют математические библиотеки (тот же NumPy и SciPy), плюс реализация ООП может быть более элегантной и не требующей особых оптимизаций.
Наверное это больше дело привычки.
Наверное главное преимущество в использовании существующих библиотек и наработок.
С другой стороны и для других ЯП с поддержкой парадигмы ООП существуют математические библиотеки (тот же NumPy и SciPy), плюс реализация ООП может быть более элегантной и не требующей особых оптимизаций.
Наверное это больше дело привычки.
Например, в компании, в которой я работал ранее, мы использовали матлаб для исследований в области распознавания речи и прочей работы со звуком. Уже много для работы со звуком в матлабе реализовано+фреймвёрки для нейронных сетей (без которых сейчас никуда): вот две основных причины выбора матлаба. Когда компонент был реализован, он, с помощью опять же штатных средств матлаба, генерил сиплюсплюсный код, который шел в продакшн.
Много костылей, конечно, было. Но скорость исследований и реализации новых фичей была высокой именно благодаря матлабу. И да, мы исспользовали и ООП, и просто процедурное программирование. К слову сказать, реализованные компоненты, которые генерились в сиплюсплюсный код писать в процедурах, так как матлабовский генератор сиплюсплюсного кода не умел это делать, если матлабовский код был ООП.
Много костылей, конечно, было. Но скорость исследований и реализации новых фичей была высокой именно благодаря матлабу. И да, мы исспользовали и ООП, и просто процедурное программирование. К слову сказать, реализованные компоненты, которые генерились в сиплюсплюсный код писать в процедурах, так как матлабовский генератор сиплюсплюсного кода не умел это делать, если матлабовский код был ООП.
Сравнивать Matlab и C++ некорректно, у них разные аудитории и разные задачи.
Среда Matlab нацелена на людей не являющихся профессионалами в программировании, но вынужденных решать задачи связанные с обработкой данных требующих инструмента посложнее Excel.
Поэтому чем ниже барьер входа в эту среду, чем круче learning curve тем лучше. Изыски вроде ООП давайте оставим профессиональным программерам, им за это деньги платят. Нам, химикам, платят за другое.
Среда Matlab нацелена на людей не являющихся профессионалами в программировании, но вынужденных решать задачи связанные с обработкой данных требующих инструмента посложнее Excel.
Поэтому чем ниже барьер входа в эту среду, чем круче learning curve тем лучше. Изыски вроде ООП давайте оставим профессиональным программерам, им за это деньги платят. Нам, химикам, платят за другое.
Sign up to leave a comment.
MatLab и ООП, оптимизация