O que é grande demais para os métodos padrão de álgebra linear / otimização?

Álgebra linear numérica diferente e métodos de otimização numérica têm regimes de tamanho diferentes, onde são uma 'boa ideia', além de suas próprias propriedades. Por exemplo, para problemas de otimização muito grandes, os métodos de gradiente, gradiente estocástico e descida de coordenadas são usados ​​em vez dos métodos de Newton ou Ponto Interior, porque você não precisa lidar com o Hessian. Da mesma forma, métodos densos de resolução linear deixam de ser viáveis ​​após um determinado tamanho.

Portanto, considerando que os algoritmos e o hardware do computador estão mudando constantemente, qual é uma boa maneira de saber e acompanhar o quão grande é muito grande para álgebra linear padrão e solucionadores de otimização?

(Estou pensando nisso porque, quando você é um usuário final de algoritmos numéricos, é importante ter uma vaga idéia de quando esses algoritmos podem ser aplicados. Parte disso é a estrutura do problema e o tipo de solução desejada, mas parte dela também é apenas o tamanho do problema.)

EDIT: Para uma maior concretude, o que me fez pensar sobre isso foi a variação das regras práticas nos limites superiores para determinar o tamanho de um problema que os algoritmos de pontos interiores poderiam resolver. Artigos anteriores disseram que a dimensionalidade deveria ser de cerca de 1000, enquanto artigos posteriores haviam revisado para mais de 5000 e artigos ainda mais recentes permitem ainda maiores, dependendo se você pode tirar vantagem da escarsidade. Essa é uma variedade bastante grande, portanto, estou curioso para saber o que é grande para os métodos de pontos interiores de última geração.

$\mathcal O(n)$

Observe que ainda é possível usar a otimização baseada em Newton com grandes espaços de design, você só precisa resolver iterativamente com o Hessian. Existem muitas abordagens para fazê-lo com eficiência.

Portanto, tudo depende de como você define "métodos padrão". Se sua definição incluir métodos de preservação de estrutura em vários níveis, problemas extremamente grandes serão tratáveis. Se sua definição é limitada a métodos densos não estruturados, os tamanhos de problemas possíveis são muito menores porque os algoritmos não são "escalonáveis" no tempo ou no espaço.

O limite é fornecido principalmente pela memória necessária para armazenar a representação da matriz e pelo tempo para recuperá-la da memória.

Isso torna alguns milhares o limite para o método de matriz densa em ambientes simples. Para problemas esparsos, o limite para solucionadores diretos é muito maior, mas depende do padrão de escarsidade, pois o preenchimento deve ser acomodado. O limite para métodos iterativos para solucionadores lineares é essencial para multiplicar o custo de um vetor de matriz.

O limite para resolver os subproblemas lineares se traduz diretamente nos limites correspondentes para solucionadores locais para sistemas não lineares de equações e problemas de otimização.

Os solucionadores globais têm limites muito mais severos, pois são limitados pelo número de subproblemas que precisam ser resolvidos em uma estrutura ramificada e vinculada ou pela maldição da dimensionalidade nos métodos de pesquisa estocásticos.

Para uma determinada classe de problemas, boas maneiras de descobrir o que constitui o tamanho "grande demais" são:

• pesquise a literatura em seu campo; entender quais fatores limitarão o tempo de execução (incluem uso de memória e comunicação)
• observe os conjuntos de problemas de teste (melhor para algoritmos seriais do que algoritmos paralelos, pois não conheço muitos conjuntos de problemas de teste para algoritmos paralelos)
• divida o algoritmo em partes menores e constituintes e use o que você sabe sobre as partes para fazer inferências sobre o todo (exemplo: os métodos do subespaço de Krylov se resumem a loops de produtos vetoriais de matriz, então você precisa descobrir quantas iterações é "muitos" e o que torna um produto de vetor de matriz "muito grande")
• experimente você mesmo (em uma máquina serial ou, se tiver os recursos, em uma máquina paralela). Veja o tamanho de uma instância que você pode executar ou execute várias instâncias de tamanhos diferentes e faça uma análise empírica de escala (tempo versus tamanho do problema).

Para dar um exemplo, na otimização global, a resposta concreta é extremamente dependente da estrutura. Como observa Arnold Neumaier, os algoritmos determinísticos de otimização global tendem a ser limitados pelo número de subproblemas que devem ser resolvidos em uma estrutura de ramificação e limite (ou ramificação e corte). Resolvi programas lineares inteiros mistos (MILPs) contendo milhares de variáveis ​​binárias, mas desconfio que a razão pela qual posso resolver problemas tão grandes (comparativamente falando, para MILPs) seja porque a estrutura do problema era tal que poucos subproblemas eram necessários para resolver algum conjunto crítico de variáveis ​​binárias e o restante pode ser definido como zero. Eu sei que meu problema é "grande"; Eu construí outros MILPs de tamanho semelhante que resolvem dezenas de milhares de vezes mais lentamente.

Existem conjuntos de testes de otimização global que dão uma idéia do que é "comum" e a literatura pode fornecer idéias sobre quais problemas são "grandes". Táticas semelhantes existem para descobrir o estado da arte em tamanhos de problemas em outros campos, e é assim que Jed Brown e Arnold Neumaier podem citar esses números. É ótimo obter esses números, mas é muito mais valioso poder descobrir como obtê-los você mesmo quando chegar a hora.