За да се види, кой от многото алгоритми ни върши най-добра работа се пробвах да тествам няколко общо достъпни solver-а. Те общодостъпни, но се извикват по-различен начин и не гот да се омешат толкова езици с различен синтаксис . Един фортрански код, го закачих към една програма на C, която вършеше всичко останало. В R имаше реализирани 3 алгоритъма, които също бяха тествани (от това тестване спокойно може да излезе пакет за оценяване на ARMA-GARCH в R). Лошото на тези използвани алгоритми беше, че са за оптимизация без ограничения и въпреки, че нашата оптимизация я свеждаме до такава, чрез penalty функции, то когато оптималното решение е на границата, работата не е много гот.
За целта се пробвахме със Frontline Solver (това е и solver-а, който се ползва в Excel), защото поддържа ограничения. Свалих една 15 дневна trial версия, да видя що за животно е и се оказа, че е доста голямо. Първо под Linux не можах да го подкарам. Трябваше малко да актуализирам gcc-то и glibc-то, за да могат бинарните му работи да се линкват като хората, но с тази trial защита не можах да се преборя. Не, че съм искал да я лъжа, но той просто не се оправяше с 15 дневния лиценз. През Matlab-ът си казваше, че няма лицензен файл, а като се пробвам да се закача през C, правеше директно Segmentation fault.
За мой най-голям неприязън трябваше да го боря под Windows, където се предполага, че нещата ще минат доста по-гладко. Да, ама не. Matlab-ът пак изплюваше, че не намира лицензен файл. И работата отиде в реката. След доста часове опити, накрая разбрахме къде е бил ключа от палатката. Трябвало е да се инициализира една променлива по правилния начин. Много кофти работа, могат да напишат над 500 страници референции за функциите в цялата простотия, а не могат да отделят 10 страници да кажат каква е логиката на цялото нещо и как се инициализира проклетата система.
Като се тегли чертата, лошото е че никой от тестваните алгоритми не се представи по-добре от оптимизационния toolbox на Matlab и ако трябва да го портваме на Java или C, ще ни се завие свят от матрични операции. Не че LAPACK-ът не е насреща, но все пак.
