Przejdź do zawartości

Ś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

  • 1947
    Simplex method
    Dantzig

lata 1950

  • 1954
    Cutting planes for the TSP
    Dantzig, Fulkerson and Johnson
  • 1957
    Dynamic programming
    Bellman
  • 1958
    Integer cutting planes
    Gomory
  • 1959
    Shortest paths
    Dijkstra
  • 1959
    The vehicle routing problem
    Dantzig and Ramser

lata 1960

  • 1960
    Branch and bound
    Land and Doig
  • 1960
    Dantzig-Wolfe decomposition
    Dantzig and Wolfe
  • 1961
    Column generation
    Gilmore and Gomory
  • 1962
    Benders decomposition
    Benders
  • 1964
    Clarke-Wright savings
    Clarke and Wright

lata 1970

  • 1970
    Lagrangian relaxation
    Held and Karp
  • 1972
    NP-completeness
    Karp
  • 1973
    Lin-Kernighan
    Lin and Kernighan
  • 1975
    Genetic algorithms
    Holland
  • 1977
    Arc consistency
    Mackworth
  • 1979
    Ellipsoid method
    Khachiyan

lata 1980

  • 1983
    Simulated annealing
    Kirkpatrick, Gelatt and Vecchi
  • 1984
    Interior point methods
    Karmarkar
  • 1986
    Tabu search
    Glover
  • 1987
    Constraint logic programming
    Jaffar and Lassez

lata 1990

  • 1991
    Branch and cut
    Padberg and Rinaldi
  • 1992
    Ant colony optimisation
    Dorigo
  • 1994
    The alldifferent constraint
    Regin
  • 1996
    Conflict-driven clause learning
    Marques-Silva and Sakallah
  • 1997
    Variable neighbourhood search
    Mladenovic and Hansen
  • 1998
    Branch and price
    Barnhart and others
  • 1998
    Large neighbourhood search
    Shaw

lata 2000

  • 2005
    Feasibility pump
    Fischetti, Glover and Lodi
  • 2006
    Adaptive large neighbourhood search
    Ropke and Pisinger
  • 2007
    MiniZinc
    Nethercote and others
  • 2009
    Lazy clause generation
    Ohrimenko, Stuckey and Codish

lata 2010

  • 2017
    JuMP
    Dunning, Huchette and Lubin
  • 2019
    Learned branching heuristics
    Gasse and others

lata 2020

  • 2020
    Neural diving for mixed-integer programs
    Nair and others
  • 2021
    First-order methods for large linear programs
    Applegate and others
  • 2023
    Linear programming on GPUs
    Lu 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.

Zbudowane na JuMP, algebraiczny język modelowania język programowania Julia

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.

Odtwarzacz ładuje się z YouTube dopiero po naciśnięciu odtwarzania.

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