Jeśli używamscipy.linalg.solve (co, jak sądzę, nazywa funkcją gesv LAPACK) na nieznanym problemie ~ 12000 (z ~ 12000-kwadratową, gęstą, niesymetryczną matrycą) na mojej stacji roboczej, otrzymuję dobrą odpowiedź w10-15 minut.

Aby zbadać granice tego, co jest możliwe (zauważ, że nie mówię „użyteczny”), podwoiłem rozdzielczość mojego podstawowego problemu, co prowadzi do konieczności rozwiązania dla ~ 50000 nieznanych. Chociaż to technicznie działałoby na mojej stacji roboczej, gdy dodałem jeszcze 10 GB GB swapu, bardziej rozsądne wydawało się użycie HW z odpowiednią pamięcią RAM, więc wyrzuciłem go na AWS EC2 High-Memory Quadruple Extra Large. .. gdzie zgrzytało na ostatnią14 godzin (hej, przypadki spotów są tanie) i nie da się określić, jak daleko się znajduje.

Niestety nie mam pojęcia, jaka jest złożoność czasowa zaangażowanych solverów (moje google-fu zawiodło mnie na tym). Jeśli jest to O (N ^ 2), spodziewałbym się, że zostanie to zrobione po około 4 godzinach; jeśli jest to O (N ^ 3), może zostanie to zrobione za 16 godzin. Oczywiście jest to interpretacja N jako liczby niewiadomych - która wzrosła czterokrotnie - liczba elementów w macierzy wzrosła o współczynnik 16!

I porady, które pomogą mi ustalić, czy ma to szansę na ukończenie mojego (projektu) życia, czy też nie zostanie mi z wdzięcznością przyjęte!

Inne informacje:

Rzadkie macierze nie są tu interesujące (moja matryca jest gęsta, aw każdym razie scipy nie działają z więcej niż2**31 niezerowe elementy nawet na 64-bitach).

Używam scipy Debiana / Squeeze na stacji roboczej, Ubuntu 12.04 na EC2. Obie 64-bitowe oczywiście.