Автор Гілка: OpenOpt: Українське ПЗ для чисельної оптимізації  (Прочитано 9809 раз)

Відсутній Dmitrey

  • Новачок
  • *
  • дописів: 12
  • Карма: +0/-0
Розробники вільного (ліцензія BSD) українського ПЗ для чисельної оптимізації OpenOpt повідомили про вихід чергової версії свого пакету, написаного мовою програмування Python, що на вiдміну від С та Fortran дозволяє RAD (Rapid application development).
Комерційні аналоги коштують тисячі та навіть десятки тисяч доларів, окрім того приблизно 10% доводиться витрачати на оновлення програмних бібліотек щорічно.

Докладніше:

Відсутній yurchor

  • Видавець
  • *******
  • дописів: 3641
  • Карма: +3/-0
  • Grateful for our Iron Lung
    • Вікі користувачів KDE
Г-м-м, трошки сиреньке і замало пояснень щодо методів оптимізації (такий собі чорний ящик). Тільки й зауважень на кшталт "very unstable". Можна було б хоча б розмістити посилання на сторінки Вікіпедії. І нічого про швидкість розрахунку задач для великих розмірностей матриць задачі лінійного програмування. Кажуть пайтон — не монстр швидкодії (хтось може спростувати?)
Поки що доцільніше користуватись інтерпретаціями на C відомих алгоритмів Fortran.
Try to reach you before winter comes
Always a place for you in my heart
You're not alone
All used up
I'd give anything to talk to you

Відсутній hse

  • Графоман
  • ****
  • дописів: 473
  • Карма: +0/-0
  • Gentoo Linux
Думаю що ви дуже помилились що початкову версію програми з MATLAB переписали на Python! Python - тормоз в матиматиці якого ще треба пошукати, так що швидкодія ваших чисельних оптимізацій буде бажати кращого. Так я знаю що є вже для Python різні прибамбаси для математики, але вважаю що для чисельних методів треба було писати далі MATLAB код та переходити на GNU/Octave - вона є вільною підтримує паралелізм (mpi) що дає змогу дуже ефективно рахувати в багатопроцесорних системах та на кластерах і matlab сумісна так що код переписувати не потрібно. Так поступають всі! Нові програми для чисельної матеметики пишуть в коді GNU/Octave.

PS: А за що ви так GPL не любите? Хоч Octave і під GPL, але програми для неї пишуть під любими ліцензіями навіть BSD, цеж не бібліотека тут лінкувати нічого не треба...
бушократія - цинічний помаранчевий геноцид, витравлювання Української Нації, плюс мікрософтизація всієї країни.

Відсутній Сашко Кравчук

  • Графоман
  • ****
  • дописів: 490
  • Карма: +0/-0
  • Debian GNU/Linux
Нагадати про анонімоусів?

М. fixed
« Змінено: 2007-12-16 01:43:23 від Praporshic »

Praporshic

  • Гість
Нагадати про анонімоусів?
До їх дозволу було не менше порушників. Хіба що їх треба було ще й банити.

Відсутній rangel

  • Графоман
  • ****
  • дописів: 281
  • Карма: +0/-0
  • Python programmer
Python - тормоз в матиматиці якого ще треба пошукати, так що швидкодія ваших чисельних оптимізацій буде бажати кращого. Так я знаю що є вже для Python різні прибамбаси для математики...
numarray?
Roman Suprotkin

Відсутній Веприк

  • Дописувач
  • **
  • дописів: 58
  • Карма: +0/-0
  • Pythonic man
Python - тормоз в матиматиці якого ще треба пошукати, так що швидкодія ваших чисельних оптимізацій буде бажати кращого. Так я знаю що є вже для Python різні прибамбаси для математики...
numarray?

Взагалі той же MATLAB це по суті оболонка до C-шних високооптимізованих бібліотек , частину в основному графіки вони переписали на Java , так що в плані швидкодії він далеко позаду Python + SciPy та обгорток над бібліотеками чисельної оптимізації буде. Крім того таких обгорток є досить багато + написати власну як на мене не надто складно. А західні ВУЗи, навіть дуже багаті не дуже здатні потягнути такий пакет як MATLAB, я не кажу вже про FEMLAB-и і інші надбудови, тому багато нових розробок робиться саме на Python + високооптимізована С+ ASM бібліотека. А ваша любов до MATLAB дуже швидко скінчиться, коли ви чи ваш ВУЗ відвалить добрячу суму за ліцензійну версію.
Мої рефлексії на довкілля http://blog.sasnyk.name

Відсутній yurchor

  • Видавець
  • *******
  • дописів: 3641
  • Карма: +3/-0
  • Grateful for our Iron Lung
    • Вікі користувачів KDE
Python - тормоз в матиматиці якого ще треба пошукати, так що швидкодія ваших чисельних оптимізацій буде бажати кращого. Так я знаю що є вже для Python різні прибамбаси для математики...
numarray?

Взагалі той же MATLAB це по суті оболонка до C-шних високооптимізованих бібліотек , частину в основному графіки вони переписали на Java , так що в плані швидкодії він далеко позаду Python + SciPy та обгорток над бібліотеками чисельної оптимізації буде. Крім того таких обгорток є досить багато + написати власну як на мене не надто складно. А західні ВУЗи, навіть дуже багаті не дуже здатні потягнути такий пакет як MATLAB, я не кажу вже про FEMLAB-и і інші надбудови, тому багато нових розробок робиться саме на Python + високооптимізована С+ ASM бібліотека. А ваша любов до MATLAB дуже швидко скінчиться, коли ви чи ваш ВУЗ відвалить добрячу суму за ліцензійну версію.
Можна подивитися на результати тестів, на які Ви спиралися висловлюючи думку про гальма у MATLAB, а отже і Octave та Scilab, як його аналоги у ВПЗ?
Try to reach you before winter comes
Always a place for you in my heart
You're not alone
All used up
I'd give anything to talk to you

Відсутній Dmitrey

  • Новачок
  • *
  • дописів: 12
  • Карма: +0/-0
Мені здається, що треба зауважити наступне:
1. Copyleft, що присутній у GPL/LGPL, є дуже великим стримуючим фактором, що не дозволяє багатьом розробникам ПЗ включати ПЗ з цією ліцензією до свого ПЗ з закритим чи іншим не вільним кодом. Зокрема, це стосується Octave та ще більше SciLab, який взагалі має ліцензію не сприйняту OSI.
2. MATLAB це однозначно пройдений єтап (хоч я і проходив курси, маю сертифікат та більше трьох років досвіду), повернення на ноьго неможливе за багатьма обставинами, головні з яких:
  • велика вартість (та взагалі - "вартість" vs вільне ПЗ)
  • pass-by-copy only, що просто не дозволяло мені мати нормальні програмні конструкції, доводилося багато користуватися global (ця проблема є і у Octave)
  • відсутність нормального ООП
  • деякі відмінності між MATLAB та Octave, які доводилося брати до уваги. Доречі, розробники Octave дуже обмежені - вони не можуть розвивати свій власний продукт (тобто добавляти чи змінювати синтакс), бо мають мати 100% сумістність до MATLAB.
3. numarray та numeric - це застарілі пакети (доречі, нова версія matplotlib вже не буде підтримувати їх), зараз усі користуються numpy
4. Усі тести щодо MATLAB та numpy/scipy мають давати приблизно ті ж самі результати за швидкістю (і приблизно таке я і бачів на різноманітних результатах тестів, що надсилають користувачі numpy/scipy через лісти розсилок), тому що зараз як MATLAB так і numpy/scipy є "обгортками" до BLAS, LAPACK, MKL (Intel), ACML (AMD) та багатьох інших відомих бібліотек написаних на С та Фортран.
5. Якщо OpenOpt і буде переписуватися на щось інше, то це буде лише Fortress (наступник Fortran від Sun Microsystems) (доречі я вже давно підписався на їх mailing lists). Але більш - меньш стабільний компілятор Fortress його розробники планують випустити лише у ~2010 році, тому ще неясно, чи стане він поширеним, чи цю нішу займуть інші його конкуренти - Microsoft F#, IBM Х10, Cray Chapel (а може й якийсь з компіляторів Python, "заточений" на швидкість та параллені розрахунки).

Г-м-м, трошки сиреньке і замало пояснень щодо методів оптимізації (такий собі чорний ящик). Тільки й зауважень на кшталт "very unstable". Можна було б хоча б розмістити посилання на сторінки Вікіпедії. І нічого про швидкість розрахунку задач для великих розмірностей матриць задачі лінійного програмування. Кажуть пайтон — не монстр швидкодії (хтось може спростувати?)
Поки що доцільніше користуватись інтерпретаціями на C відомих алгоритмів Fortran.
Вікіпедія: http://en.wikipedia.org/wiki/OpenOpt
Де це ти знайшов стільки зауважень"very unstable"?? Я знаю лише одне, що є на сторінці NLSP, про декілька сторонніх солверів, яки взагалі і написані-то не мною (це я їх потестував і вирішив таке про них зауважити).
Щодо швидкості - я вже написав вище.
Для задачі лінійного програмування OpenOpt має 3 підключених сторонніх солвера (glpk, lpsolve та cvxopt), перші 2 написані на С, про останній не пам'ятаю. Можу додати що є 100% Python-written LP солвер у проєкті Elefant (теж користується numpy), але там сам проєкт ща сирий тому я звідти нічого не підключав.
"пайтон — не монстр швидкодії" - так, але іноді краще писати тиждень програму та 2 хвилини почекати ніж 2 тиждні писати на С та 1 хвилину чекати розрахунків. До того ж, усі ті тести про швидкодію Пітона користувалися чистим Пітоном, а не скомпільованим підключеним кодом на кшалт numpy/scipy.

Відсутній yurchor

  • Видавець
  • *******
  • дописів: 3641
  • Карма: +3/-0
  • Grateful for our Iron Lung
    • Вікі користувачів KDE
Де це ти знайшов стільки зауважень"very unstable"?? Я знаю лише одне, що є на сторінці NLSP, про декілька сторонніх солверів, яки взагалі і написані-то не мною (це я їх потестував і вирішив таке про них зауважити).
Щодо швидкості - я вже написав вище.
Для задачі лінійного програмування OpenOpt має 3 підключених сторонніх солвера (glpk, lpsolve та cvxopt), перші 2 написані на С, про останній не пам'ятаю. Можу додати що є 100% Python-written LP солвер у проєкті Elefant (теж користується numpy), але там сам проєкт ща сирий тому я звідти нічого не підключав.
"пайтон — не монстр швидкодії" - так, але іноді краще писати тиждень програму та 2 хвилини почекати ніж 2 тиждні писати на С та 1 хвилину чекати розрахунків. До того ж, усі ті тести про швидкодію Пітона користувалися чистим Пітоном, а не скомпільованим підключеним кодом на кшалт numpy/scipy.
Спасибі, що уважили таку бидлятину як я зверненням на "ти". :(
Вгадувати назви алгоритимів, я так розумію, треба з вихідних кодів, а пайтон стане мовою майбутнього у наукових розрахунках уже найближчим часом. До речі, якщо Ви не в курсі, у мережі лежать тонни добре документованих рецептів на C для спецфункцій, лінійного, опуклого та нелінійного програмування. Їх автори не гребують докладним поясненням, звідки взято розрахункові формули та хто є їх науковим автором... Хоча вони і не під GPL. Наприклад тут.
Те, що сперто Вами з підручників, без вказання авторів алгоритмів не робить честі жодній вільній ліцензії.
« Змінено: 2007-12-17 13:02:13 від yurchor »
Try to reach you before winter comes
Always a place for you in my heart
You're not alone
All used up
I'd give anything to talk to you

Відсутній Dmitrey

  • Новачок
  • *
  • дописів: 12
  • Карма: +0/-0
Спасибі, що уважили таку бидлятину як я зверненням на "ти". :(
Вгадувати назви алгоритимів, я так розумію, треба з вихідних кодів, а пайтон стане мовою майбутнього у наукових розрахунках уже найближчим часом. До речі, якщо Ви не в курсі, у мережі лежать тонни добре документованих рецептів на C для спецфункцій, лінійного, опуклого та нелінійного програмування. Їх автори не гребують докладним поясненням, звідки взято розрахункові формули та хто є їх науковим автором... Хоча вони і не під GPL. Наприклад тут.
Те, що сперто Вами з підручників, без вказання авторів алгоритмів не робить честі жодній вільній ліцензії.

Пробачьте, я цей форум раніше не читав тому не знав що тут прийнято на ви, наскільки мені відомо на багатьох форумах програмістів звернення на ти не є образою (якої я зовсім не мав на увазі).

В вихідній структурі r (r = p.solve(SolverName)) є поля r.alg, r.authors, r.homepage та інші, де можна детальніше дізнатися про застосований солвер. Але деякі з них undefined, бо мені самому складно добути усю інформацію, видавці деяких солверів (хочь і вільних) не дуже-то полюбляють давати усю інформацію та ще й детально.

Тонни рецептів ще не є кодом сприйнятним до користування. Навіщо тоді взагалі щось робити, писати 17 Мб zipped кода як має coin-or, якщо вже все є у літературі?.. Навіщо платити по 24500$ за CONOPT або інші комерційні солвери якщо можна сісти та з літератури усе написати?..


Praporshic

  • Гість
2 yurchor & Dmitrey:

Для початку попередження. Обом. Плюсомет вже напоготові.

Відсутній yurchor

  • Видавець
  • *******
  • дописів: 3641
  • Карма: +3/-0
  • Grateful for our Iron Lung
    • Вікі користувачів KDE
Вибачте за різкість... :-[
Давайте зійдемось посередині: я й далі користуватимусь своїми рецептиками, а Ви допишете колись згодом документацію до Вашого пакета.
Try to reach you before winter comes
Always a place for you in my heart
You're not alone
All used up
I'd give anything to talk to you

Відсутній Dmitrey

  • Новачок
  • *
  • дописів: 12
  • Карма: +0/-0
Усю документацію можна отримати за допомогою
from scikits.openopt import *
help(NLP) # або будь-який інший клас

До того ж багато прикладів використовування з деякими роз'ясненнями є у директорії /openopt/examples
Веб-сторінка кожного класу має посилання на приклад, що можна подивитися on-line, на кшалт
http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nlp_1.py


Відсутній yurchor

  • Видавець
  • *******
  • дописів: 3641
  • Карма: +3/-0
  • Grateful for our Iron Lung
    • Вікі користувачів KDE
Я трошки не про те: ну, наприклад, вирішив я за допомогою Вашого пакету порахувати якусь задачку лінійного програмування. Імпортував lpSolve.py. Подивився на посилання на авторів, перейшов за цією адресою... І що я маю: та це ж мій улюблений рецепт на C! До чого тут пайтон?
Крім того, для того щоб з’ясувати, що там застосовано симплекс-метод (я-то це знаю, а хтось може і ні) треба буде ще полазити по Вікіпедіях та вихідному коду...
Try to reach you before winter comes
Always a place for you in my heart
You're not alone
All used up
I'd give anything to talk to you