Desenvolvimento de um interpretador de problemas para otimização não linear

(1)

Desenvolvimento de um Interpretador

de Problemas para Otimiza¸

c˜

ao N˜

ao Linear

Por

Christophe Teixeira

Orientador: Doutor Pedro Miguel Mestre Alves da Silva

Co-orientador: Doutora Aldina Isabel de Azevedo Correia

Disserta¸c˜ao submetida `a

UNIVERSIDADE DE TR ´AS-OS-MONTES E ALTO DOURO para obten¸c˜ao do grau de

MESTRE

em Engenharia Electrot´ecnica e de Computadores, de acordo com o disposto no DR – I s´erie – A, Decreto-Lei n.o _{74/2006 de 24 de Mar¸co com as altera¸c˜}_{oes introduzidas pelos}

Decretos-Leis n.o 107/2008, de 25 de Junho, e 230/2009, de 14 de Setembro, e demais legisla¸c˜ao aplic´avel e no Regulamento de Ciclo de Estudos Conducente ao Grau de Mestre da

Universidade de Tr´as-os-Montes e Alto Douro DR, 2.a s´erie – n.o 149/2011 de 4 de Agosto

(2)

(3)

Desenvolvimento de um Interpretador

de Problemas para Otimiza¸

c˜

ao N˜

ao Linear

Por

Christophe Teixeira

Orientador: Doutor Pedro Miguel Mestre Alves da Silva

Co-orientador: Doutora Aldina Isabel de Azevedo Correia

Disserta¸c˜ao submetida `a

UNIVERSIDADE DE TR ´AS-OS-MONTES E ALTO DOURO para obten¸c˜ao do grau de

MESTRE

em Engenharia Electrot´ecnica e de Computadores, de acordo com o disposto no DR – I s´erie – A, Decreto-Lei n.o _{74/2006 de 24 de Mar¸co com as altera¸c˜}_{oes introduzidas pelos}

Decretos-Leis n.o 107/2008, de 25 de Junho, e 230/2009, de 14 de Setembro, e demais legisla¸c˜ao aplic´avel e no Regulamento de Ciclo de Estudos Conducente ao Grau de Mestre da

Universidade de Tr´as-os-Montes e Alto Douro DR, 2.a s´erie – n.o 149/2011 de 4 de Agosto

(4)

(5)

Orienta¸c˜ao Cient´ıfica :

Doutor Pedro Miguel Mestre Alves da Silva Professor Auxiliar do

Departamento de Engenharias Escola de Ciˆencias e Tecnologia Universidade de Tr´as-os-Montes e Alto Douro

Doutora Aldina Isabel de Azevedo Correia Professora Adjunta do

Departamento de Matem´atica

Escola Superior de Estudos Industriais e de Gest˜ao Instituto Polit´ecnico do Porto

Acompanhamento do trabalho :

Doutor Jo˜ao Lu´ıs Hon´orio Matias

Professor Auxiliar do Departamento de Matemática Escola de Ciências e Tecnologia Universidade de Trás-os-Montes e Alto Douro

(6)

(7)

”A perfei¸cão não é alcan¸cada quando já não há mais nada para adicionar, mas quando já não há mais nada que se possa retirar”

Antoine de Saint-Exup´ery

A quem dedico,

Albano de Moura Teixeira, Maria Assun¸c˜ao Ara´ujo Teixeira, Catherine Teixeira, Caroline Teixeira, L´ucia Valentina Teixeira, Tatiana Ferreira Moura.

(8)

(9)

UNIVERSIDADE DE TR ´AS-OS-MONTES E ALTO DOURO Mestrado em Engenharia Electrot´ecnica e de Computadores

Os membros do Júri recomendam à Universidade de Trás-os-Montes e Alto Douro a aceita¸cão da disserta¸c˜ao intitulada “ Desenvolvimento de um Interpretador de

Problemas para Otimiza¸c˜ao N˜ao Linear” realizada por Christophe Teixeira

para satisfa¸c˜ao parcial dos requisitos do grau de Mestre. Janeiro 2014

Presidente: Doutor Jos´e Carlos Silva Cardoso,

Direçcão do Mestrado em Engenharia Electrotécnica e de Computadores do Departamento de Engenharias

da Escola de Ciˆencias e Tecnologia

Universidade de Tr´as-os-Montes e Alto Douro

Vogais do J´uri: Doutora Isabel Cristina Lopes,

Professora Adjunta do Departamento de Matemática da Escola Superior de Estudos Industriais e de Gestão Instituto Politécnico do Porto

Doutor Pedro Miguel Mestre Alves da Silva,

Professor Auxiliar do Departamento de Engenharias da Escola de Ciˆencias e Tecnologia

Universidade de Tr´as-os-Montes e Alto Douro

(10)

(11)

Desenvolvimento de um Interpretador

de Problemas para Otimiza¸c˜

ao N˜

ao Linear

Christophe Teixeira

Submetido na Universidade de Tr´as-os-Montes e Alto Douro para o preenchimento dos requisitos parciais para obten¸c˜ao do grau de

Mestre em Engenharia Electrot´ecnica e de Computadores

Resumo — No ˆambito da resolu¸cão de problemas de otimiza¸cão não linear, existem problemas com expressões das fun¸cões envolvidas demasiado complexas, não suaves ou até mesmo desconhecidas, com derivadas não dispon´ıveis, não sendo assim poss´ıvel recorrer a métodos baseados em derivadas. Desta forma, para a sua resolu¸cão são utilizados em alternativa métodos de pesquisa directa. Para a resolu¸cão deste tipo de problemas foi criada uma API (Application Programming Interface), em tecnologia Java, baseada nesses métodos de pesquisa directa. Para a utiliza¸cão dessa ferramenta ´

e necessário que os problemas se encontrem na sua forma geral, ou seja, é necessário estarem definidos dados de entrada como a fun¸cão objetivo, ponto incial e fun¸cões restri¸cão, se existirem.

Na presente disserta¸cão é apresentada uma ferramenta, em tecnologia Java, capaz de formular esses problemas a partir de ficheiros codificados em AMPL (A Modeling Language for Mathematical Programming). Dessa formula¸cão resulta um ficheiro Java, que, uma vez compilado, pode ser utilizado como instância da classe utilizada pela API supra mencionada, contendo todos os dados do problema. Desta forma, tendo como dados de entrada o ficheiro criado, é poss´ıvel chegar à solu¸cão do problema utilizando a API.

Palavras Chave: Tecnologia JAVA, AMPL, Problemas de Otimiza¸c˜ao N˜ao Linear, Codifica¸c˜ao de Problemas, Interpretadores.

(12)

(13)

Development of a Problems Solver

for Nonlinear Optimization

Christophe Teixeira

Submitted to the University of Tr´as-os-Montes and Alto Douro in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering and Computers

Abstract — In the context of solving nonlinear optimization problems, there are

problems with too complex expressions, with unknown derivatives, and thus it is not possible to use derivative based optimization methods to solve them. Therefore Direct Search Methods can be used as an alternative. Based on those methods, it was created an API (Application Programming Interface), using JAVA technology, to solve this kind of problems. Problems must be in their general form to allow the utilization of this tool, i.e., input data must be defined such as the objective function, initial point and constraint functions, if there are any.

In this work it is presented a tool, developed in Java, capable of formulating these problems from files encoded in AMPL (A Modeling Language for Mathematical Programming). This formulation results in a Java file, which after being compiled can be used as an instance of the class used by the above mentioned API, containing all the data of the problem. Thus, taking as an input the created file it is possible to find the solution for the problem using the API.

Key Words: JAVA Technology, AMPL, Nonlinear Optimization Problems, Encoding

Problems, Parser.

(14)

(15)

Agradecimentos

Gostaria de agradecer a todas as pessoas que de certa forma ajudaram na realiza¸cão deste trabalho, nomeadamente a todos os responsáveis pela cria¸cão e manuten¸cão de toda a log´ıstica necessária ao bom funcionamento, forma¸cão e aprendizagem do Mestrado em Engenharia Electrotécnica e de Computadores. Gostaria ainda de agradecer de forma particular às pessoas que, de uma forma ou de outra, participaram mais activamente na realiza¸cão deste trabalho. São elas:

Ao Professor Doutor Pedro Miguel Mestre Alves da Silva, Professor Auxiliar do Departamento de Engenharias da Universidade de Trás-os-Montes e Alto Douro, orientador deste trabalho, pela paciência, pelas orienta¸cões e, principalmente, pela oportunidade de aprender com a experiência e conhecimento cient´ıfico que lhe pertence.

`

A Professora Doutora Aldina Isabel de Azevedo Correia, Professor Adjunto da Escola Superior de Tecnologia e Gestão de Felgueiras, do Instituto Politécnico do Porto, na qualidade de co-orientadora, pelas suas observa¸cões e orienta¸cões e explica¸cões.

Ao Professor Doutor João Lu´ıs Honório Matias, Professor Auxiliar do Departamento de Matemática da Universidade de Trás-os-Montes e Alto Douro, pelo apoio

(16)

prestado, pelas suas observa¸cões, sugestões e explica¸cões.

A todos os meus amigos, pelo apoio que me deram, por estarem sempre presentes e por todos os momentos de divers˜ao que me proporcionaram ao longo deste percurso.

`

A minha namorada, Tatiana Ferreira Moura, pelo carinho, compreens˜ao e simplesmente por estar sempre ao meu lado.

Aos meus Pais, que tornaram todo este percurso poss´ıvel e a quem devo tudo o que tenho e tudo o que sou, e às minhas irmãs, por todo o apoio incondicional que sempre me deram e pela paciência nos momentos mais dif´ıceis, sem eles não teria chegado até aqui.

A todos, um sincero obrigado!

UTAD, Christophe Teixeira

Vila Real, 31 de Outubro de 2013

(17)

´Indice geral

Resumo xi

Abstract xiii

Agradecimentos xv

´_{Indice de tabelas} _xix

´_{Indice de figuras} _xxi

Gloss´ario, acr´onimos e abreviaturas xxiii

1 Introdu¸c˜ao 1

1.1 Enquadramento . . . 1

1.2 Objetivos . . . 2

1.3 Motiva¸c˜ao e Contribui¸c˜oes . . . 3

1.4 Organiza¸c˜ao da disserta¸c˜ao. . . 3

2 API de Otimiza¸cão não Linear 5 2.1 Introdu¸cão . . . 5

2.2 M´etodos de Otimiza¸c˜ao. . . 7

2.3 Implementa¸c˜ao dos M´etodos em Java . . . 15

3 Codifica¸cão de Problemas Matemáticos 23 3.1 Introdu¸cão . . . 23

(18)

3.2 Principais Codifica¸c˜oes . . . 24

4 Codifica¸c˜ao AMPL 37 4.1 Introdu¸c˜ao . . . 37

4.2 Interpretadores e Solvers de codififca¸c˜ao AMPL . . . 39

5 Desenvolvimento e Implementa¸c˜ao do Interpretador 49 5.1 Introdu¸c˜ao . . . 49

5.2 Tecnologia Java . . . 49

5.3 Codifica¸c˜ao AMPL . . . 50

5.3.1 Interpreta¸c˜ao do Ficheiro . . . 51

5.3.2 Interpreta¸cão dos Parâmetros e das Variáveis. . . 53

5.3.3 Interpreta¸cão da Fun¸cão Objetivo e Fun¸cões Restri¸cão . . . . 57

5.3.4 Interpreta¸cão de Operadores e Fun¸cões Matemáticos . . . 60

5.3.5 C´alculos Aritm´eticos . . . 62

5.3.6 Cria¸c˜ao do Problema em Java . . . 63

5.4 Utiliza¸c˜ao do Interpretador. . . 64

5.5 Codifica¸c˜ao SIF . . . 66

6 Testes, Resultados e Conclus˜oes 69 6.1 Introdu¸c˜ao . . . 69

6.2 Testes e Resultados das Fun¸c˜oes Implementadas . . . 70

6.3 Testes e Resultados do Interpretador . . . 71

6.4 Testes e Resultados da Utiliza¸c˜ao da API . . . 73

6.5 Conclus˜oes e Trabalho Futuro . . . 76

Referˆencias bibliogr´aficas 79

A Exemplo de Codifica¸c˜oes 85

B Resultados da Interpreta¸c˜ao de Problemas AMPL 91

(19)

´Indice de tabelas

3.1 Tabela para Declara¸cão de Parâmetros na Codifica¸cão Gams . . . 26

6.1 Tempos de execu¸c˜ao, em milissegundo, utilizando o parser da API . . 74

6.2 Tempos de execu¸c˜ao, em milissegundo, utilizando problemas em JAVA 74

6.3 Tempos de execu¸c˜ao, em milissegundo, utilizando problemas gerados pelo interpretador . . . 74

6.4 Compara¸c˜ao dos tempos, em milissegundo, de resolu¸c˜ao de Problemas 75

B.1 Resultados para Problemas sem Restri¸c˜oes . . . 91

B.2 Resultados para Problemas com Restri¸c˜oes . . . 92

(20)

(21)

´Indice de figuras

1 M´ınimo Local . . . xxv

2.1 Movimento de reflex˜ao (Fonte: [1]) . . . 8

2.2 Movimento de Nelder-Mead (Fonte: [1]). . . 9

2.3 Funcionamento do M´etodo dos Filtros (Fonte: [1]) . . . 14

2.4 Filtro com quatro pontos (Fonte: [1]) . . . 15

2.5 Diagrama de Classes da API . . . 17

2.6 Exemplo de utiliza¸c˜ao da API Via Java . . . 19

2.7 Exemplo de utiliza¸c˜ao da API Via Web Services . . . 19

2.8 Exemplo de utiliza¸c˜ao da API Via Web Vers˜ao 1 . . . 20

2.9 Exemplo de utiliza¸c˜ao da API Via Web Vers˜ao 2 . . . 21

2.10 Exemplo de utiliza¸cão da API para análise do processo iterativo Via Web Versão 2 . . . 21

3.1 N´umero de utiliza¸c˜oes (Fonte: [2]) . . . 25

3.2 Utiliza¸c˜ao em percentagem (Fonte: [2]) . . . 25

3.3 Problema de otimiza¸c˜ao HS62 codificado em GAMS . . . 26

3.4 Divis˜ao da Matriz (Fonte: [3]) . . . 28 xxi

(22)

3.5 Exemplo de um problema de otimiza¸c˜ao e a sua codifica¸c˜ao em SPARSE SDPA (Fonte: [3]) . . . 29

3.6 Estrutura das colunas da codifica¸c˜ao MPS (Fonte: [4]) . . . 30

3.7 Problema de otimiza¸c˜ao codificado em MPS (Fonte: [4]) . . . 31

3.8 Problema de otimiza¸c˜ao Burglar2 codificado em MOSEL (Fonte: [5]) 32

3.9 Palavras-chave utilizadas pela codifica¸c˜ao CPLEX para os tipos de dados (Fonte: [6]) . . . 36

3.10 Problema de otimiza¸c˜ao codificado em CPLEX (Fonte: [7]) . . . 36

4.1 Problema S353 codificado em AMPL . . . 38

5.1 Problema S233 codificado em AMPL . . . 52

5.2 Interpreta¸c˜ao do Ficheiros . . . 54

5.3 Interpreta¸cão dos Parâmetros e das Variáveis . . . 56

5.4 Declara¸c˜ao de Vari´aveis do Problema S233 . . . 56

5.5 Declara¸c˜ao de Vari´aveis do Problema S380 . . . 57

5.6 Interpreta¸cão da Fun¸cão Objetivo e Fun¸cões Restri¸cão . . . 58

5.7 Defini¸c˜ao das restri¸c˜oes do Problema S330 . . . 60

5.8 Interface do Interpretador . . . 65

5.9 Declara¸c˜ao de Vari´aveis. . . 66

5.10 Declara¸c˜ao de Vari´aveis utilizando um Ciclo . . . 67

6.1 Resultado da Interpreta¸c˜ao das Vari´aveis . . . 70

6.2 Resultado da Interpreta¸c˜ao da Fun¸c˜ao Objetivo . . . 70

6.3 Resultado da Interpreta¸cão das Fun¸cões Restri¸cão . . . 70

(23)

Gloss´

ario, acr´

onimos e

abreviaturas

Gloss´

ario de termos

Fun¸cão Objetivo — Fun¸c˜ao matemática real de variáveis reais que, a partir das variáveis de decisão, define o valor da solu¸cão [1].

Fun¸cão Restri¸cão — Fun¸c˜ao matemática que define os valores aceitáveis ou admiss´ıveis das variáveis [1].

Fun¸c˜ao derivada — Dada uma fun¸c˜ao, f(x) num intervalo I ∈ R e x0 ∈ I, a derivada de f(x) em x0 ´e dada por [8]:

f′(x0) = lim

h→0

f (x0+h)−f(x0) h

Uma fun¸cão diz-se diferenci´avel se o for em todos os pontos do intervalo I. Assim, surge uma fun¸cão y, denominada por fun¸cão derivada, dada por:

y(x) = f′(x),∀ x ∈ R

(24)

Fun¸cão Suave — Fun¸c˜ao matemática em que é poss´ıvel determinar a sua 1a e 2a derivada em todo o seu dom´ınio [1].

Problemas não lineares inteiros mistos — Problemas matem´aticos constituidos por variáveis cont´ınuas discretas, com fun¸cão objetivo e fun¸cões restri¸cão não lineares [9].

Matriz hessiana — Matriz quadrada formada pelas segundas derivadas de uma

fun¸c˜ao [10], dada por:

Hıȷ(x) = δ_δ2f (x)

xıδxȷ

Fun¸c˜ao quadr´atica — Fun¸c˜ao dada por:

f (x) = ax2_{+ bx + c}

onde a, b, c s˜ao n´umeros reais e a̸= 0.

Fun¸c˜ao cont´ınua — Seja f uma fun¸c˜ao e a um ponto do dom´ınio de f . A fun¸c˜ao diz-se continua em a se:

lim

x→af (x) = f (a)

A fun¸c˜ao ´e cont´ınua se f ´e cont´ınua em todos os pontos do seu dom´ınio.

Fun¸cão Linear — Uma fun¸c˜ao linear é representada por uma equa¸cão de uma reta, ou seja, do tipo:

f (x) = ax + b

em que a e b s˜ao n´umeros reais, com a̸= 0. a representa o declive da reta e b ´e a intersec¸c˜ao com o eixo dos yy.

(25)

Fun¸c˜ao convexa — Sendo I um intervalo de R e f : I → R, f diz-se convexa se:

∀ a, b ∈ I e t ∈ [0, 1], f(ta + (1 − t)b) ≤ tf(a) + (1 − t)f(b)

ou seja, o gr´afico da fun¸c˜ao f fica sempre abaixo do segmento que une dois quaisquer pontos pertencentes a f .

M´ınimo local — Um ponto x0 ´e denominado de m´ınimo local quando f (x0) ≤

f (x) para todo x suficientemente pr´oximo de x0. Ilustrado na Figura1

Figura 1 – M´ınimo Local

Matriz Esparsa — Matriz que apresenta um grande n´umero de elementos igual a zero.

(26)

Lista de acr´

onimos

Sigla Expans˜ao

AMPL A Modeling Language for Mathematical Programming

SIF Standard Input Format

API Application Program Interface

Lista de abreviaturas

Abreviatura Significado(s)

et al. e outros (autores) etc. etecetera, outros i.e. isto ´e, por conseguinte

(27)

1

Introdu¸c˜

ao

1.1 Enquadramento

Quando falamos de problemas de otimiza¸cão, deparamo-nos com situa¸cões onde não ´

e poss´ıvel usar métodos baseados na deriva¸cão para as suas resolu¸cões, devido à complexidade das fun¸cões derivadas ou da própria fun¸cão objetivo ou em casos onde a fun¸cão objetivo é não suave ou até desconhecida. Nesses casos podemos recorrer a métodos de pesquisa directa [1]. Estes diferem em fun¸cão do tipo de problema, com ou sem restri¸cões.

Muitos desses problemas são codificados em linguagem matemática seguindo um formato padrão, tornando o seu processo de resolu¸cão mais fácil, visto que em alguns casos, onde os problemas possuem centenas de variáveis, o processo de entrada de dados pode tornar-se muito demorado e vulnerável a erros [11].

Uma vez o problema codificado, é então poss´ıvel obter a sua resolu¸cão utilizando interpretadores dependendo do tipo de codifica¸cão em que se encontra o problema. Alguns destes interpretadores não só formulam os problemas como também permitem a sua resolu¸cão utilizando vários métodos de otimiza¸cão. Tendo como dados de entrada ficheiros contendo os problemas, todo o processo de resolu¸cão é mais rapido

(28)

2 CAPÍTULO 1. INTRODUÇ ÃO

e pode ser feito a qualquer momento sem necessidade de reescrever o problema a cada resolu¸c˜ao.

1.2 Objetivos

Para a resolu¸cão de problemas de otimiza¸cão foi desenvolvida uma API (Application Programming Interface) [1], que recorre aos métodos de pesquisa directa, mas que, para a sua utiliza¸cão é necessário formular os dados de entrada como a fun¸cão objetivo, o valor dos pontos iniciais e as fun¸cões restri¸cão, caso existam. Esta formula¸cão é efectuada quer através de um ficheiro em Java, quer através da passagem destes dados (sob a forma de uma string) para uma classe que representa genericamente os problemas.

Este trabalho visa o desenvolvimento, em tecnologia Java, de uma ferramenta capaz de interpretar problemas matemáticos codificados em AMPL (A Modeling Language for Mathematical Programming). Feita essa interpreta¸cão, a ferramenta deve formular o problema na sua forma geral, ou seja, definir a sua fun¸cão objetivo, as fun¸cões restri¸cão e os seus pontos iniciais. A partir destes dados deve ser criado e compilado um ficheiro Java contendo fun¸cões capazes de devolver a dimensão do problema, o valor do pontos iniciais das variáveis, o número de restri¸cões de cada tipo, o número total de restri¸cões, o tipo de uma determinada restri¸cão, o valor de uma determinada fun¸cão restri¸cão num determinado ponto e o valor da fun¸cão objetivo num determinado ponto.

Para a resolu¸cão do problema, deverá ser poss´ıvel à API recorrer ao ficheiro compilado, não sendo assim necessário a formula¸cão e introdu¸cão do problema por parte do utilizador. Além disso o utilizador não deverá necessitar de ter conhecimentos de programa¸cão para criar um novo problema.

(29)

1.3. MOTIVAÇ ÃO E CONTRIBUIÇ ÕES 3

1.3 Motiva¸

c˜

ao e Contribui¸

c˜

oes

Este trabalho veio complementar trabalhos já realizados, nomeadamente a API referida, permitindo assim a utiliza¸cão de problemas codificados em AMPL no estudo de métodos para a otimiza¸cão de problemas. Obtendo um problema formulado a partir destes ficheiros é poss´ıvel a utiliza¸cão da API de uma forma simples e imune a poss´ıveis erros na formula¸cão dos problemas feita pelo utilizador. Para além de tornar poss´ıvel o estudo de um problema sem necessidade do utilizador o formular a cada utiliza¸cão, a utiliza¸cão dos problemas codificados permite ainda a utiliza¸cão da API no estudo de problemas que envolvem centenas de variáveis e restri¸cões, que seria impraticável se o problema fosse formulado e inserido pelo utilizador. Existem ainda bibliotecas de problemas ”padrão”codificados em AMPL, normalmente utilizados para testar métodos de otimiza¸cão, que passam a ser utilizáveis pela API.

De referir ainda que a API existente recorre a um parser que interpreta as express˜oes introduzidas pelo utilizador. Desta forma é poss´ıvel desenvolver aplica¸cões que aceitam em run-time as express˜oes dos problemas. Contudo, este parser, para além de não aceitar os problemas ”padrão”existentes, apresenta problemas ao n´ıvel da velocidade de execu¸cão. Assim, com o presente trabalho pretende-se também resolver este problema de desempenho, criando um ”novo”interpretador/parser mais eficiente recorrendo à compila¸cão dinâmica de código.

1.4 Organiza¸

c˜

ao da disserta¸

c˜

ao

Esta disserta¸cão encontra-se estruturada em seis cap´ıtulos. No presente Cap´ıtulo é feita uma introdu¸cão de enquadramento e apresenta-se os objetivos e motiva¸cões do trabalho, resumindo desta forma o trabalho realizado.

No Cap´ıtulo 2 faz-se uma abordagem à otimiza¸cão não linear, sendo apresentados os métodos tidos em conta para a resolu¸cão deste tipo de problemas.

(30)

4 CAPÍTULO 1. INTRODUÇ ÃO

´

E feita uma abordagem, no Cap´ıtulo 3 e 4, às codifica¸cões existentes para problemas de otimiza¸cão, sendo no Cap´ıtulo 3 apresentadas as mais utilizadas no último ano e no Cap´ıtulo 4 a codifica¸cão tida em conta neste trabalho, quanto às suas caracter´ısticas e às ferramentas existentes para interpreta¸cão e resolu¸cão dos problemas codificados. No Cap´ıtulo 5 é apresentada a implementa¸cão do interpretador da codifica¸cão referida, descrevendo todo o processo de formula¸cão do problema a partir do ficheiro, como pode ser utilizado e quais os resultados dessa utiliza¸cão.

A finalizar a disserta¸cão, é efectuada no Cap´ıtulo 6 uma apresenta¸cão e discussão dos resultados obtidos nos testes realizados ao interpretador e apresentam-se no final deste, as conclusões e algumas perspectivas de trabalho futuro.

(31)

2

API de Otimiza¸c˜

ao n˜

ao Linear

2.1 Introdu¸

c˜

ao

Entende-se por otimiza¸cão de problemas a obten¸cão de uma solu¸cão, ou um conjunto de solu¸cões, ótimas para uma determinada fun¸cão ou conjunto de fun¸cões. Em otimiza¸cão o valor ótimo de uma fun¸cão tanto pode ser o seu m´ınimo como o seu máximo. Nesta disserta¸cão será considerado o m´ınimo. Em problemas relativamente simples de resolver podem ser utilizados métodos baseados em derivadas, no entanto existem problemas onde esses métodos não podem ser aplicados devido à sua complexidade, ao facto da fun¸cão objetivo ser não suave ou mesmo desconhecida e das suas derivadas não estarem dispon´ıveis [12]. Como alternativa podem ser utilizados os denominados métodos de pesquisa direta.

Os métodos de pesquisa direta vão progredindo em dire¸cão ao valor ótimo, tendo como base a compara¸cão de valores da fun¸cão objetivo em diversos pontos. Sendo esta a única informa¸cão que utilizam, permitem a resolu¸cão de problemas onde a fun¸cão objetivo e as restri¸cões podem ser não suaves, não lineares, descont´ınuas, não convexas e com muitos m´ınimos locais [10].

Para que a resolu¸cão de um problema seja poss´ıvel é necessário que este esteja 5

(32)

6 CAPÍTULO 2. API DE OTIMIZAÇ ÃO N ÃO LINEAR

formulado, isto é, estarem definidas as suas variáveis, a fun¸cão objetivo e as fun¸cões restri¸cão. Esta formula¸cão depende do tipo de problema [13], com ou sem restri¸cões. Assim os problemas sem restri¸cões têm a forma de (2.1):

min

x∈Rn f (x) (2.1)

Onde f : Rn_{→ R ´e a fun¸c˜ao objetivo;}

Por outro lado, os problemas com restri¸c˜oes tˆem a forma de (2.2): min x∈Rn f (x) sujeito a ci(x) = 0, i∈ E ci(x)≤ 0, i ∈ I (2.2) Onde:

• f : Rn _{→ R ´e a fun¸c˜ao objetivo;}

• ci(x) = 0, i∈ E = {1, 2, ..., t}, representam as restri¸c˜oes de igualdade;

• ci(x)≤ 0, i ∈ I = {t+1, t+2, ..., m}, representa as restri¸c˜oes de desigualdade; • Ω = {x ∈ Rn_{: c}

i = 0, i∈ E ∧ ci(x)≤ 0, i ∈ I} ´e o conjunto de todos os pontos

admiss´ıveis, i.e., define a regi˜ao admiss´ıvel.

Identificado o tipo de problema, e feita a sua formula¸cão matemática, é necessário selecionar o método de otimiza¸cão mais adequado para a sua resolu¸cão, algo que se pode tornar dificil visto existirem incertezas em rela¸cão ao método que melhor aproxima a solu¸cão ótima do problema. No entanto a solu¸cão não depende apenas do método utilizado mas támbem da formula¸cão matemática do problema [1].

(33)

2.2. MÉTODOS DE OTIMIZAÇ ÃO 7

2.2 M´

etodos de Otimiza¸

c˜

ao

Os métodos apresentados neste trabalho para resolu¸cão de problemas de otimiza¸cão não linear são os métodos utilizados pela API referida anteriormente. Estes métodos, a seguir apresentados, diferem em fun¸cão do tipo de problema, com ou sem restri¸cões.

M´

etodos de Otimiza¸

c˜

ao para Problemas sem Restri¸

c˜

oes

Para a resolu¸cão de problemas sem restri¸cões encontram-se implementados os seguintes métodos [1]:

• Método de pesquisa coordenada – É o método de pesquisa padrão mais

simples [12]. Partindo de uma itera¸c˜ao xk, este m´etodo determina a pr´oxima

itera¸cão, procurando num padrão de pontos ou grelha de pontos, usando dire¸cões fixas com distˆancia d a xk, com d ∈ R+. Este método avalia o

comportamento da fun¸c˜ao objetivo ao longo do padr˜ao de pontos. No exemplo de um problema de minimiza¸c˜ao, se no ponto seguinte, Pi, se verificar uma

redu¸c˜ao simples, ou seja, se f (Pi) < f (xk) ent˜ao esse ponto Pi´e a aproxima¸c˜ao

seguinte. Se não se verificar nenhuma redu¸cão em nenhuma dire¸cão, então a distˆancia d ´e reduzida, usualmente para metade, e é feito o teste ao novo padrão de pontos.

• Método de Hooke e Jeeves – Também ele um método de pesquisa padrão,

diferencia-se do m´etodo de pesquisa coordenada por utilizar um passo padr˜ao

ao analisar a informa¸cão gerada das itera¸cões anteriores bem sucedidas. Se a itera¸cão anterior for bem sucedida, então a dire¸c˜ao xk+1−xké considerada uma

dire¸c˜ao promissora e a pesquisa ´e feita em torno de xp = xk+1+ (xk+1− xk).

Se for bem sucedida o ponto é aceite, senão a pesquisa é feita em torno de

xk+1, tal como acontecia no m´etodo de pesquisa coordenada.

• M´etodo de Audet et. al. – Semelhante ao m´etodo pesquisa coordenada

(34)

passo, passo de pesquisa, consiste no cálculo do valor da fun¸cão objetivo num número finito de pontos tentando encontrar um ponto com menor valor da fun¸cão objetivo. O segundo passo, passo de sondagem, realizado quando o passo de pesquisa não obteve sucesso, consiste na usual pesquisa coordenada em torno da itera¸cão actual.

• Método de Nelder-Mead – O método Nelder-Mead, método Simplex, consiste

na constru¸c˜ao de um Simplex S constituido por um conjunto de n + 1 pontos,

{xi}n+1

i=1, em Rn, ou seja, ´e um poliedro em Rn com n + 1 faces, onde xi ´e o

i-ésimo v´ertice do Simplex S. Sendo um m´etodo Simplex, a itera¸cão seguinte é calculada através da reflexão isométrica do pior vértice, em rela¸cão ao centroide dos n melhores v´ertices, exemplificada na figura 2.1. Se o valor da fun¸cão objetivo no vértice refletido for inferior, o novo vértice é candidado a minimizante, caso contrário escolhe-se o segundo pior vértice e repete-se o processo.

(35)

Pala além deste movimento de reflexão, o método Nelder-Mead introduziu movimentos não isométricos, conhecidos como movimentos de expansão e contraçcão, complementados por um passo de redu¸cão, ou passo encolhido, de todo o Simplex em dire¸cão ao melhor vértice. Este último é utilizado quando os movimentos de expansão e contraçcão não apresentam um valor inferior para a fun¸cão objetivo tendo em conta o novo vértice refletido. Neste caso repete-se todo o processo tendo como base o novo Simplex reduzido. Estes movimentos são apresentados na figura 2.2, sendo o xk o melhor vértice do

Simplex.

(36)

• M´etodo Simplex Convergente - Semelhante ao m´etodo de Nelder-Mead,

introduz um novo passo, chamado de passo de salvaguarda, consiste numa rota¸c˜ao do Simplex em torno do melhor v´ertice v0:

vrot,i= v0− (vi− v0), i = 1, ..., n.

No primeiro passo deste método, antes do movimento de reflexão, é necessário escolher e determinar uma série de parâmetros utilizados ao longo do método e fazer alguns ajustes aos dados. São eles:

– Ordenar os n + 1 v´ertices do Simplex S = {v₀(0), v₁(0), ..., vn(0)}, de modo

que:

f0 = f (v0)≤ f1 = f (v1)≤ ... ≤ fn= f (vn).

– Determinar ∆ = diam(S), onde diam(S) representa o diˆametro de S.

– Tendo o Simplex inicial S ={v(0)₀ , v(0)₁ , ..., vn(0)}, escolher ξ de modo que: von(S)≤ ξ

onde von(S) representa o volume de S e ξ ∈ R+_;

– Escolher os parˆametros de expans˜ao, δe; de reflex˜ao, δr; de contraçcão para o exterior, δoc_{; de contraçc˜}_{ao para o interior, δ}ic_{; o ´ındice de redu¸c˜}_ao

do Simplex, γs_{; e o parˆ}_{ametro de controlo do diˆ}_{ametro do Simplex, γ}e_,

de modo que:

0 < γs < 1 < γe, −1 < δic_{< 0 < δ}oc_{< δ}r _{< δ}e_.

Após o cálculo da reflexão do Simplex (apresentado no método Nelder-Mead), se este movimento não apresentar um decrésimo no valor da fun¸cão objetivo, este método verifica as condi¸cões apresentadas em (2.3) e, se não forem satisfeitas, procede ao passo de salvaguarda. No caso das condi¸cões serem satisfeitas o método, tal como o método de Nelder-Mead, procede aos movimentos de expansão, contraçcão e redu¸cão.

(37)

diam({v0, v1, vn−1} ∪ {vr}) ≤ γe∆, von({v0, v1, vn−1} ∪ {vr}) ≥ ξ.

(2.3)

M´

etodos de Otimiza¸

c˜

ao para Problemas com Restri¸

c˜

oes

A API contém, implementados até ao momento, para resolver problemas com restri¸cões métodos de Penalidade ou Barreira e o método dos Filtros [1]. Considerando o problema apresentado em (2.2), estes métodos de otimiza¸cão para problemas não lineares com restri¸cões convertem, no caso do método dos Filtros, o problema em dois problemas sem restri¸cões, e no caso dos métodos Penalidade ou Barreira o problema é convertido em sub-problemas sem restri¸cões, que são resolvidos usando os algoritmos anteriormente apresentados, utilizados para resolver problemas sem restri¸cões.

O que diferencia estes métodos é o facto do método dos Filtros ter em conta a otimalidade e viabilidade separadamente, isto é, a finalidade em minimizar a fun¸cão objetivo e minimizar as viola¸cões das restri¸cões enquanto que os métodos de Penalidade e Barreira tratam a otimalidade e viabilidade em conjunto [13].

M´etodos de Penalidade ou Barreira

Tanto os métodos de Penalidade como de Barreira, come¸cam por converter o problema com restri¸cões do tipo (2.2) num problema sem restri¸cões, apresentado em (2.4), criando para tal uma nova fun¸cão objetivo, contendo informa¸cão da fun¸cão objetivo original, f , e das restri¸cões do problema ci, i = 1, ..., m:

min

x∈Rn Φ(xk, rk) (2.4)

onde:

(38)

• rk ´e o parˆametro de penalidade ou barreira, com um valor real positivo;

• p ´e uma fun¸c˜ao que penaliza (Penalidade) ou recusa (Barreira) pontos que

violem as restri¸c˜oes;

A nova fun¸c˜ao objetivo Φ a otimizar difere para cada m´etodo de Penalidade e Barreira, abaixo apresentadas.

• Método de Penalidade Estática e Dinâmica:

Ambos os métodos têm a mesma fun¸cão Φ, apresentada em (2.5). Φ(x) = f (x) + t ∑ i=1 αi|ci(x)|q+ m ∑ i=t+1 βi[max(0, ci(x))]q, q≥ 1 (2.5)

No entanto, nos métodos implementados na API, os parâmetros utilizados na fun¸cão Φ são actualizados de forma diferente. No método de Penalidade Estática é feita da seguinte forma:

parametro ={γ.α1, ..., γ.αt, γ.β1, ..., γ.βm−t}, γ > 1.

No método de Penalidade Dinâmica, os parâmetros são actualizados da seguinte forma:

q > 1;

(C = γ) > 0;

αi(k + 1) = αi(k) + C.|ci(x)|, i = 1, ..., t; βi(k + 1) = βi(k) + C.[max(0, ci(x))], i = t + 1, ..., m. • Fun¸c˜ao Barreira Progressiva:

Φ(x) = f (x) + bx(x) (2.6) onde, bx(x) =        m ∑ i=1 [max(ci(x), 0)]2 se x∈ X +∞ se x /∈ X com Ω∈ X. (2.7)

(39)

• Fun¸c˜ao Barreira Extrema:

Φ(x) =      f (x) se x∈ Ω +∞ se x /∈ Ω . (2.8)

• M´etodo de Penalidade Cl´assica:

Φ(x) = f (x) + p(x) = f (x) + rk m ∑ i=1 [max(0, ci(x))]q, q≥ 1. (2.9) • M´etodo de Penalidade ℓ1 : Φ(x) = ℓ1(x, µ) = f (x) + µ t ∑ i=1 |ci(x)| + µ m ∑ i=t+1 [max(ci(x), 0)], µ−→ +∞. (2.10)

Como é vis´ıvel nas fun¸cões acima apresentadas, o método de Penalidade soma à fun¸cão original um valor de penalidade em fun¸cão da viola¸cão das restri¸cões, quanto maior for a viola¸cão, maior é o valor de penalidade, aumentando assim o valor da nova fun¸cão objetivo, afastando-se do seu valor ótimo. Uma vez que o método de otimiza¸cão pretende chegar ao valor ótimo da fun¸cão, a itera¸cão seguinte será calculada com objetivo de diminuir o valor da penalidade. Utilizando as fun¸cões Barreira, no caso da Barreira Extrema, esta não permite aceitar pontos fora da região admiss´ıvel Ω, região criada pelas restri¸cões do problema, atribuindo o valor +∞ à fun¸cão objetivo. Para o caso da fun¸cão Barreira Progressiva, esta não permite aceitar pontos fora da regi˜ao admiss´ıvel X, regi˜ao criada pelas restri¸cões relaxáveis do problema, atribuindo o valor +∞ à fun¸cão objetivo. As restri¸cões relaxáveis são restri¸cões que podem ser satisfeitas apenas aproximadamente, possibilitando o cálculo das fun¸cões fora da região admiss´ıvel, definida por elas, considerando uma certa tolerância.

(40)

M´etodo dos Filtros

Este método converte os problemas com restri¸cões em problemas com 2 fun¸cões distintas, sendo uma, f , contendo a fun¸cão objetivo original, f , e a outra, h, contendo a informa¸cão das restri¸cões do problema. Tendo estas fun¸cões, come¸ca-se por verificar se o valor do ponto xk está contido na região admiss´ıvel Ω, região essa

definida pelas restri¸cões do problema. Se o ponto estiver contido em Ω, a fun¸cão tida em conta pelo método de otimiza¸cão é a fun¸c˜ao f , caso contr´ario, é tida em conta a fun¸c˜ao h. O m´etodo procede à verifica¸c˜ao do ponto no Filtro, caso seja aceite, o

Filtro ´e actualizado e o método procede à itera¸cão seguinte (no caso de não serem verificados os critérios de paragem). No caso do ponto n˜ao ser aceite no Filtro ´e utilizado um método para resolu¸cão de problemas sem restri¸cão para o cálculo da itera¸cão seguinte para a fun¸c˜ao objetivo, f ou h, dependendo se o ponto anterior era admiss´ıvel ou não. Obtendo a itera¸cão seguinte, o método do Filtros repete todo o processo. É apresentado na figura2.3 o diagrama de funcionamento do método dos Filtros.

Figura 2.3 – Funcionamento do M´etodo dos Filtros (Fonte: [1])

(41)

2.3. IMPLEMENTAÇ ÃO DOS MÉTODOS EM JAVA 15

do conjuntoF tem rela¸cão x ≺ y, ou seja, o Filtro é constituido por pontos tal que nenhum domina outro. É apresentado na figura2.4um Filtro constituido por quatro pontos, a, b, c e d, que definem a zona proibida, representada a sombreado. Se um novo ponto testado no Filtro for representado por y, situado na zona proibida, este não é aceite. Ao contr´ario dos pontos z e w, que n˜ao se encontram na zona proibida, seriam aceites e incluido no Filtro. No caso do ponto w seriam eliminados os pontos

c e d, visto que, ao actualizar o Filtro com o novo ponto w, estes s˜ao dominados pelo novo ponto, logo seriam eliminados.

Figura 2.4 – Filtro com quatro pontos (Fonte: [1])

2.3 Implementa¸

c˜

ao dos M´

etodos em Java

Como já referido anteriormente, este trabalho visa complementar um outro trabalho já realizado [1], uma API (Application Programming Interface) que permite resolver problemas de otimiza¸cão, utilizando a tecnologia Java. Esta API permite, a partir de um problema formulado, obter a sua solu¸cão ótima, recorrendo aos vários métodos antes apresentados.

(42)

Para cada método existe uma Classe associada, apresentada na figura 2.5, que permite ao utilizador a sua utiliza¸cão, para tal necessita de definir o valor das variáveis dessas Classes que representam os dados do problema. Essa defini¸cão é feita através dos construtores da Classe, que permitem o processo de duas formas:

• Os parâmetros de entrada são a Fun¸cão objetivo, f e o vector dos valores

iniciais da vari´avel x0, sob a forma de String´s, neste caso a API recorre a um

parser que interpreta essas Strings;

• O parâmetro de entrada é uma instância da Classe ProblemaGeral. Esta Classe

representa o problema em quest˜ao, contendo os respetivos dados.

No caso dos problemas com restri¸cões, existem apenas duas Classes, uma para os métodos de Penalidade e Barreira e outra para o método dos Filtros. Para além dos parâmetros de entrada acima apresentados, o construtor da Classe associada aos métodos de Penalidade e Barreira tem também os seguintes parâmetros:

• Vector de Restri¸c˜oes;

• O m´etodo interno a utilizar; • O m´etodo externo a utilizar.

Para o método dos Filtros, o construtor da Classe associada tem, para além dos dados do problema, os seguintes dados parâmetros:

• Vector de Restri¸c˜oes; • A medida h a utilizar; • O m´etodo externo a utilizar.

(43)

Figura 2.5 – Diagrama de Classes da API

Todos os dados acima apresentados podem não só ser definidos nos construtores das Classes, como também através de m´etodos SET (m´etodos que permitem definir o valor dos atributos). Os outros métodos disponibilizados pelas Classes são os métodos que devolvem os resultados do problema e alguns dados sobre o processo iterativo. São eles:

• run(), executa o algoritmo de resolu¸c˜ao do problema; • getDim(), devolve a dimens˜ao do problema;

(44)

nEvals;

• getSolution(), devolve a aproxima¸cão à solu¸cão encontrada, x* ;

• evaluateF(x), devolve o valor da fun¸c˜ao objetivo na aproxima¸c˜ao f(x), tem

como entrada o valor das vari´aveis, x ;

• evaluateH(n, xk), devolve o valor da restri¸c˜ao n para o valor da vari´avel na itera¸c˜ao k ;

• numerRestricoes(), devolve o n´umero de restri¸c˜oes;

• numerRestricoes igualdade(), devolve o número de restri¸cões de igualdade; • numerRestricoes desigualdade(), devolve o número de restri¸cões de desigualdade; • numerRestricoes limiteSimples(), devolve o número de restri¸cões do tipo limites

simples.

A utiliza¸c˜ao desta API pode ser feita de v´arias formas, abaixo apresentadas:

• No computador local – Instalando a API, a partir do seu ficheiro .jar, no

próprio computador é poss´ıvel ter acesso a todas as suas classes, permitindo assim a sua utiliza¸cão [1]. Tendo acesso às classes da API torna-se poss´ıvel a resolu¸cão de um problema formulado e inserido pelo utilizador, como é apresentado na figura 2.6, no caso de um problema sem restri¸cões e utilizando por exemplo o método de Pesquisa Coordenada, onde a vari´avel expr ´e a fun¸cão objetivo e a vari´avel initPoint cont´em os valores dos pontos iniciais das vari´aveis. Utilizando o construtor da classe CoordinatedSearch ´e criada uma instância dessa Classe que contém os dados do problema enviados por parâmetros. Para resolu¸cão do problema é chamado o m´etodo run(), ao ser executado este método a solu¸cão é guardada num vector com a dimensão do problema. Vários métodos estão dispon´ıveis para obter os dados do problema, para o caso da solu¸cão é utilizado o m´etodo getLastResult(), que retorna o vector com os valores da solu¸cão [1].

(45)

Figura 2.6 – Exemplo de utiliza¸c˜ao da API Via Java

• Via Web Services – Permite aos utilizadores terem acesso remoto aos m´etodos

da API, não sendo necessário ter a API instalada no próprio computador. Uma outra vantagem desta implementa¸cão reside no facto de ser poss´ıvel aceder aos métodos não só utilizando a tecnologia Java, mas também muitas outras linguagens de programa¸cão, ao contrário da utiliza¸cão local da API, que apenas permite a utiliza¸cão desta com Java. Na figura 2.7 é apresentado um exemplo de acesso remoto à API utilizando Java. Para esta utiliza¸cão apenas é necessário a importa¸cão, por parte do utilizador, do ficheiro WSDL (Web Service Definition Language), disponibilizado na Web. Este ficheiro cria localmente todos os ficheiros necessários para a utiliza¸cão da API [14].

Figura 2.7 – Exemplo de utiliza¸c˜ao da API Via Web Services

• Via Web Vers˜ao 1 – Permite aos utilizadores inserirem os problemas formulados

e selecionarem os métodos de otimiza¸cão que pretendem. Como é vis´ıvel na Figura 2.8, o utilizador deve introduzir os dados do problema, i.e., o tipo de problema, a sua dimensão e quantas restri¸cões tem associadas, a fun¸cão objetivo, as fun¸cões restri¸cão e o valor do pontos iniciais. Após a introdu¸cão

(46)

destes dados e escolhido o método a utilizar o resultado é então apresentado ao utilizador [14].

Figura 2.8 – Exemplo de utiliza¸c˜ao da API Via Web Vers˜ao 1

• Via Web Vers˜ao 2 – Permite aos utilizadores inserirem os problemas formulados

e selecionarem os métodos de otimiza¸cão que pretendem. Tal como na versão 1, e vis´ıvel na Figura 2.9, é necessário para além do problema formulado, introduzir o tipo de problema, a sua dimensão e o número de restri¸cões. Esta versão permite além da solu¸cão, visualizar os dados do processo iterativo, apresentado na figura 2.10, permitindo uma análise de todo o processo, visto serem apresentados graficamente os valores das variáveis e da fun¸cão objetivo em cada itera¸cão. Os dados relativos ao processo de resolu¸cão são guardados em base de dados, podendo assim serem consultados posteriomente [13].

(47)

Figura 2.9 – Exemplo de utiliza¸c˜ao da API Via Web Vers˜ao 2

Figura 2.10 – Exemplo de utiliza¸cão da API para análise do processo iterativo Via Web Versão 2

(48)

(49)

3

Codifica¸c˜

ao de Problemas

Matem´

aticos

3.1 Introdu¸

c˜

ao

Uma vez que a otimiza¸cão envolve mais do que apenas a aplica¸cão de um algoritmo para minimizar ou maximizar uma fun¸cão objetivo, é necessário, antes de qualquer rotina de otimiza¸cão ser invocada, um esfor¸co considerável para formular o modelo matemático subjacente ao problema, e desta forma diminuir o esfor¸co computacional dos algoritmos de otimiza¸cão. A codifica¸cão dos problemas permite tornar estas etapas de formula¸cão mais fáceis e menos suscet´ıveis a erros [15].

Segundo Emmanuel Fragnière [16], a codifica¸cão utilizada deve permitir aos utilizadores codificarem problemas, mas também compreendê-los uma vez codificados, por outro lado, os computadores devem ser capazes de os ler e traduzir. Desta forma é poss´ıvel a qualquer pessoa codificar um problema e, se pretender, disponibilizá-lo em qualquer parte do mundo via Web.

Estando um problema codificado, é poss´ıvel ao utilizador obter a sua solu¸cão, utilizando um solver associado, sem necessidade de o formular e introduzir sempre que quiser obter a solu¸cão. Para além da vantagem de reutiliza¸cão de problemas já formulados, permite o estudo de problemas de grande escala, visto que existem

(50)

24 CAPÍTULO 3. CODIFICAÇ ÃO DE PROBLEMAS MATEM ÁTICOS

muitas situa¸cões onde um problema de otimiza¸cão apresenta apenas uma fun¸cão objetivo, restri¸cões simples e um número de variáveis relativamente baixo. No entanto, a maioria dos problemas da vida real envolvem centenas de restri¸cões e variáveis, não sendo pratic´avel para o utilizador formular e inserir num solver cada restri¸cão e cada variável [16].

3.2 Principais Codifica¸

c˜

oes

Tendo como base o NEOS (Network-Enabled Optimization System) Server, é poss´ıvel avaliar quais as codifica¸cões mais utilizadas na resolu¸cão de problemas por parte de quem utiliza este servi¸co.

O NEOS Server ´e um servi¸co livre baseado na Internet, que permite, atrav´es de uma abordagem simples, resolver uma grande variedade de problemas de otimiza¸cão, disponibilizando v´arios solvers para isso. De uma forma muito simples o utilizador seleciona o solver que pretende utilizar e, no caso de o solver interpretar mais que uma codifica¸cão, indica qual a codifica¸cão do problema que se pretende resolver. Após o utilizador selecionar o ficheiro onde o problema está contido, o resultado ´

e apresentado, sendo apresentados, entre outros dados, a solu¸cão, o número de variáveis e o número de restri¸cões.

Tendo em conta as estat´ısticas de utiliza¸cão, no ano de 2012, do NEOS Server, apresentadas no gráfico da Figura3.1, é poss´ıvel visualizar as principais codifica¸cões utilizadas na modela¸cão de problemas de otimiza¸cão quanto ao número de utiliza¸cões para cada codifica¸cão, e no gráfico da Figura 3.2 em termos percentuais. São apresentados os dados relativos aos dez interpretadores mais utilizados, no entanto o NEOS permite a resolu¸cão de problemas com vinte e sete codifica¸cões diferentes. De salientar que o NEOS teve no último ano 353 091 utilizadores.

São de seguida apresentadas breves explica¸cões das codifica¸cões mais utilizadas, nos gráficos apresentadas, com a exce¸cão da codifica¸cão AMPL que é apresentada no cap´ıtulo seguinte.

(51)

3.2. PRINCIPAIS CODIFICAC¸ ˜OES 25

Figura 3.1 – N´umero de utiliza¸c˜oes (Fonte: [2])

Figura 3.2 – Utiliza¸c˜ao em percentagem (Fonte: [2])

GAMS

A codifica¸cão GAMS consiste num conjunto de declara¸cões de dados, dados estes que dizem respeito às variáveis do problema, aos seus valores e à forma como estas constituem a fun¸cão objetivo e as fun¸cões restri¸cão. E apresentado na Figura´

3.3 um exemplo de um problema codificado em GAMS, problema 62 da cole¸c˜ao HockSchittkowski. Todos os dados declarados num ficheiro GAMS pertencem a uma das cinco classes existentes nesta codifica¸c˜ao. Estas classes, apresentadas a seguir, definem os tipos de dados do problema [17].

• SETS - Esta classe representa a declara¸c˜ao dos ´ındices utilizados tanto nos

(52)

Figura 3.3 – Problema de otimiza¸c˜ao HS62 codificado em GAMS

• PARAMETERS - Apresenta os parˆametros do problema, contendo o nome e

valor destes. Os parˆametros podem ser declarados de duas formas, de forma normal, apresentando o nome e valor correspondente, e sob a forma de tabela, como ´e apresentado na tabela 3.1.

Tabela 3.1 – Declara¸c˜ao de Parˆametros sobe a forma de tabela

Distˆancia entre cidades em Kil´ometros - D(i, j) Vila Real Bragan¸ca Amarante 42,7 158 Porto 99,3 215 Lisboa 385 491

• VARIABLES - S˜ao identificadas por esta classe as vari´aveis, sendo apresentado

o nome e restri¸c˜oes associadas a estas, nomeadamente se s˜ao positivas, negativas, inteiras, etc.

(53)

• EQUATIONS - Como o nome indica s˜ao apresentadas por esta classe as

equa¸cões das fun¸cões restri¸cão e da fun¸cão objetivo, sendo primeiro declarado o nome destas e de seguida as expressões das mesmas. Para identificar o tipo de restri¸cão ´e utilizado a letra E no caso de igualdade, L no caso de uma restri¸c˜ao do tipo inferior ou igual e G no caso de uma restri¸c˜ao superior ou igual.

• MODELS - Esta ´ultima classe indica quais das equa¸c˜oes acima declaradas

fazem parte do problema, desta forma ´e poss´ıvel formular modelos diferentes utilzando o mesmo ficheiro de entrada GAMS.

SPARSE SDPA

Utilizado para problemas de otimiza¸c˜ao escritos na seguinte forma padr˜ao (3.1):

min c1× x1 + c2 × x2 + . . . + cm × xm

sujeito a F 1× x1 + F 2 × x2 + . . . + F m × xm − F 0 = X X ≥ 0

(3.1)

Sendo o dual do problema (3.2):

min tr(F 0× Y )

sujeito a tr(F i× Y ) = ci, i = 1, 2, . . . , m Y ≥ 0

(3.2)

Onde todas as matrizes de F0, F1, ..., Fm para al´em de serem consideradas sim´etricas de tamanho n por n, s˜ao matrizes esparsas. As restri¸c˜oes X ≥ 0 e Y ≥ 0 significam que X e Y devem ser positivo.

Existem outras formas normalizadas para esta codifica¸cão utilizadas por vários autores, no entanto podem ser traduzidas para o formato padrão SPARSE SDPA com pouco esfor¸co [3]. O ficheiro codificado divide-se em seis partes, são elas:

(54)

1. Come¸cando pelos comentários, o ficheiro pode conter várias linhas de comentários, linhas estas que devem come¸car com um destes caracteres ”ou *.

2. Depois dos comentários é apresentado o número de matrizes restri¸cão, seguida pela letra m, qualquer texto introduzido ap´os esta letra é ignorado.

3. A segunda linha após os comentários apresenta o número de blocos que dividem a diagonal das matrizes, ou seja, a diagonal da matriz é dividida, formando assim submatrizes, exemplificado na Figura 3.4. A declara¸cão do número de blocos é seguida da express˜ao nblocks. Da mesma forma que na linha anterior, o texto inserido depois da express˜ao nblocks ´e ignorado.

Figura 3.4 – Divis˜ao da Matriz (Fonte: [3])

4. Após ser indicado o número de blocos criados é apresentado um vetor que representa a dimensão de cada bloco. Se este vetor apresentar valores negativos significa que o bloco é uma submatriz diagonal, ou seja, apenas os elementos da diagonal são diferentes de zero.

5. A quarta linha após os comentários contém o vetor dos coeficientes das variáveis que constituem a fun¸cão objetivo.

6. As linhas restantes do ficheiro contêm os valores das matrizes restri¸cão, apresentando um valor por cada linha. Cada linha é constituida pelo ´ındice da matriz, seguido do n´umero do bloco dentro dessa matriz, dos ´ındices i, j que representam o elemento do bloco e por fim o valor da matriz. Como já referido as matrizes são consideradas simétricas, logo apenas os valores do triângulo superior de cada bloco são declarados. É apresentado na Figura 3.5 um exemplo de um problema e a sua codifica¸cão em SPARSE SDPA respetivamente.

(55)

(a) Problema formulado (b) Codifica¸c˜ao em SPARSE SDPA

Figura 3.5 – Exemplo de um problema de otimiza¸c˜ao e a sua codifica¸c˜ao em SPARSE SDPA (Fonte: [3])

MPS

A codifica¸cão MPS segue um formato orientado às colunas, sendo os dados do problema apresentados nas colunas 2, 5, 15, 25, 40 e 50, como é vis´ıvel na Figura

3.6 [4]. Nesta mesma Figura é poss´ıvel ver que os dados são divididos e agrupados em fun¸cão do mesmo tipo.

Ao longo do ficheiro vão sendo apresentados os tipos de dados que se seguem, utilizando cartões de cabe¸calho. São eles:

• NAME – Apresentados a partir da coluna 5, os dados identificados por este

cabe¸calho podem conter qualquer informa¸c˜ao sobre o problema, normalmente o nome.

• ROWS – Identifica as linhas seguintes como sendo dados relativos ao nomes

e tipo das fun¸cões, objetivo ou restri¸cões. Estes dados das restri¸cões são apresentados nas colunas 2 ou 3 para o tipo de restri¸cão e a partir da coluna 5 para o nome da restri¸cão.

(56)

Figura 3.6 – Estrutura das colunas da codifica¸c˜ao MPS (Fonte: [4])

objetivo e fun¸cões restri¸cões, ou seja, as variáveis do problema que definem estas fun¸cões. Cada linha apresenta o nome da variável, que fun¸cões constitui e o seu coeficiente em cada uma delas.

• RHS – Os dados identificados por este cabe¸calho definem o valor das fun¸c˜oes

restri¸c˜ao.

• RANGES (opcional) – Também referente ao valor das fun¸cões restri¸cões aparece

quando essas fun¸c˜oes possuem um valor superior e inferior.

• BOUNDS (opcional) – Representa os dados referentes `as restri¸c˜oes simples,

ou seja, aos limites inferiores e superiores das vari´aveis.

• ENDATA – O cabe¸calho ENDATA representa o fim de todos os dados do

problema.

´

(57)

Figura 3.7 – Problema de otimiza¸c˜ao codificado em MPS (Fonte: [4])

MOSEL

Tal como as outras linguagens de modela¸cão, o formato MOSEL permite codificar e manipular problemas de otimiza¸cão. A sintaxe utilizada nesta codifica¸cão foi projetada de forma a ser fácil de utilizar. É apresentado na Figura 3.8 um exemplo de um problema codificado em MOSEL, problema Burglar2. A estrutura de um ficheiro MOSEL é constituido por cinco partes [18], são elas:

• Model – Representa o in´ıcio do problema, contendo na mesma linha o nome

do problema.

• Directives – Nesta seçcão é poss´ıvel incluir bibliotecas do interpretador e

selecionar op¸cões relativamente à forma como as linhas são interpretadas, mais propriamente a forma como o interpretador identifica o fim de uma expressão, podendo ser pela quebra de linha ou pelo caracter “;“. No caso da identifica¸cão ser feita com a quebra de linha, é poss´ıvel que a expressão continue na linha seguinte, no entanto é necessário colocar um operador antes da quebra de linha. No caso do final da expressão ser definido com o caracter “;“ o interpretador

(58)

assume todas as linhas como sendo da mesma express˜ao at´e ser encontrado o caracter.

• Parameters – São declarados nesta seçcão os parâmetros do problema, apresentando

o seu nome e valor.

• Body – Esta seçcão do ficheiro apresenta todas as equa¸cões do problema,

nomeadamente da fun¸cão objetivo e fun¸cões restri¸cão.

• End-model – Representa o fim do problema, o ficheiro pode conter linhas de

código depois desta declara¸cão, no entanto serão todas interpretadas como comentários.

(59)

Esta codifica¸c˜ao permite ainda incluir ficheiros, isto ´e, na parte body acima referido, ´

e poss´ıvel utilizar dados existentes noutros ficheiros, sendo apenas necessário indicar o nome do ficheiro que se pretende incluir. Esta inclusão de ficheiro apenas é poss´ıvel na parte body do ficheiro, logo apenas pode conter dados relativos `as equa¸cões do problema, nomeadamente da fun¸cão objetivo e fun¸cões restri¸cão;

TSP

A codifica¸cão de problemas utilizando TSP divide o ficheiro, onde estes estão contidos, em duas partes. A primeira parte, denominada parte de especifica¸cão, diz respeito `

a formata¸cão utilizada no ficheiro, a segunda parte contém os dados do problema [19]. A parte de especifica¸cão contém os seguintes parâmetros:

• Name – Identifica o nome do problema.

• Type – Identifica o tipo de dados do problema, que podem ser:

– TSP – Representa dados de um problema do caixeiro viajante, sendo

estes sim´etricos.

– ATSP – Representa tal com o TSP, dados de um problema do caixeiro

viajante, no entanto com dados assim´etricos.

– SOP – Representa dados de um problema de ordena¸c˜ao sequencial.

– HCP – Representa dados de um problema de caminho hamiltoniano. – CVRP – Representa dados de um problema de roteamento de ve´ıculos

com restri¸c˜oes de capacidade.

– TOUR – Representa dados de um problema de tour. • Comment – Identifica os coment´arios existentes no ficheiros.

• Dimension – Identifica no caso do tipo de dados serem TSP ou ATSP, o n´umero

de nós do problema. No caso do tipo de dados serem CVRP, identifica o número total de nós e depósitos. Se os dados do problema foram do tipo TOUR, identifica a dimensão do problema correspondente.

(60)

• Capacity – Identifica a capacidade dos ve´ıculos no caso dos dados serem do

tipo CVRP.

• Edge Weight Type – Especifica como as distâncias dos caminhos são dadas. • Edge Weight Format – Especifica o formato das distâncias dos caminhos. • Edge Data Format – Especifica o formato dos dados dos caminhos.

• Node Coord Type – Especifica o tipo coordenadas associados a cada n´o do

problema utilizadas para apresenta¸cão gráfica ou no cálculo das distâncias.

• Display Data Type – Especifica como é feita a apresenta¸cão gráfica dos nós. • EOF – Identifica o fim da parte de especifica¸cão.

A declara¸cão destes parâmetros é feita utilizando os seus nomes, acima apresentados, seguido do valor.

A segunda parte, referente aos dados do problema é dividida em seçcões de dados, sendo que cada uma delas come¸ca com a palavra-chave correspondente. As seçcões existentes para a parte dos dados são as seguintes:

• Node Coord Section – O valor das coordenadas de cada n´o s˜ao apresentadas

nesta sec¸c˜ao.

• Depot Section – Esta seçcão apresenta a lista de poss´ıveis nós de depósito

alternativos.

• Demand Section – A procura associada a cada n´o, no caso de um problema com

dados do tipo CVRP, é dada nesta seçcão, contendo para cada nó o número que identifica o nó, seguido do valor da procura. Para os nós de depósito o valor da procura é 0, no entanto também são apresentados nesta seçcão.

• Edge Data Section – Esta seçcão contém os dados dos caminhos do problema.

Contendo em cada linha, referente a cada caminho, os n´umeros que identificam os n´os que este liga.

(61)

• Fixed Edges Section – Nesta seçcão são listados os caminhos que devem aparecer

na solu¸cão, sendo apresentados os números que identificam os nós que estes ligam.

• Edge Weight Section – Esta seçcão contém o valor das distâncias dos caminhos

do problema.

CPLEX

Desenvolvido no final dos anos oitenta pela CPLEX Optimization Inc., a codififca¸cão CPLEX segue um formato orientado às linhas, cada linha do ficheiro pode conter até 255 caracteres [6]. As linhas em branco são ignoradas e as linhas que contiverem o caracter \ também são ignoradas, visto este caracter identificar a linha como um comentário. O ficheiro CPLEX é codificado seguindo o seguinte formato:

• Defini¸cão da fun¸cão objetivo. • Defini¸cão das fun¸cões restri¸cão. • Defini¸cão das restri¸cões simples. • Defini¸cão das variáveis.

• Indica¸c˜ao de fim do ficheiro.

Todas estas seçcões do ficheiro são identificadas por palavras-chave que identificam o tipo de dados que se segue. Existem várias Palavras-chave para o mesmo tipo de dados, apresentadas no Figura 3.9, onde em cada linha é poss´ıvel ver as Palavras-chave utilizáveis para cada tipo de dados. É apresentado na Figura3.10um exemplo de um problema codificado em CPLEX.

(62)

Figura 3.9 – Palavras-chave utilizadas pela codifica¸c˜ao CPLEX para os tipos de dados (Fonte: [6])

Figura 3.10 – Problema de otimiza¸c˜ao codificado em CPLEX (Fonte: [7])

C, MATLAB BINARY e Fortran

Para problemas codificados em C, MATLAB BINARY e Fortran, a estrutura dos dados depende do interpretador utilizado. No que diz respeito à codifica¸cão todos os dados são declarados utilizando a própria linguagem de programa¸cão. Devido à extensão dos exemplos para estas codifica¸cões, estes foram colocados nos anexos em

(63)

4

Codifica¸c˜

ao AMPL

4.1 Introdu¸

c˜

ao

Alguns problemas encontram-se formulados e escritos em AMPL, esta linguagem, de modela¸cão algébrica e com uma sintaxe semelhante à nota¸cão matemática de problemas de otimiza¸cão, permite descrever e solucionar problemas de alta complexidade em larga escala de computa¸cão matemática [15]. Projetada e implementada por Robert Fourer, David M. Gay e Brian W. Kernighan em 1985, tem apresentado grandes evolu¸cões desde então.

Os problemas estão contidos em ficheiros com extens˜ao .mod e encontram-se separados em 3 partes: inicialmente são declaradas as variáveis e os parâmetros utilizados na formula¸cão do problema; numa segunda parte é apresentada a fun¸cão objetivo e fun¸cões restri¸cão, caso existam, e por fim são apresentados os valores das variáveis e dos parâmetros do problema.

Como é vis´ıvel na Figura 4.1, problema S353 da coleçcão Schittkowski, o problema come¸ca com a declara¸cão dos parâmetros, sendo estes dados identificados pela palavra param. A declara¸c˜ao dos parâmetros pode ser feita de duas formas, apresentando o nome e o seu valor na mesma linha, ou apresentando apenas o nome, sendo o valor

(64)

38 CAPÍTULO 4. CODIFICAÇ ÃO AMPL

Figura 4.1 – Problema S353 codificado em AMPL

declarado numa parte posterior do ficheiro.

De seguida são declaradas as vari´aveis do problema, identificadas pela palavra var e da mesma forma que os parâmetros existem mais que uma forma destas serem declaradas. A forma mais simples apenas contém o nome da variável sendo o valor inicial declarado na última parte do ficheiro, no entanto é poss´ıvel na mesma linha da declara¸cão determinar o seu valor e, se existirem, as restri¸cões simples associadas. A parte final do ficheiro, visto estar associada aos parâmetros e às variáveis, e identificada pela palavra data apresenta os valores iniciais das vari´aveis e o valor dos parâmetros caso não sejam apresentados no momento de declara¸cão, apresentando o nome da variável ou do parâmetro seguido do seu valor.

Depois das vari´aveis, voltando atr´as na estrutura do ficheiro, identificada pela palavra