Método de gradiente conjugado BFGS vs.


25

Que considerações devo fazer ao escolher entre BFGS e gradiente conjugado para otimização? A função que estou tentando ajustar com essas variáveis ​​são funções exponenciais; no entanto, a função objetivo real envolve integração, entre outras coisas, e é muito dispendiosa se isso ajudar.


3
Bem, o BFGS é certamente mais caro em termos de armazenamento que o CG. Um requer a manutenção de um Hessiano aproximado, enquanto o outro precisa apenas de alguns vetores de você. Por outro lado, ambos exigem o cálculo de um gradiente, mas disseram-me que, com o BFGS, você pode usar aproximações de diferenças finitas em vez de precisar escrever uma rotina para o gradiente (mas a versão que usa diferenças finitas converge um pouco mais lento que o que usa gradientes reais, é claro). Se você possui um recurso de diferenciação automática, sua única preocupação é o armazenamento.
JM

tem que caber apenas ~ 7 (definitivamente menos de 10) variáveis ​​significa que a aproximação hessiana é apenas (no máximo) uma matriz 10x10 correta? nesse caso, um é mais rápido que o outro?
drjrm3

Eu não acho que haveria muita diferença na velocidade; se alguma coisa, acho que a parte do seu cálculo que provavelmente levaria mais tempo são as quadraturas que você precisa fazer para avaliar a função. Você realmente deve fazer algumas experiências, se o número de parâmetros for tão pequeno quanto você alega.
JM

Respostas:


13

JM está certo sobre o armazenamento. O BFGS requer um Hessian aproximado, mas você pode inicializá-lo com a matriz de identidade e, em seguida, apenas calcular as atualizações de nível dois para o Hessian aproximado à medida que avança, desde que você tenha informações de gradiente disponíveis, preferencialmente analiticamente, e não através de diferenças finitas. O BFGS é um método quase-Newton e convergirá em menos etapas que o CG, e tem uma tendência um pouco menos de "ficar preso" e exigir pequenos ajustes algorítmicos para obter uma descida significativa para cada iteração.

Por outro lado, o CG requer produtos vetoriais de matriz, que podem ser úteis para você, se você puder calcular derivadas direcionais (novamente, analiticamente ou usando diferenças finitas). Um cálculo de diferença finita de uma derivada direcional será muito mais barato que um cálculo de diferença finita de um Hessiano; portanto, se você optar por construir seu algoritmo usando diferenças finitas, basta calcular diretamente a derivada direcional. Essa observação, no entanto, não se aplica realmente ao BFGS, que calculará Hessianos aproximados usando produtos internos de informações de gradiente.

nn

Eu compararia os dois algoritmos em um pequeno problema de teste para seu aplicativo se você souber que o armazenamento não será um problema. Sem conhecer as especificidades específicas do seu problema, meu palpite é que o BFGS será mais rápido, mas você deve realmente testar os dois algoritmos para ter uma idéia melhor de qual funcionará melhor.

Por fim, uma palavra sobre diferenciação automática: tendo alguma experiência com um recurso interno de diferenciação automática (AD) para Fortran ( DAEPACK ), posso dizer que as ferramentas do AD geralmente são exigentes. Eles podem não ser capazes de diferenciar necessariamente o código que eles próprios geram. Existem dois tipos de ferramentas do AD:

  • ferramentas AD de fonte a fonte
  • operador sobrecarregando ferramentas AD

As ferramentas fonte a fonte são essencialmente compiladores modificados que pegam o código-fonte que você escreveu, analisam e geram automaticamente um novo código-fonte que calcula o gradiente de funções no seu código-fonte. As ferramentas de sobrecarga do operador do AD exigem que você use os operadores do AD sobrecarregados em seu código-fonte para que as derivadas possam ser calculadas, o que exigiria um esforço adicional de sua parte para calcular derivadas analíticas com o AD.


22

mm

Na minha experiência, o BFGS com muitas atualizações armazena informações muito distantes da solução atual para ser realmente útil na aproximação do jacobiano sem atraso, e você pode realmente perder a convergência se armazenar demais. Existem variantes "sem memória" do BFGS que se parecem muito com gradientes conjugados não lineares (consulte a atualização final descrita para um deles) apenas por esses motivos. Portanto, se você deseja fazer L-BFGS em vez de BFGS, os problemas de memória desaparecem e os métodos estão relacionados . Evidências anedóticas apontam para o reinício de ser uma questão complicada, pois algumas vezes é desnecessária e outras muito necessária.

Sua escolha entre os dois também depende muito dos problemas nos quais você está interessado. Se você tiver os recursos, poderá tentar os dois e decidir qual funciona melhor. Por exemplo, eu pessoalmente não faço otimização com esses algoritmos, mas sim me preocupo com a solução de sistemas de equações não lineares. Para estes, descobri que o NCG funciona melhor e é mais fácil executar o pré-condicionamento não linear. BFGS é mais robusto.

m


Eu esqueci totalmente o L-BFGS. +1 para isso.
JM

15

Em baixas dimensões, um método BFGS bem implementado é geralmente mais rápido e mais robusto que o GC, especialmente se a função não estiver muito longe de ser quadrática.

Nem BFGS nem GC precisam de nenhuma suposição sobre convexidade; apenas a aproximação Hessiana inicial (para BFGS) resp. o pré-condicionador (para GC) deve ser definido positivamente. Mas estes sempre podem ser escolhidos para serem a matriz de identidade, em dimensões baixas, sem muito dano. Consulte também /scicomp//a/3213/1117

Na ausência de um gradiente programado, é um grande desperdício de esforço usar gradientes numéricos, especialmente quando os valores das funções são caros. Em vez disso, deve-se usar um algoritmo sem derivadas. Consulte http://archimedes.cheme.cmu.edu/?q=dfocomp para uma pesquisa recente.


O link fornece um "404 não encontrado", você pode corrigi-lo?
Stiefel

@ Stiefel: eu consertei. O novo link aponta para uma versão muito melhorada.
Arnold Neumaier 13/09/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.