Регрессия квадратичного полинома

[Alex Krylov]

-> Missir

Yalmip я решил использовать, чтобы сохранить хоть какую-то наглядность при записи ограничений. Чтоб невооруженным взлядом было видно, что есть что. Кому лень связываться с Yalmip, естественно может использвать linprog.

Касательно сомнительности Yalmip... Это один из двух самых популярных парсеров такого рода. Другой - CVX. В данном случае из-за тривиальности легко поработать ручками и обойтись без парсера. Но во многих случаях удобнее все ж таки использовать парсер (экономия времени, избежание возможных ошибок, сохранение наглядности).

[Missir]

Alex Krylov в сообщении #1647130 писал(а):

Это один из двух самых популярных парсеров такого рода

а мне кажется это очередное вредоносное ПО, коим итак доверху нашпигован ПК неискушенного юзера. По крайней мере никакой наглядности или упрощения с его использованием незаметно, скорее всё наоборот. Да и сам matlab давно уже анахронизм, все нормальные юзеры сейчас используют python. Вы бы ещё "для наглядности" привели примеры на Fortran.

[Alex Krylov]

-> Missir

Извините, но не вижу логики в вашем ответе. Fortran - это низкоуровневый язык, язык Matlab - это язык гораздо более высокого уровня, нежели Fortran. А парсеры наподобие Yalmip/CVX - это надстройка еще более высокого уровня. Так как же крайне низкоуровневое может быть подобно крайне высокоуровневому?!!!! Так что не совсем понятно, для чего вы сюда Fortran приплели.

Цитата:

все нормальные юзеры сейчас используют python

Некоторые и с пятого этажа прыгают. За ними бежать прикажете, следуя моде?

[Missir]

Alex Krыlov
не нужно вешать людям "лапшу" на уши, Fortran не только, и не столько низкоуровневый, сколько устаревший и малораспространённый, к тому же в современных вариантах он вполне себе поддерживает линейную алгебру и реализовать решение задачи ТС в нём не так уж и сложно. Только какой в этом смысл, если большинство людей с ним не знакомы и скорее всего он никогда им не понадобится.
Тоже самое, хотя и в меньшей степени, относится к matlab, его сейчас очень мало кто использует. Кто без особой нужды будет устанавливать 20Гб дистрибутивы, которые к тому же далеко не бесплатны, или рыскать по сомнительным online-ресурсам, при наличии более удобной альтернативы в виде python. А вы ещё предлагаете дополнительно к matlab скачивать и устанавливать какую то сомнительную приблуду, которая скорее всего больше никогда и не понадобится. В том то и дело, что из-за этого ваши примеры попросту никто не будет проверять. А python сейчас есть очень у многих, если не у всех.
О какой наглядности вообще речь? Если под ней понимать раскрытие сути задачи, а не рекламу Yalmip. Я же показал, что абсолютно ту же самую систему ограничений, и тот же функционал как у вас, принимает функция linalg, входящая в самые допотопные версии matlab. Какие тогда дополнительные удобства в понимании задачи даёт Yalmip, кроме того, что объявляет о своём существовании? Может наоборот для абстрагирования от сути задачи? Но в таком случае зачем она вообще нужна?

К тому же и ЗЛП вы сформулировали, ни то что бы не правильно, но довольно криво. МНМ традиционно формулируется так:

$$\bf{Xb}+Ie^+-Ie^-=y$$

$$F=\bf \Sigma e^++\Sigma e^- -> min$$

это и нагляднее, и компактнее, и требует для решения гораздо меньше итераций.

[Alex Krylov]

Цитата:

традиционно формулируется так

Можно и так, как вы сказали:
https://dxdy.ru/post1637967.html#p1637967
А можно и эдак, как в данной ветке.

Цитата:

и требует для решения гораздо меньше итераций

Решатель Mosek в любом из вариантов требует ровно 5 итераций, встроенный решатель linprog в обоих случаях - 8 итераций!

[ozheredov]

Missir в сообщении #1647134 писал(а):

Да и сам matlab давно уже анахронизм, все нормальные юзеры сейчас используют python.

Missir, Missir!

Missir в сообщении #1647140 писал(а):

не нужно вешать людям "лапшу" на уши

Матлаб удобнее и логичней Питухона.

[Alex Krylov]

Цитата:

Матлаб удобнее и логичнее Питухона.

В конце концов для дюбителей совсем свободного ПО есть еще GNU Octave!

[ozheredov]

Alex Krylov в сообщении #1647171 писал(а):

В конце концов есть еще GNU Octave!

Вот это как раз ужас ужасный Однажды я запустил свой код на Octave, и он в нём (кто в ком?) не понял примерно половину инструкций. Если выбирать между Питухоном и Octave, то первое уж точно лучше.

[Alex Krylov]

ozheredov в сообщении #1647172 писал(а):

Alex Krylov в сообщении #1647171 писал(а):

В конце концов есть еще GNU Octave!

Вот это как раз ужас ужасный Однажды я запустил свой код на Octave, и он в нём (кто в ком?) не понял примерно половину инструкций. Если выбирать между Питухоном и Octave, то первое уж точно лучше.

Я Octave не пользовался. Написал исходя из деклариуемой языковой совместимости с Matlab. Но как там с этим реально обстоят дела, абсолютно не ведаю.

Цитата:

не понял примерно половину инструкций

Действительно все так плохо? Или может вы какие-нибудь новые расширения языка Matlab пытались в Octave запустить? Даже с переносимостью устоявшихся/базовых языковых конструкций все плохо?

Кстати, а что там с бибилиотеками?

[Missir]

ozheredov в сообщении #1647170 писал(а):

Матлаб удобнее и логичней Питухона

Лично для меня да, но я работаю в нём более 20 лет, так что моё мнение может быть сильно предвзятым. И лично я вынужден признать, что python сейчас наиболее популярен. Этому есть масса причин: разнообразие пакетов, кроссплатформенность и переносимость кода, изобилие обучающих материалов и т.п. Хотя, для тех кто не в курсе, python вырос именно из matlab, по большей части из-за ценовой политики mathworks. По тем же причинам появилась Octave, но она не получила такой популярности как python, т.к. по сути является просто бесплатной копией matlab, и не содержит в себе ничего нового, чего совсем нельзя сказать о python.
Лично мне работать в python сложнее и дольше чем в matlab, но первый предоставляет гораздо более широкие возможности, вплоть до web программирования, да и востребован он сейчас намного сильнее, поэтому я не могу просто его игнорировать. Ну а для начинающих, наверное python окажется даже проще.

[Geen]

Missir в сообщении #1647179 писал(а):

python вырос именно из matlab

Ерунду не надо писать.

[Missir]

Alex Krylov в сообщении #1647169 писал(а):

Решатель Mosek в любом из вариантов требует ровно 5 итераций, встроенный решатель linprog в обоих случаях - 8 итераций!

Я имел в виду классический симплекс-метод, для интереса проверил - для этой задачи он требует 12 итераций, улучшенный вариант Borrodale&Roberts требует 10 итераций. В Вашей постановке эти числа сильно увеличатся. Именно её я не проверял, но проверил симплекс-алгоритм для решения двойственной задачи, который в этой теме одно время сильно расхваливали из-за компактной записи ЗЛП. Так вот, его выполнение требует 42 итераций.
Что там напихано в решателях, мне не известно, но я кажется писал, что для решения этой задачи можно использовать много разных методов. Некоторые из них я проверил тоже. Например алгоритм Clarc-Osborn требует для решения 9 итераций, irls - 11 тыс. итераций, а метод внутренней точки - всего 4 итерации. Но в этих методах исходная формулировка ЗЛП мало на что влияет.

-- 23.07.2024, 21:05 --

Geen в сообщении #1647181 писал(а):

Ерунду не надо писать

я конечно же имел в виде пакет Numpy

-- 23.07.2024, 21:16 --

ozheredov в сообщении #1647172 писал(а):

Однажды я запустил свой код на Octave, и он в нём (кто в ком?) не понял примерно половину инструкций.

совместимость у них впечатляющая, но напрямую скрипты обычно не запускаются, есть некоторые различия в синтаксисе, приходится подправлять. Например в Octave поддерживается x+=y; в matlab же нужно писать x=x+y; Но в принципе это несложно и не долго.

[ozheredov]

Alex Krylov в сообщении #1647175 писал(а):

Действительно все так плохо? Или может вы какие-нибудь новые расширения языка Matlab пытались в Octave запустить?

Нет: скормливал код, который не требовал вообще ни одного пакета (ну, потому что как бы предугадывал, что никаких пакетов в Octave нет). Конкретику забыл, но хорошо помню мои ощущения, что этот недоМатлаб не понимает простейших инструкций.

-- 26.07.2024, 18:31 --

Missir в сообщении #1647182 писал(а):

Например в Octave поддерживается x+=y;

У меня по ходу программизменный диабет - терпеть не могу синтаксический сахар ))

[Geen]

ozheredov в сообщении #1647453 писал(а):

терпеть не могу синтаксический сахар

Это не сахар - вместо x может быть некоторое выражение (и вычислять его один или два раза - большая разница может быть) или аргумент функции (и в питоне, к примеру, от этого зависит изменится ли он снаружи функции)....

[ozheredov]

Geen в сообщении #1647458 писал(а):

вместо x может быть некоторое выражение (и вычислять его один или два раза - большая разница может быть) или аргумент функции (и в питоне, к примеру, от этого зависит изменится ли он снаружи функции)

Ничего себе - не знал, спасибо