Śledzimy badania nad optymalizacją i współtworzymy open source
Optymalizacja matematyczna jest publikowana, dyskutowana i ulepszana od 1947 roku. Nowe metody wciąż się pojawiają. Czytamy je, testujemy na instancjach, które klienci naprawdę przysyłają, i zmieniamy silnik, gdy tak mówią liczby. Łączniki między językiem modelowania Julia a tymi silnikami są otwartoźródłowe i utrzymujemy je jawnie.
- Organizacja GitHub
- NexOR-Optimization
- Napisane w
- Julia, Python
- Wkład
- Rdzeń JuMP i mosty do solverów
- Konferencje
- JuMP-dev, Odoo Experience
- Powiązania akademickie
- UCLouvain
Osiemdziesiąt lat metod
Osiem dekad wyników i żadnej metody, która by wygrała. Każda pozycja poniżej to datowana publikacja, wraz z osobami, które ją napisały.
Optymalizacja zaczęła się jako problem planowania w czasie wojny i stała się dziedziną. Metoda simpleks pojawiła się w 1947 roku, a kolejnych piętnaście lat dało większość maszynerii działającej do dziś: programowanie dynamiczne, płaszczyzny tnące, podział i ograniczenia, najkrótsze ścieżki oraz dekompozycje pozwalające rozwiązać jeden duży problem jako serię małych.
Potem, w 1972 roku, Karp pokazał, dlaczego ta praca nigdy się nie skończy. Cała rodzina zwykłych problemów planistycznych nie ma znanego wydajnego algorytmu dokładnego i do dziś żadnego nie znaleziono. Odpowiedzią nie był jeden lepszy algorytm, lecz wiele, zapożyczonych zewsząd: symulowane wyżarzanie z metalurgii, przeszukiwanie tabu z pomysłu krótkiej pamięci, algorytmy genetyczne i optymalizacja mrowiskowa z biologii, programowanie z ograniczeniami z logiki, a przeszukiwanie dużego sąsiedztwa ze spostrzeżenia, że dobry plan zwykle dzieli od lepszego jedna drobna zmiana.
Żadna nie wygrała i o to właśnie chodzi. Każda jest mocna na kształcie problemu, z którym pozostałe radzą sobie źle, więc dziedzina zachowała je wszystkie i nauczyła się je łączyć: przeszukiwanie dokładne sterowane heurystykami, propagacja ograniczeń wsparta uczeniem klauzul, a od niedawna decyzje o podziale wyuczone z danych. Ostatnie lata dołożyły metody pierwszego rzędu i GPU, które otwierają na nowo programy liniowe w rozmiarach, do jakich metoda simpleks nigdy nie była przeznaczona.
lata 1940
-
1947Simplex methodDantzig
lata 1950
-
1954Cutting planes for the TSPDantzig, Fulkerson and Johnson
-
1957Dynamic programmingBellman
-
1958Integer cutting planesGomory
-
1959Shortest pathsDijkstra
-
1959The vehicle routing problemDantzig and Ramser
lata 1960
-
1960Branch and boundLand and Doig
-
1960Dantzig-Wolfe decompositionDantzig and Wolfe
-
1961Column generationGilmore and Gomory
-
1962Benders decompositionBenders
-
1964Clarke-Wright savingsClarke and Wright
lata 1970
-
1970Lagrangian relaxationHeld and Karp
-
1972NP-completenessKarp
-
1973Lin-KernighanLin and Kernighan
-
1975Genetic algorithmsHolland
-
1977Arc consistencyMackworth
-
1979Ellipsoid methodKhachiyan
lata 1980
-
1983Simulated annealingKirkpatrick, Gelatt and Vecchi
-
1984Interior point methodsKarmarkar
-
1986Tabu searchGlover
-
1987Constraint logic programmingJaffar and Lassez
lata 1990
-
1991Branch and cutPadberg and Rinaldi
-
1992Ant colony optimisationDorigo
-
1994The alldifferent constraintRegin
-
1996Conflict-driven clause learningMarques-Silva and Sakallah
-
1997Variable neighbourhood searchMladenovic and Hansen
-
1998Branch and priceBarnhart and others
-
1998Large neighbourhood searchShaw
lata 2000
-
2005Feasibility pumpFischetti, Glover and Lodi
-
2006Adaptive large neighbourhood searchRopke and Pisinger
-
2007MiniZincNethercote and others
-
2009Lazy clause generationOhrimenko, Stuckey and Codish
lata 2010
-
2017JuMPDunning, Huchette and Lubin
-
2019Learned branching heuristicsGasse and others
lata 2020
-
2020Neural diving for mixed-integer programsNair and others
-
2021First-order methods for large linear programsApplegate and others
-
2023Linear programming on GPUsLu and Yang
Śledzenie dziedziny to część pracy
Rosnący katalog silników
Liczba obsługiwanych przez nas solverów stale rośnie. Każdy nowy silnik trafia do katalogu przez ten sam interfejs JuMP, zmierzony wobec silników już obecnych i opublikowany wraz ze swoją stawką.
Wydania solverów
Każde wydanie solvera przesuwa to, który silnik jest najszybszy i na jakim problemie. Uruchamiamy nasz zestaw testowy na każdej nowej wersji i zmieniamy domyślny silnik tylko wtedy, gdy poprawa utrzymuje się na więcej niż jednej instancji.
Opublikowane badania
Badania operacyjne są publikowane jawnie, więc metodę można przeczytać i sprawdzić, zanim ktokolwiek na niej zbuduje. Śledzimy literaturę o trasowaniu i harmonogramowaniu i wdrażamy to, co sprawdza się na danych klientów.
Warsztat JuMP-dev
Na JuMP-dev osoby utrzymujące warstwę modelowania i jej interfejsy solverów osobiście przeglądają pracę roku. Jeździmy tam i prezentujemy.
Konferencja Odoo Experience
Odoo Experience zbiera w jednej sali plan rozwoju Odoo i jego klientów. Jedziemy tam, żeby usłyszeć, czego potrzebują, pokazać, co robimy, i utrzymać naszą pracę nad optymalizacją dopasowaną do platformy, na której działa.
Nasz własny zestaw testowy
Metoda zdobywa miejsce w katalogu, pokonując to, co już tam jest. Mierzymy to na instancjach zachowanych z prawdziwych problemów klientów, a nie na zestawach wybranych przez jej autorów.
Julia i warstwa, w której modeluje ta dziedzina
W Julii pisze się dużą część współczesnych badań nad optymalizacją. Działa z prędkością, jakiej potrzebują solvery, i czyta się blisko matematyki, więc artykuł i jego implementacja pozostają rozpoznawalnie tym samym.
JuMP leży na wierzchu. Opisz problem raz, w składni bliskiej matematyce, a potem przekaż go jednemu z ponad 30 solverów za jednym interfejsem. To de facto standard w społeczności Julii i kręgosłup badań nad optymalizacją na uczelniach europejskich, w tym na UCLouvain, gdzie kształciła się część naszego zespołu.
Pracujemy nad nim, a nie tylko z nim. Członkowie zespołu zgłaszają pull requesty do pakietów rdzeniowych, utrzymują interfejsy solverów i prezentują na warsztacie JuMP-dev.
Pokazane na JuMP-dev
Benoît Legat, jeden z naszych założycieli i główny deweloper JuMP, pokazuje stos, na którym działa NexOR, społeczności budującej JuMP.
Co utrzymujemy otwarcie
Mosty do solverów, warstwy modelowania i klient łączący się z naszymi serwerami. Zostają na GitHubie na własnych licencjach.
Hexaly.jl
Interfejs JuMP do Hexaly, komercyjnego solvera programowania z ograniczeniami i metaheurystyk. Pozwala modelom w Julii sterować Hexaly bezpośrednio.
MaxiCP.jl
Interfejs JuMP do MaxiCP, akademickiego solvera programowania z ograniczeniami rozwijanego na UCLouvain. Otwarte źródła, razem z solverem.
Vroom.jl
Interfejs JuMP do VROOM, szeroko używanego otwartego solvera marszrutyzacji pojazdów. Wprowadza VROOM do zestawu narzędzi Julii i JuMP.
OscaRCBLS.jl
Interfejs JuMP do OscaR.cbls, biblioteki przeszukiwania lokalnego opartego na ograniczeniach, rozwijanej w CETIC. Udostępnia przeszukiwanie lokalne w tym samym języku modelowania co solvery dokładne.
MathOptVRP.jl
Rozszerzenie JuMP do problemów marszrutyzacji pojazdów. Zapisuje przystanki, ładowności i okna czasowe jako model marszrutyzacji, który JuMP może przekazać dowolnemu solverowi.
JuMPy
Interfejs Pythona do MathOptInterface. Modele zapisuje się raz jako szablony i rozwija w skompilowanej Julii, więc zbudowanie dużego modelu przestaje kosztować więcej niż jego rozwiązanie.
ContractionHierarchies.jl
Obliczanie najkrótszych ścieżek na grafach OpenStreetMap za pomocą hierarchii kontrakcji. Buduje macierze odległości i czasów przejazdu, które model optymalizacyjny przyjmuje na wejściu.
NexOR.jl
Klient Julia do naszego API rozwiązywania. Model zapisany w JuMP rozwiązuje się na naszych serwerach, a nie na komputerze lokalnym, a wyniki wracają do tej samej sesji.
Otwarta matematyka bije matematykę z czarnej skrzynki
Audytowalne modele
Mosty do solverów są w kodzie, który każdy może przeczytać, tak samo jak solvery, do których sięgają. Matematyka nie jest czarną skrzynką przyjmowaną na wiarę.
Sprawdzone przez badania
JuMP i jego solvery są używane w laboratoriach badań operacyjnych na całym świecie. Solvery, na których budujemy, są sprawdzane przez globalną społeczność.
Bez vendor lock-in
Mosty zostają na GitHubie na własnych otwartych licencjach, cokolwiek się z nami stanie. Dane i baza danych należą do Państwa i można je wyeksportować w dowolnej chwili.
Dopasowane do klienta
Solver, który nie odwzorowuje realiów klienta, jest tylko wolnym oprogramowaniem. Rozszerzamy otwarte pakiety, gdy ograniczenie zgłoszone przez klienta nie jest jeszcze obsługiwane.
Kod optymalizacyjny, który piszemy, jest otwartoźródłowy
github.com/NexOR-Optimization