Славно. Я, насправді, не є спеціаліст у цій конкретній галузі, але не може не зацікавити питання, як у нього з... е-е-е... перформансом у порівнянні з аналогами на C чи Fortran? Подібні виміри проводились? Справа в тому, що, на мій погляд, це дещо виходить за межі звичного застосування Python.
Цитата: Raven від 2008-09-15 22:28:59Славно. Я, насправді, не є спеціаліст у цій конкретній галузі, але не може не зацікавити питання, як у нього з... е-е-е... перформансом у порівнянні з аналогами на C чи Fortran? Подібні виміри проводились? Справа в тому, що, на мій погляд, це дещо виходить за межі звичного застосування Python.По-перше, застосування Python у науковому ПЗ є достатньо популярним (якщо подивитися на кількість наукових Python-проектів з наведених лінків) По-друге, майже усі низько-рівневі операції, якто матричні помноження, розв'язування систем лінійних рівнянь і таке інше, виконуються за допомогою бібліотеки numpy - вільного ПЗ, що дозволяє звертатися з Python до скомпільованого коду С та ФОРТРАН що міститься у цій бібліотеці. Окрім того, якщо задача належить до матричного класу (тобто нема нелінійних функцій), то OpenOpt лише передає ці матриці з Python до інших матричних солверів, як правило написаних на С та ФОРТРАН, і отримує матрицю/матриці назад, тому погіршення перформансу може бути зумовлене лише часом для формування початкових даних для солвера, але воно як правило незначне у порівнянні з часом розвєязування, а час програміста для відповідного коду набагато меньший ніж С або ФОРТРАН (що обумовлено визначними RAD-властивостями Pythonу)По-трете, якщо задача належить до класу нелінійних, то як правило 90-99% часу на її розв'язування витрачається солвером на матричні операції (що обробляється numpy, дивись вище) та на виклики цих нелінійних функцій. Якщо декілька з них costly (потребують багато часу) то їх можна переписати на С або ФОРТРАН, що іноді і роблять. (один з багатоьх відомих мені прикладів)Також можу додати, що багато разів зустрічав задачі, де мій Python-written солвер ralg вирішував швидше та краще ніж усі 5 інших (які мають openopt-інтерфейси) написаних на С або ФОРТРАН. Це набагато більше залежить від алгоритмів що лежать у основі солверів, також має велике значення єпіграф з цієї сторінки.
Тобто Ви не можете надати таблицю з конкретними прикладами і часом розв’язання Вашою програмою і програмами на C, типу цього?
Приклади, наведені у пакеті розв’язувача, знову дають різні результати для різних бібліотек SciPy?
І ще одне: хто на Вашу думку писатиме бібліотеки для RAD-програмування на C і Fortran, якщо всі науковці писатимуть до них оболонки на Python?
Гаразд. Сувора мова фактів:lsp_1.py(1789.20055096-1787.97555551)/1787.97555551~0.00069 (0.07%) (Це ближче до десятих долей відсотка)lsp_1.py(13.4691644145-1.35828942657)/1.35828942657~9.18 (918%) (No comments)
Майже в усіх прикладах відносна похибка коливається від тисячних долей відсотків до десятих або навіть цілих відсотків. З точки зору обчислювальної математики, навіть за точності float, а не double, обґрунтування практичних рішень на основі таких програмних комплексів виглядає сумнівним.
І ще: не підкажете, де OpenOpt у цій таблиці (для Ъ: всі (sic!) розв’язувачі з таблиці написано на C)?
Дискутувати більше не буду.
М-м-м... пане Dmitrey15, не сприймайте за образу, але ви маєте відношення до розробки сабжу? Просто ряд ваших висловлювань (поки не буду їх цитувати, це зовсім інша тема для дискусії) наводить на думку, що ви "просто помістили об'яву" і самі не пишете. Може, це просто не до вас треба з цим питанням звертатись.
Автор
Гілка: OpenOpt: Українське ВПЗ для чисельної оптимізації (Прочитано 2293 раз)
