LIBRERIA DE PROGRAMACION DINAMICA

LIBRERIA DE PROGRAMACION DINAMICA

Trabajo de Tesis presentado al

Departamento de Ingenier´ıa Sistemas y Computaci´on

por

Juan Francisco Redondo Fajardo

Asesor: Rafael Garc´ıa

Para optar al t´ıtulo de

Ingeniero de Sistemas y Computaci´on

Ingenier´ıa de Sistemas y Computaci´on Universidad de Los Andes

LIBRERIA DE PROGRAMACION DINAMICA

Aprobado por:

Rafael Garc´ıa, Asesor

A mi familia, quienes me han brindado todo su apoyo y aquellas personas allegadas que siempre han estado,

Prefacio

La programaci´on din´amica es una de las metodolog´ıas implementadas para solu-cionar una gran variedad de problemas. Esta t´ecnica, si se utiliza en su forma m´as pura, ofrece algoritmos de soluci´on que, dada su naturaleza recursiva, tiene comple-jidad temporal exponencial en la mayor´ıa de los casos.

La metodolog´ıa para encontrar soluciones a este tipo de problemas, propues-ta por Boh´orquez[4], muestra que definiendo estructuras de datos adicionales que almacenen las soluciones, se evita volver a realizar c´aculos correspondientes a sub-problemas, ya que las soluciones pueden ser llevados acumulativamente; tambi´en se evita realizar c´alculos innecesarios, al tratar de calcular una soluci´on a un subproble-ma, ya antes solucionado, literalmente se cambia espacio por tiempo. Cabe nombrar que esta librer´ıa busca ser una herramienta que estandarice el proceso de modelaje de problemas de programaci´on din´amica, as´ı que ingresando datos del problema en las funciones de la librer´ıa, se podr´ıa encontrar una soluci´on en un tiempo polinomial.

Por esto se ve la necesidad y la viabilidad de la implementaci´on de un API, que ubica al usuario en un mundo limitado a la inserci´on de datos que son requeridos y con estos se encontrar´ıa la soluci´on al problema de programaci´on din´amica, esto se hace instanciando a la clase DynamicSolver, para luego darle los datos correspondi-entes al problema, de esta forma, la soluci´on es alcanzada sin que el usuario sepa la implementaci´on de alto nivel que utiliza memorizaci´on y divisi´on en subproblemas. La librer´ıa exige datos basados en un problema bien modelado, para satisfacer todas las funciones del API, que logren una soluci´on ´optima, de no cumplirse se llegar´ıa a soluciones incorrectas o infactibilidades de realizaci´on.

Este proyecto contribuye con un proceso de aprendizaje y especializaci´on, mez-clando ´areas de investigaci´on de operaciones de ingenier´ıa industrial y de dise˜no de algoritmos de ingenier´ıa de sistemas y computaci´on.

El proyecto cuenta con el lanzamiento de un API de JAVA, que cambia la forma de hallar la soluci´on a cualquier problema de programaci´on din´amica, ya que apoyados a este, simplemente se plantea, modela e ingresa los datos del problema que esta limitados por los par´ametros de los m´etodos de la librer´ıa.

Para tener una lectura amena de esta tesis, a continuaci´on se explicar´a los temas que contiene cada cap´ıtulo de este documento.

Inicialmente en el prefacio, se encuentra una introducci´on sobre este desarrollo, un breve ¿qu´e?, ¿para qu´e?, ¿por qu´e?, y ¿c´omo leer la tesis?; luego en el cap´ıtulo uno, est´a una introducci´on te´orica acerca de la programaci´on din´amica, que prob-lemas soluciona, la existencia de metodolog´ıas para atacar estos probprob-lemas, adem´as de varias generalidades sobre conceptos b´asicos, es decir, un diccionario simple, que para lectores con pocos conocimientos del tema, clarifica ideas b´asicas; un cap´ıtulo importante es el n´umero dos, donde el modelo y metodolog´ıa implementados se ven expl´ıcitos, adem´as muestra la estructura base para la realizaci´on del proyecto, es decir, todo el ciclo de dise˜no del API; en el cap´ıtulo tres se hace un paralelo entre la metodolog´ıa mencionada en 1.5 y el ¿c´omo se implement´o el proyecto?, explicando las estructuras de datos y la funciones que este posee, acorde con la metodolog´ıa utilizada; y por ´ultimo, en el cuarto cap´ıtulo se encuentran las conclusiones y de-sarrollos futuros de la tesis, para que esta librer´ıa abarque aun m´as problemas de programaci´on din´amica. Para finalizar la inducci´on a la lectura de este documento, se anexa un manual que explica c´omo el problema del morral es solucionado in-gresando los datos que la librer´ıa exige, este problema es uno de los ejemplos m´as famosos de la programaci´on din´amica. En los anexos existe una investigaci´on y con-clusiones sobre que variables se necesita tener para poder desarrollar un problema de programaci´on din´amica, donde la conclusi´on fu´e una validaci´on al modelo usado en la t´esis. Adicional al documento, se encuentra un disco compacto que contiene la librer´ıa y los javadoc que muestran la documentaci´on interna del proyecto.

Reconocimientos

A Rafael Garcia, por su colaboraci´on, paciencia y ´animo, en el desarrollo de este API.

Tabla de Contenido

Dedicatoria III

Prefacio IV

Reconocimientos VI

I. Introducci´on a la programaci´on din´amica 1

1.1. Definici´on . . . 1

1.2. Enfoques de la programaci´on din´amica . . . 2

1.3. ¿Qu´e se puede solucionar con esta metodolog´ıa? . . . 3

1.4. Marco te´orico . . . 4

1.5. Metodolog´ıa aplicada de programaci´on din´amica . . . 5

II. Modelaje y dise˜no del problema 7 2.1. Elementos b´asicos de los problemas de programaci´on din´amica . . . 7

2.2. Planteamiento . . . 9

2.3. El problema del morral . . . 10

2.4. Planteamiento del morral bajo la metodolog´ıa . . . 11

2.5. Dise˜no de la implementaci´on . . . 17

2.6. Requerimientos funcionales . . . 17

2.7. Requerimientos no funcionales . . . 19

2.8. Casos de uso . . . 20

2.8.1. Usuario con pocos conocimientos en modelar un problema de programaci´on din´amica . . . 20

2.8.2. Usuario con altos conocimientos en modelar un problema de programaci´on din´amica . . . 20

2.9. Diagrama de Clases . . . 20

III. Desarrollo de la librer´ıa 22 3.1. Generalidades del Desarrollo . . . 22

3.2. Componentes del Problema . . . 23

3.3. Estructura de datos . . . 23

3.3.1. Los estados . . . 23

3.3.2. Pregunta y etapas . . . 23

3.4. API para problemas de programaci´on din´amica . . . 24

3.4.1. Conjunto de estados . . . 24

3.4.2. Pregunta . . . 24

3.4.3. Condiciones inductivas . . . 24

3.4.4. Operador de la funci´on Objetivo . . . 25

3.4.5. Funci´on aplicada a estados sucesores . . . 25

3.4.6. Funci´on de valor en el caso base . . . 26

3.4.7. Funci´on de valor en el caso inductivo . . . 26

3.4.8. Memorizaci´on . . . 26

3.4.9. Librer´ıa JEP . . . 27

IV. Conclusiones y futuros desarrollos 28 4.1. Conclusiones . . . 28

4.2. Futuros avances . . . 29 Ap´endice A. — Manual Operativo sobre el problema del morral 30

Ap´endice B. — Investigaci´on previa 34

Cap´ıtulo I

Introducci´

on a la programaci´

on din´

amica

1.1.

Definici´

on

Programaci´on din´amica es un m´etodo utilizado para reducir la complejidad o tiempo de ejecuci´on de los algoritmos, esto mediante la utilizaci´on de problemas superpuestos y subestructuras adicionales. el matem´atico Richard Bellman fue la primera persona en plantear la ecuaci´on base para la programaci´on din´amica, ver Bellman[2].

Aunque el t´ermino contiene la palabra programaci´on, dista mucho de lo que en realidad implica1 _{y esto es resolver problemas donde se calcula la mejor soluci´on}

consecutivamente.

Pero, ¿qu´e es una subestructura adicional? El t´ermino indica que soluciones ´optimas de subproblemas, pueden ser usadas para encontrar soluciones ´optimas del problema total. Por definici´on se puede resolver problemas con subestructuras adi-cionales mediante los siguientes pasos:

1. Dividiendo el problema en subproblemas mas peque˜nos

2. Encontrando la soluci´on ´optima de estos subproblemas usando este mismo

proceso de tres pasos2 _{, de forma recursiva.}

3. Construir la soluci´on ´optima del problema con las soluciones de los subprob-lemas.

1_{Esta palabra no hace referencia a programaci´on como tal, pero si a programaci´on matem´atica.} 2_{Al proceso de tres pasos se conoce como dividir y vencer o dividir y conquistar.}

Los subproblemas se resuelven a su vez, con subproblemas que surgen de estos mismos, as´ı se van haciendo m´as sencillos de solucionar hasta llegar al caso base, donde la soluci´on es trivial Cormen[6].

Se debe notar que una mala implementaci´on de programaci´on din´amica puede incurrir en desperdicios de tiempo. Pues podr´ıa volver a calcular soluciones a sub-problemas que ya se saben de antemano. Para solucionar este detalle, y bajar la complejidad de un algoritmo de programaci´on din´amica, guardando las soluciones que ya se han calculado. Esta metodolog´ıa se conoce como memorizaci´on.

A lo largo del documento se hablar´a del problema del morral, con el fin de hallar similitudes entre la teor´ıa y la pr´actica, haciendo m´as f´acil la lectura y el entendimiento de este documento. En breve, este problema, sugiere un morral que cuenta con cierta capacidad, adem´as se cuentan con objetos que se pueden meter dentro del morral, cada uno con un costo de capacidad y un valor o beneficio al cargarlo en el morral. Se pretende encontrar la combinaci´on de objetos que max-imicen la utilidad generada en conjunto entre los objetos incluidos en el morral, simplemente teniendo bajo restricci´on que estos objetos quepan.

1.2.

Enfoques de la programaci´

on din´

amica

De arriba a abajo

El problema se empieza a dividir en subproblemas, se solucionan los que no han sido resueltos, a medida que se divide en subproblemas y se recuerdan los que han sido resueltos, combinando inducci´on y memorizaci´on3 _.

De abajo a arriba

Primero se solucionan absolutamente todos los problemas que se requieran para la implementaci´on de antemano y luego, ya teniendo sus soluciones, estas son uti-lizadas para resolver a los problemas mayores. Es poco intuitivo, pero ahorra espacio y llamados a funciones.

3_{Nota: Este fue el m´etodo utilizado para la implementaci´on de la librer´ıa, ya que es el m´as} intuitivo.

1.3.

¿Qu´

e se puede solucionar con esta metodolog´ıa?

Algunos de los problemas que se pueden resolver son los siguientes:

1. Problema de c´aculo de sucesi´on Fibonacci: La forma para ser calculado es netamente inductiva, el valor de este c´alculo, es la suma de los dos ´ultimos resultados teniendo como caso base, la funci´on evaluada en cero o en uno, que genera como resultado uno.

2. Problema de inventario: Es considerado un problema de ordenar una canti-dad de cierto tipo de items para cada N periodos, hasta encontrar los montos necesarios para suplir la demanda, ya obtenida de manera estoc´astica o de-terminista, ver Bertsekas[3]. Este problema contiene, ci, que es el inventario

disponible en el periodo i-´esimo, cpi un inventario pedido en el comienzo de

cada i-´esimo periodo y un di que es la demanda durante el i-´esimo periodo,

dada por la distribuci´on de probabilidad. Entonces ci+1 = ci + cpi + di, de

aqu´ı surgen: Un costo de oportunidad o(ci), que es una penalidad por tener

exceso, el costo de hacer el pedido por unidad C(cpi) y M(cN) el costo de

mantener un inventario al final de los N periodos entonces el costo total, esta descrito.

E{M(cN) +

P_{N −1}

i=0 C(cpi) + o(ci)}

La soluci´on encontrar el conjunto de objetos que en la etapa N, minimice mi costo.

3. Ruta m´as corta: Se conoce como al problema de encontrar la mejor ruta entre un v´ertice y los dem´as v´ertices de un grafo conecto ver Ahuja[1]. La forma de resolver este ejemplo es segmentado, si se encuentran las rutas m´as cortas entre los puntos, y se va analizando que ocurre si se ingresa m´as puntos, luego de desarrollar todos los posibles caminos a los puntos, con ayuda de las soluciones parciales se puede generar una soluci´on definitiva.

Los anteriores son algunos de los problemas que puede solucionar esta metodolog´ıa. Algunos cuentan con carater´ısticas similares y pueden estar contenidos dentro de otros, ya mencionados. Este documento se apoya, en el problema del morral que es uno de estos problemas de programaci´on din´amica. Un problema en donde la t´ecnica de programaci´on dividir y vencer, funciona. En general, cualquier problema que su soluci´on pueda ser hallada partiendo el problema en subproblemas y que las soluciones de los subproblemas sirvan para hallar la soluci´on del problema global,si el problema no llega a desbordar la capacidad de la memoria, esta metodolog´ıa en teor´ıa lograr´ıa resolverlo.

1.4.

Marco te´

orico

Estado Componente de una red o grafo, es un punto, nodo o v´ertice, el cual diferencia una posible situaci´on, y est´a definido por un nombre y una funci´on de valor. El conjunto de estados de G se denota como V(G), y donde el orden de un grafo es el numero de estas | V (G) |. En el caso del morral, los estados constituyen a los objetos que pueden estar dentro del morral.

Acci´on Es una decisi´on posible que se puede tomar en cada estado. Asocian a un estado con otro estado, tambi´en conocidos como arcos o transiciones. El conjunto de arcos de G se denota E(G) y donde el tama˜no de un grafo es el numero de arcos.

| E(G) |. El grado de un nodo es la cantidad de arcos que salen de este. En el ejemplo

del morral los estados se conectan con los otros estados, de acuerdo a la funci´on de sucesores que el usuario implemente.

Red Es un conjunto de estados, relacionados entre si por acciones y se denota como G := (V,E), esto en el caso de no ser dirigido. En el caso de ser dirigido, E, es cambiado por un conjunto de parejas ordenadas, que indican el estado inicial y cual estado destino.

´ Arbol

Es un grafo simple conectado y ac´ıclico. Se le conoce como hojas a los nodos con grado 1. En este caso cada nodo, corresponde a un estado, los estados que provienen del mismo nodo hermanos, se encuentran en la misma etapa, es decir, que cada piso que tenga el ´arbol corresponde a otra etapa, en el caso del morral, los estados que

se encuentran en la misma etapa, son objetos que caben dentro del morral sabiendo que ya hay o no, otros dentro.

Programaci´on din´amica

La programaci´on din´amica es una t´ecnica de soluci´on de problemas, pero cuya implementaci´on directa es ineficiente, por eso, se plantea la definici´on de estructuras de datos que almacenen c´alculos, para evitar c´alculos repetidos e innecesarios. Lit-eralmente cambiando espacio por tiempo. Si el algoritmo que se mejora es iterativo, se acelerar´ıa manejando una invariante, minimizando el uso de mucho m´as c´alculos en la implementaci´on del programa.

1.5.

Metodolog´ıa aplicada de programaci´

on din´

amica

Como funciona esto:

1. Se define un lenguaje para establecer formalmente el problema. Se incluye notaci´on para la funci´on f, cuyo c´aculo es un valor especifico x0, corresponda

a la soluci´on del problema

2. Se establece una recurrencia que defina la funci´on f en un dominio que incluya a x0.

3. Se estudia la recurrencia, determinando un diagrama de necesidades, para cada elemento x del dominio de f, establecer para que elementos se deber´a conocer el valor de f para poder calcular f(x)

4. El diagrama de necesidades sugiere un invariante para un ciclo que calcule todos los valores previos necesarios para evaluar f(x0). Adem´as de un orden

de evaluaci´on para los elementos del dominio de f.

De esta forma se puede disminuir la complejidad temporal considerablemente, apoyando el tan conocido, dividir y conquistar. Por otra parte, ya que hay c´alculos almacenados en la estructura de datos, y existe un orden de evaluaci´on, se puede apoyar en los c´alculos ya realizados y obtener los nuevos valores, de igual forma tambi´en guardar los datos ya obtenidos para que no sean vueltos a calcular.

Al crear una librer´ıa para resolver problemas de programaci´on din´amica, se debe recurrir a la generalizaci´on de los problemas din´amicos, separando por niveles, los datos y librer´ıa; con esta separaci´on se trataron varios problemas para analizar, cuales son los datos necesarios para desarrollar problemas de esta ´ındole.

Para entender un poco m´as esta t´ecnica de soluci´on se debe ver el planteamiento del problema del morral bajo la misma metodolog´ıa, ver 2.4.

Cap´ıtulo II

Modelaje y dise˜

no del problema

2.1.

Elementos b´

asicos de los problemas de programaci´

on

din´

amica

1. El problema puede dividirse en etapas, con una decisi´on de la pol´ıtica requerida en cada etapa. En el caso del morral se divide en varias etapas que est´an asociadas a la capacidad restante. Es decir, si tengo una capacidad N y un costo por objeto i ci, la siguiente etapa esta definida, (N −ci) y la decisi´on es, en este

caso, la elegir que objeto maximiza el beneficio para esa etapa. Adem´as existe problemas de programaci´on din´amica que requieren an´alogamente de tomar sucesi´on de decisiones interrelacionadas y en otros, la toma de decisiones no se encuentra relacionada.

2. Cada etapa tiene un n´umero de estados asociados a esta. Los estados asociados con cada etapa en el problema del morral, son los objetos que se quieren meter al morral, los cuales tienen adem´as un valor vi, si ese costo ci cabe dentro del

costo libre para esa etapa, el objeto o estado esta asociado a esa etapa t. En general, los estados son las diversas condiciones posibles en las que el sistema podr´ıa estar en esa etapa del problema, estos pueden ser finitos o infinitos.

3. El efecto de la decisi´on de una pol´ıtica en cada etapa es; transformar el estado actual en un estado asociado con la etapa siguiente. En el ejemplo del morral, se tiene una capacidad y esta es disminuida con el costo de ingresar un objeto en el morral, se soluciona ese subproblema y queda una capacidad restante, que es el nuevo espacio disponible en el morral para ingresar objetos i, y sobre

esta se vuelve a realizar el mismo proceso, hasta llegar al caso trivial, que para este seria que no quepa m´as objetos i, en el morral. Con los valores obtenidos por cada etapa se empieza a armar una contribuci´on a la funci´on objetivo en este caso, metiendo en el morral la combinaci´on de objetos que maximicen el valor del conjunto de objetos.

4. Dado el estado actual, una pol´ıtica ´optima para las etapas restantes. En el ejemplo del morral, Dado un objeto i que se desea evaluar para ingresar dentro del morral, desde ese punto en adelante es independiente de como lleg´o all´ı. Para los problemas de programaci´on din´amica en general, el conocimiento del estado actual del sistema comunica toda la informaci´on de su comportamiento previo, necesaria para determinar la pol´ıtica ´optima de all´ı en adelante. Esta propiedad se conoce como el principio de optimalidad.

5. El procedimiento de soluci´on empieza por hallar la pol´ıtca ´optima para cada estado de la ´ultima etapa. Com´unmente, la soluci´on de este problema para la ´ultima etapa es trivial. En el caso del morral, se llega al caso trivial cuando de esa etapa no se pueden generar m´as etapas, y eso ocurre cuando no existe capacidad restante para insertar cualquier otro objeto.

6. Se dispone de una relaci´on recursiva que identifica la pol´ıtica ´optima para cada estado en la etapa n, dada la pol´ıtica ´optima para cada estado en la etapa (n+1)

f∗

n(s) = m´axxn(vs|xn + fn−1∗ (xn))

Por lo tanto, hallar la pol´ıtica ´optima cuando se parte del estado s, quiere que se encuentre el valor que maximice xn. Esta pol´ıtica consiste en usar este

valor de xn, seguir la pol´ıtica ´optima cuando se parte del estado xn en la etapa

(n-1). La forma precisa de la relaci´on recursiva difiere algo entre los problemas de programaci´on din ´mica. As´ı sea, variable o vector xn, la variable de decisi´on

en la etapa n. Sea fn(s, xn), el valor que m´aximiza la funci´on objetivo. dado

para el problema del morral, fn(s, xn) = vs|xn+ fn−1∗ (xn), siendo fn∗(s) el valor

m´aximo de fn(s, xn) sobre todos los valores posibles de xn; entonces la relaci´on

recursiva siempre sera de la forma: f∗

n(s) = m´ax fn(s, xn), en donde se escribir´ıa

fn(s, xn), en t´erminos de s, xn, fn∗ y de alguna medida de la primera etapa de

la efectividad o no efectividad de xn

7. Usando esta relaci´on recursiva, el procedimiento de soluci´on se mueve hacia atr´as, etapa por etapa, hallando la pol´ıtica ´optima, para cada estado de esa etapa, hasta que se encuentra la pol´ıtica ´optima cuando se parte de la etapa inicial,

Eso se demostr´o en el problema del morral, en el que se encontr´o la pol´ıtica ´optima, para todos los estados y para todas las etapas. Para hacer an´alisis, todos los problemas de programaci´on din´amica, se puede tener una tabla que contiene s, f∗

n(s) y xn, cuando se obtiene esta tabla para la etapa inicial, se

resuelve el problema. Ya que se conocer´ıa el estado inicial, la decisi´on inicial especificada por x∗

1. Entonces, a su vez se especifica el valor ´optimo de las

otras variables de decisi´on mediante otras tablas, de acuerdo con el estado del sistema que resulta de la decisiones precedentes. ver Hillier[5].

2.2.

Planteamiento

Para la metodolog´ıa usada en este proyecto, un problema de programaci´on din´amica requiere de:

1. Una funci´on objetivo f que tiene un operador, el cual busca encontrar la solu-ci´on ´optima para ese problema, el resultado de esa funsolu-ci´on es generado induc-tivamente, y a ese se nombra valor inductivo. En el caso del morral se busca maximizar el beneficio llenando el morral con la mayor cantidad de objetos que generen m´as valor conjunto, ver 2.3.

2. Una pregunta P, que en realidad es la evaluaci´on de una funci´on asociada a la funci´on objetivo, a la pol´ıtica alcanzada, en alg´un estado o valor entero. Sobre el cual se desea concluir. En el caso del morral la pregunta es cual es el

conjunto de objetos que maximizan la funci´on objetivo dado que se dispone de una capacidad C.

3. Los datos del problema:

Estados Estos son los estados se pueden describir como el conjunto de op-ciones con los cuales cuenta el problema en cada etapa, a los estados que no tienen predecesores se les conoce como estados iniciales, y de estos sur-gen todos los estados de la siguientes etapas, y los estados que no tienen sucesores se conocen como estados finales.

Caso Base Cuando el problema se descompone en subproblemas, as´ı sucesi-vamente has que se intenta resolver el caso trivial, luego de este, no hay m´as etapas posibles, por eso, este arroja una soluci´on.

Caso Inductivo El problema se divide en subproblemas ayudado por la condi-ci´on que genera los estados sucesores, para que luego el caso base o nue-vamente los casos inductivos retornen valores ya acumulados, que hacen parte de la pol´ıtica ´optima. y el beneficio va a ser parte de la funci´on objetivo.

Funci´on suc:, encontrar sucesores Esta funci´on notada como h, se en-cuentra asociada a cada caso inductivo, ya que los estados sucesores son manipulados para generar nuevos sucesores’, cada sucesores se encuen-tran en otra etapa diferente a la etapa de sus predecesores. Y entre estos compiten para maximizar la funci´on objetivo.

Funci´on h, para el caso base Esta funcio´n en el caso base, genera el com-portamiento de la funci´on de valor en el caso base o caso trivial.

Funci´on h, para el caso inductivo Esta funci´on indica el comportamiento de la funci´on de valor mientras se va desarrollando la inducci´on.

2.3.

El problema del morral

El problema del morral es uno de estos problemas de programaci´on din´amica, donde unos objetos i ∀1≤i≤n, que se desean ingresar dentro del morral con capacidad

P , estos objetos i tienen un costo de capacidad pi, una cantidad de objetos oi y

un valor o beneficio ui, se busca llenar el morral con la cantidad objetos ´optima, es

decir,

n

X

i=0

pioi ≤ C

cuantos objetos caben en el morral y

m´ax f(oi, ui)

, la funci´on objetivo f, depende de conjunto de elementos que se encuentran en el morral y el valor que estos en conjunto generan; en otras palabras, encontrar la combinaci´on de objetos que maximicen el beneficio dado por la funci´on objetivo.

Donde la pregunta para este caso seria maximizar la funci´on objetivo, para una capacidad P ya dada.

2.4.

Planteamiento del morral bajo la metodolog´ıa

En esta secci´on, se muestra el problema del morral, utilizando la t´ecnica de solu-ci´on de problemas de programasolu-ci´on din´amica dividir y vencer, tomado de Boh´orquez[4].

El problema del morral es un problema cl´asico de la investigaci´on de operaciones. Una soluci´on recurrente ingenua puede resultar demasiado onerosa. La soluci´on que se presenta, utilizando programaci´on din´amica, es eficiente y pr´actica1 _.

El problema:

Dados

n objetos, o1, ..., on

Para i = 1, ..., n, pi es el peso de oi. Naturalmente, pi > 0

Un morral, que soporta un peso m´aximo P .

1_{A pesar de ser un problema NP-completo, la soluci´on que se presenta es eficiente en la praxis,} si se concede que los n´umeros involucrados no sean arbitrariamente grandes

Para i = 1, ..., n, si se carga en el morral el objeto oi , se obtiene un beneficio

o utilidad ui.

Se quiere maximizar la utilidad de cargar en el morral algunos objetos.

El lenguaje

ut(j,x) : Utilidad m´axima que se consigue, si los objetos que se pueden cargar se eligen entre o1,...,oj, si el peso m´aximo que se puede soportar es x.

ut(n,P) : Respuesta deseada.

La recurrencia

ut(j,x)= 0 , si j=0

= ut(j-1,x), si 1 ≤ j ≤ n, 0 ≤ x< pj

= m´ax{ut(j-1,x), ut(j-1,x-pj ) + uj}, si 1 ≤ j ≤ n, 0 < x≤ pj

El diagrama de necesidades

Figura 1: Diagrama de necesidades

As´ı:

T (n, P ) = O(nP ) S(n, P ) = nP

Mejoras: El algoritmo puede mejorarse, si se observa con mas cuidado el diagrama de necesidades: basta guardar ´unicamente las dos ´ultimas columnas calculadas:

T (n, P ) = O(nP ) S(n, P ) = 2P

El ahorro en espacio es significativo. La situaci´on puede, incluso, mejorar hasta lograr que se deba almacenar solo una columna, si se piensa que se puede mantener un invariante que afirme:

El nuevo algoritmo puede escribirse de la siguiente forma:

Hasta aqu´ı, se ha solucionado el problema de conocer cu´al ser´ıa la utilidad m´axi-ma posible. En la pr´actica se quiere averiguar, adem´as, en que form´axi-ma se puede alcanzar este ´optimo.

Ahora, ¿c´omo saber que objetos se llevan?

La t´ecnica se extiende para considerar una funci´on adicional que permita recordar las decisiones que se tomaron en el c´alculo del ´optimo. Los valores de esta funci´on deben almacenarse para construir la respuesta a la nueva pregunta.

sel(j,x) : 1 si oj se lleva, cuando el peso m´aximo permitido es x,

: 0 si oj no se lleva, cuando el peso m´aximo permitido es x.

N´otese que:

sel(j,x) = 1 ⇔ 0 < j ≤ P ∧ x ≥ pj cand ut(j-1,x-pj)+uj

Con esta definici´on, el algoritmo puede modificarse para calcular sel:

Se debe observar que la estructura del algoritmo que calcula el ´optimo se respeta y se utiliza como plataforma sobre la que se puede, adicionalmente, escribir c´odigo que permita recordar las decisiones tomadas.

Finalmente, para determinar que objetos se pueden llevar para conseguir la util-idad m´axima, def´ınase, para 1 ≤ i ≤ n :

x[i]= 1 ⇔ oi se lleva, para alcanzar el ´optimo.

El siguiente algoritmo, que calcula en el arreglo X[1..n] el vector x[1..n]:

2.5.

Dise˜

no de la implementaci´

on

A continuaci´on se encuentra el ciclo de dise˜no de la aplicaci´on y se encuentra dividido en: Levantamiento de requerimientos, el cual consta de las cosas que esta aplicaci´on debe hacer y se encuentra segmentado en requerimientos funcionales, propios de la aplicaci´on para que esta cumpla con su objetivo y requerimientos no funcionales, que son parte de la calidad del programa; luego los posibles casos de uso, explicado para cada usuario que pueda usar la librer´ıa; por ´ultimo un diagrama de clases, el cual contiene el conjunto de estructuras de datos, separadas por objetos, con sus respectivos atributos o variables y sus m´etodos, que son aquellas funciones que sirven para interactuar entre objetos.

2.6.

Requerimientos funcionales

1. Hallar el escenario ´optimo, o conjunto de escenarios ´optimos por etapa, de un problema bien modelado.

2. Tendr´a la capacidad de amoldarse ante cualquier tipo de problema de progra-maci´on din´amica con que el usuario se encuentre. Y encontrar una soluci´on ´optima, factible, etc., todo esto, dependiendo de la forma como se plantee el problema.

3. Desarrolla un esquema de estados alcanzables a partir de las condiciones in-ductivas presentadas.

4. Con javadoc y un manual de soporte para el API, se facilitara el entendimiento de este.

5. Los resultados ser´an expl´ıcitos con el valor final de la f.o, tambi´en llamado f(x0) decisi´on asociada a cada mejor estado en cada etapa.

6. El API tendr´a m´etodos para resolver tanto problemas determ´ınisticos, esto esta sujeto a la metodolog´ıa del desarrollo.

7. El usuario, debe indicar claramente la funci´on objetivo de la cual deriva su caso base y su caso inductivo, como avance al desarrollo y facilitar, el recorrido entre estados y etapas, el usuario en el planteamiento del problema podr´a agregar un caso transitivo, que evite recorrer m´as estados y acelere el encontrar el caso base.

8. El usuario podr´a agregar condiciones

9. El usuario de acuerdo a su metodolog´ıa podr´a encontrarse con un resultado ´optimo hallado de forma eficiente, un resultado ´optimo encontrado de una forma no eficiente, o no alcanzar el caso base, por mal planteamiento del problema. Casos de ciclaje o infactibilidad.

10. La separaci´on de tres niveles: datos, problema y programa; existe por lo sigu-iente

b) De acuerdo a la mezcla entre par´ametros requeridos y opcionales, se puede

atacar de diferentes formas un problema din´amico, ya que en el fondo, todos los problemas din´amicos concuerdan en varios detalles.

c) De acuerdo a investigaciones soportadas por Bellman, el principio de

pro-gramaci´on din´amica es el mismo, y se encuentra basado en una ecuaci´on sencilla, que fue la base de este desarrollo.

11. El problema no requiere definici´on de etapas, ya que gen´ericamente es atem-poral, pero manejando responsablemente y con un buen modelaje los estados pueden aparecer modificando las condiciones. El control de recorrido y de eta-pas queda a cargo del API.

12. El usuario se hace responsable del buen modelaje del problema para una buena inserci´on de los datos del problema din´amico al API.

2.7.

Requerimientos no funcionales

1. La librer´ıa implementa la t´ecnica de programaci´on antes mencionada como

dividir y vencer, adem´as de estructuras de datos que memoricen c´alculos, para

que esta sea eficiente, aumentando la respuesta en tiempo.

2. La librer´ıa tiene muy bien definida en sus estructuras, el problema y los ele-mentos de este.

3. La librer´ıa debe estar bien documentada.

4. Se debe tener un manual que sirva para ilustrar como insertar datos de un ejemplo para encontrar una soluci´on a un problema de programaci´on din´amica.

2.8.

Casos de uso

2.8.1. Usuario con pocos conocimientos en modelar un problema de programaci´on din´amica

1. Insertar datos requeridos, el usuario puede insertar estos datos bas´andose en un ejemplo ya realizado y apoy´andose en un manual.

2. Este usuario encontrara soluciones al problema, al cual sencillamente modif-ic´o los datos que recib´ıa el API.

2.8.2. Usuario con altos conocimientos en modelar un problema de programaci´on din´amica

1. El usuario experto puede utilizar la librer´ıa como una librer´ıa para cualquier aplicaci´on, no solo botando resultados sino, siendo parte de un desarrollo para toma de decisiones.

2. De acuerdo a los datos requeridos y opcionales, el usuario podr´a modificar la inserci´on y mezclar entre estos, definiendo bien un problema

3. Agregar nuevos ejemplos con el lenguaje. Para usuarios inexpertos.

4. Insertar datos requeridos, el usuario puede insertar estos datos bas´andose en un ejemplo ya realizado y apoy´andose en un manual.

5. Mediante un comando el usuario puede genere una soluci´on ´optima factible, de acuerdo a la metodolog´ıa utilizada en el programa.

6. Los resultados deben ser presentados en la consola de JAVA

Figura 2: Diagrama de clases 21

Cap´ıtulo III

Desarrollo de la librer´ıa

3.1.

Generalidades del Desarrollo

Con los concepto tomados en el modelaje del problema, se puede hacer un parale-lo con este capituparale-lo, aqu´ı se convierte el modeparale-lo de la soluci´on en estructuras de datos y funciones que van acordes a la metodolog´ıa.

Este proyecto de grado consta del desarrollo de un API (Application Program-ming Interface - Interfaz de Programaci´on de Aplicaciones; un conjunto de especifica-ciones de comunicaci´on entre componentes software) de programaci´on din´amica para

JAVA , basados en la metodolog´ıa vista en el cap´ıtulo dos. El API tendr´a funciones

que permitan crear y recorrer el conjunto posible de estados, para ser evaluados y en-contrar soluciones ´optimas a los problemas planteados. Los m´etodos son f´acilmente entendibles, concisos para que el usuario ingrese los datos, paso a paso, sin mayores traumas.

El punto cr´ıtico de este trabajo por parte del usuario, es en un buen modelaje de los problemas de programaci´on din´amica, para que al usuario final tenga una transparencia al llamar los m´etodos del API. Un mal modelaje del problema incur-rir´a en una mala inserci´on de datos o resultados incoherentes, llegado a una soluci´on err´onea o simplemente inexistente. Un problema bien planteado podr´ıa tener solu-ci´on, dependiendo de los estados y etapas que debe inspeccionar, ya que cada estado en cierta etapa puede generar m´as subproblemas y si el problema esta bien mode-lado pero no esta acotado igualmente no tiene soluci´on por este m´etodo, al final, el ahorro es en tiempo.

3.2.

Componentes del Problema

Se analiza que los estados, deben guardar la informaci´on que es acumulada, para luego que sea comparada entre estos y ver cual es el estado ´optimo y avanzar a la siguiente etapa. Adem´as el usuario puede hacer referencia a lo que le interese.

Un estado contar´a, con un apuntador a lo que el usuario desee. Contar´a con un valor interno si es necesario, que sera asociado por el algoritmo, de acuerdo a como se ingrese la defici´on del problema.

Las restricciones est´an asociadas entre variables que se encuentran en la funci´on objetivo y otras variables que se encuentran en el lenguaje definido por el usuario.

3.3.

Estructura de datos

3.3.1. Los estados

Los estados contienen valores fijos y variables calculados que al estar almacenados y permanecer en una estructura de ´arbol, simplifican dr´asticamente la complejidad del algoritmo.

Costo: Cada estado tiene definido su costo asociado, este costo es de tipo entero, ya que es un problema de programaci´on din´amica y no un algoritmo greedy.

Valor: Cada estado posee, un valor tipo real el cual es tenido en cuenta para calcular la pol´ıtica ´optima y la funci´on objetivo.

Valor Inductivo: Este valor es un control y esta limitado, por la condici´on inductiva del problema, el c´alculo es generado, si el estado donde se encuentra es un posible sucesor.

F´ormula de la funci´on de valor: Este valor es acumulativo y corresponde al valor inmediato que genera el incurrir en ese estado, m´as todos los valores de los estados que se obtuvieron para llegar a esa etapa.

3.3.2. Pregunta y etapas

Para evitar volver a procesar c´alculos ya realizados, se utiliza una estructura de tablas de hash anidadas, con etapas y la pregunta que evaluada para los subproble-ma genera un conjunto de preguntas m´as sencillas de responder, si en la inducci´on

se encuentra con la misma etapa y con la pregunta que ya ha sido evaluada para el subproblema, no es necesario desarrollar los c´alculos para obtener el resultado cor-respondiente ya que fue calculado y memorizado,en la estructura antes mencionada.

3.4.

API para problemas de programaci´

on din´

amica

Esta librer´ıa debe ser invocada, con todos los estados posibles, indicando la condici´on inductiva y haciendo expl´ıcito que hacer con la funci´on objetivo. En el ap´endice, se encuentra un manual operativo basado en el ejemplo del morral, all´ı se hace un paralelo entre esta secci´on y el ejemplo se ha venido trabajando en este documento.

3.4.1. Conjunto de estados

Es el primer par´ametro de la librer´ıa cuando se invoca el m´etodo solve(),

en este caso es un Vector de objetos State, donde se indica la totalidad de estados que la librer´ıa puede alcanzar o en su defecto los estados iniciales, pero indicando en la condici´on inductiva cuales son los posibles sucesores y en la funci´on aplicada a los estados sucesores decir que hacer con estos.

3.4.2. Pregunta

Es el segundo par´ametro del m´etodo solve()

, en este caso es un Vector de objetos Integer, donde se indica la pregunta del problema, para problemas de programaci´on din´amica, esta pregunta es inductiva, y es divisible en subconjuntos, por eso, lo considere como un conjunto de enteros.

3.4.3. Condiciones inductivas Es el tercer par´ametro del m´etodo

en este caso es un Vector de objetos Condition, donde se indica que condici´on se debe cumplir, manipulando los nombre de las variables que se encuentran dentro de los estados, para encontrar los sucesores a cada estado analizado, esta condicci´on por ende, al ser evaluada por el algoritmo que implementa esta metodolog´ıa debe retornar falso o verdadero.

3.4.4. Operador de la funci´on Objetivo Es el cuarto par´ametro del m´etodo

solve(),

en este caso es un String, donde se indica que tipo de operaci´on se va a realizar con los valores resultantes en cada etapa. Es decir, si la funci´on objetivo esta max-imizando, entonces por etapas se debe encontrar el valor que maximice la funci´on, los mismo con la minimizaci´on, sumatoria, etc.

Para este caso se implementa las cadenas de caracteres MAX y MIN.

3.4.5. Funci´on aplicada a estados sucesores

Este par´ametro es ingresado por una funci´on que recibe un vector, por eso, primero creo el vector, luego le agrego la funci´on en una cadena de caracteres medi-ante el m´etodo

next.add(s:String);

y luego agrego el vector a la librer´ıa

s.setNext(next);,

antes de ser llamado el m´etodo

solve(),

en este caso es un Vector, de objetos String, que contiene las mismas variables de estado que manejan las condiciones inductivas, indicando el resultado a seguir de los sucesores. Esta esta directamente asociada a cada caso inductivo, de esta forma

cada vez que se crea una condici´on inductiva, se debe crear una funci´on de este tipo para que sea aplicada a los sucesores. La forma de asociarlos es simplemente agreg´andolos en los vectores en el mismo orden, al final quedaran dos vectores el primero con la condici´on en la posici´on i y su funci´on correspondiente tambi´en en la posici´on i.

3.4.6. Funci´on de valor en el caso base

Este par´ametro es ingresado por una funci´on que pertenece al API setBcVal(s:String),

antes de ser llamado el m´etodo

solve(),

en este caso es un objeto String que contiene las mismas variables de estado que maneja la funci´on aplicada a sucesores indicando con el resultado, que valor retorna la inducc´ıon al encontrarse con el caso base.

3.4.7. Funci´on de valor en el caso inductivo

Este par´ametro es ingresado por una funci´on que pertenece al API setValueFormula(s:String), antes de ser llamado el m´etodo

solve(),

en este caso es un objeto String que contiene las mismas variables de estado que maneja la funci´on aplicada a sucesores, indicando con el resultado, que valor retorna la inducc´ıon al encontrarse con el caso inductivo.

3.4.8. Memorizaci´on

Se implemento en el m´etodo inductiveCalculated() en la clase

InductionClass, el cual guarda la pregunta evaluada bajo cierto valor correspon-diente al subproblema, en cierta etapa. Esto se hace implementado dos niveles de tablas de Hash. Uno para la etapa y otro para la pregunta evaluada bajo las condi-ciones del subproblema.

3.4.9. Librer´ıa JEP

Para la manipulaci´on de condiciones, expresiones y para que el usuario desde un nivel superior las programe literalmente, sin echar codificar en JAVA las funciones, condiciones o datos, se utiliz´o una librer´ıa libre de JAVA, que convierte cadenas de caracteres en expresiones evaluables, existen dos clases que implementan esta librer´ıa JEP1 _{: Una llamada Condition que simplemente retorna falso o verdadero.}

Otra llamada Expression que retorna un valor real. Esta librer´ıa es muy ´util, ya que permite manejar variables, por eso, se le permite al usuario nombrarlas al invocar el API, para que esos nombres queden asociados a las variables de estado, de las cuales se habl´o en la secci´on componentes del problema en el punto correspondiente a estado. Luego de asociarlas el usuario puede en las condiciones evaluarla, y en las funciones que se aplican a los sucesores ocurrido alg´un caso, puede modificarlas. Sin esta librer´ıa, el usuario no estar´ıa separado totalmente del API que encuentra la soluci´on a los problemas de programaci´on din´amica.

1_{JEP es una librer´ıa, que recibe una cadena de caracteres que contenga ecuaciones, expresiones,} condiciones; entre otras cosas que pueden devolver un valor, permitiendo que estas sean evaluadas y arrojando un resultado, para encontrar m´as informaci´on sobre esta librer´ıa, se debe visitar http://www.singularsys.com/jep/doc/javadoc/org/nfunk/jep/JEP.html

Cap´ıtulo IV

Conclusiones y futuros desarrollos

4.1.

Conclusiones

Este implementaci´on es una primera versi´on de un API para encontrar soluciones a ciertos problemas de programaci´on din´amica en tiempo polinomial, es un software libre para la comunidad JAVA, bastante completo en su expresi´on m´as sencilla. Es gen´erico y depende en una gran parte, de la forma como el usuario lo modele. Es-pec´ıficamente en que es problema del usuario respetar que las condiciones inductivas sean excluyentes. Entre otros detalles de especificaci´on.

Se logr´o desarrollar una librer´ıa adaptativa, con inducci´on enfocada de arriba hacia abajo, cumpliendo con todos los par´ametros que un problema de programaci´on din´amica requiere.

Se creo un manual corto, para que el usuario con un ejemplo de problema de programaci´on din´amica, llamado el problema del morral, pueda montar cualquier otro tipo de problema de esta ´ındole, y encontrarle soluci´on de igual forma.

Es una implementaci´on, basada en una metodolog´ıa existente, brindando otro enfoque para encontrar soluciones a problemas de programaci´on din´amica a la co-munidad de programadores en JAVA.

Este desarrollo, puede ser el inicio de un grupo de investigaci´on que trabaje sobre un buen modelaje de problemas de programaci´on din´amica y como volver este API m´as intuitivo para el usuario.

4.2.

Futuros avances

Para este proyecto hay surgido un inter´es en desarrollar un complemento, mucho m´as amigable, con una buena interfaz gr´afica y con un modulo de an´alisis estad´ıstico de los datos. Para el sector asegurador.

Extender este algoritmo a no determinista, asociando probabilidades para incor-porar m´as ejemplos a este como procesos de decisi´on markoviana, ruta m´as corta estoc´astica, etc.

Realizar mezclas entre este algoritmo con otros tipos de programaci´on para que surjan nuevas metodolog´ıas de desarrollo de problemas con incertidumbre, con com-plejidad computacional alta, etc.

Desarrollando m´as ejemplos, haciendo mezclas con otras metodolog´ıas, se puede afianzar el manual del usuario de esta librer´ıa, adem´as de investigar para que en futuras versiones sea m´as intuitivo el proceso de ingresar datos.

Ap´

endice A

Manual Operativo sobre el problema del morral

DynamicSolver s= new DynamicSolver();

2. Crear la pregunta inicializando un objeto Vector, con las capacidades, montos, etc. Sobre los cuales se quiere saber el valor acumulativo del problema. Aqu´ı se hace expl´ıcito un morral con capacidad de 8.

Collection capacities = new Vector(); capacities.add(new Integer(8));

3. Luego se definen los estados, d´andoles un nombre, un costo entero y un valor real. para que luego sean ingresados a un conjunto de objetos llamado States

State s1= new State("Helado Vainilla", 64, 100000); State s2= new State("Helado Chocolate", 32, 45000); State s3= new State("Helado Fresa" , 16, 22000);

State s4= new State("Helado Ron con pasas", 8, 10000); State s5= new State("Helado Arequipe" , 4, 4500); State s6= new State("Helado Capuccino", 2, 2200 ); States sts = new States();

sts.addState(s1); sts.addState(s2); sts.addState(s3); sts.addState(s4); sts.addState(s5); sts.addState(s6);

4. Se indica que operaci´on se va a realizar sobre la funci´on objetivo, este caso es Maximizaci´on Max.

String objop = "Max";

5. Ahora se le da nombres a las variables que tiene el sistema para que el usuario las opere como quiera, en la funci´on de valor tanto del caso base como de los ca-sos inductivos, tambi´en son indispensables para la inducci´on, con la condici´on de sucesores y las operaciones que se hacen sobre estos.

String cost= "cost";

//Corresponde al nombre de la variable del costo, capacidad, etc. Fijo por estado.

String indcost = "rescap";

// Corresponde al nombre de la variable asociada con el costo, capacidad de la pregunta

String polval = "policyval";

// Corresponde al nombre de la variable que acumula el valor por escoger ese

estado y todos los que se tomaron para llegar all String valname = "val";

// Corresponde al valor inmediato de incurrir en un estado, para cierta etapa.

String stateval = "sval";

// Corresponde al valor generado por el estado indicado por el usuario.

s.setInductiveCostName(indcost); s.setCostName(cost);

s.setPolicyValueName(polval); s.setValueName(valname);

s.setStateVariableName(stateval);

6. Se crea las condiciones inductivas, que indican como encontrar los sucesores. Apoyada en los nombres antes mencionados. En este caso se indica que los sucesores son para este caso inductivo, los que quepan dentro de la capacidad restante.

Collection icond = new Vector(); icond.add("rescap - cost >= 0");

7. Se asocia a cada condici´on inductiva, una funci´on que indica que hacer con los sucesores. Apoyada en los nombres antes mencionados. En este caso, con lo sucesores, se saca la nueva capacidad restante, y la pregunta, se soluciona para un subproblema. Nota: Se debe respetar que las condiciones inductivas sean excluyentes, es decir, ya que los sucesores son generados por esta condici´on, estas condiciones no deben genera grupos de sucesores, cuya intersecci´on sea diferente de vac´ıo.

Collection next = new Vector(); next.add("rescap - cost"); s.setNext(next);

8. Se le hace expl´ıcito a la librer´ıa la funci´on que genera un valor a devolver cuando el algoritmo encuentre el caso base, para este caso debe devolver el valor de incurrir en ese estado.

s.setBcVal(val);

9. Se le hace expl´ıcito a la a librer´ıa la funci´on que genera un valor a devolver cuando el algoritmo encuentre un caso inductivo dado, aqu´ı se ve que el usuario le indica al algoritmo que sume al acumulado de la funci´on de valor, el valor de incurrir en ese estado.

s.setValueFormula("policyval + val");\\

10. Por ´ultimo se llama al m´etodo solve(), y se le ingresan estos p´arametros

s.solve(sts, capacities, icond, objop);

Luego de haber realizado estos pasos se corre el m´etodo solve() de la libr-er´ıa y en consola aparecer´an, el valor correspondiente a la funci´on objetivo evaluada seg´un los par´ametros de la pregunta y el conjunto de decisiones que corresponde a la pol´ıtica que mejor se ajusta al problema de programaci´on din´amica.

Ap´

endice B

Investigaci´

on previa

Analice cuatro de los m´ultiples problemas de programaci´on din´amica, los cuales fueron inspeccionados para encontrar similitudes y diferencias. Ya que lo que se buscaba, era crear un API que pueda solucionar cualquier problema de programaci´on din´amica, aunque se ve una convergencia entre los datos que se requieren seg´un esta investigaci´on, con los datos que se propone en la metodolog´ıa, ver secci´on1.5. Los problemas analizados son algunos de los problemas din´amicos m´as mencionados, y de conocimiento publico fueron:

1. El del Morral1

2. El de los signos

3. Ruta m´as corta

a) Correcci´on de etiquetas

b) Rama m´as pesada en un ´arbol c) Ruta m´as larga o m´ax. beneficio

4. Subcadena comn entre Cadenas, tiene ligero parecido al de los signos

Entre los anteriores problemas mencionados, se recorre entre posibles soluciones, encontrando por etapas cual es la mejor condici´on, y as´ı, llegar al mejor beneficio.

1_{Este es el problema por excelencia m´as nombrado en cuanto a programaci´on din´amica, se} puede ver m´as a fondo ver Bertsekas[1]

La diferencia entre estos, es que calcular estados alcanzables desde un estado y una etapa, es m´as expl´ıcita unos que otros, es decir, unos calculan a donde pueden llegar y otros simplemente por asignaci´on alcanzan sus estados alcanzables.

Luego de tener estados alcanzables, se encuentra la mejor decision entre estos. Este paso es mucho m´as f´acil que el anterior, porque se vuelve a tomar la famosa ecuaci´on de Bellman.

B.1.

Datos gen´

ericos

B.1.1. C´alculos y datos por el usuario

1. Contador de objetos i y cual es su m´aximo valor

2. Peso, costo o distancia p(i) esto esta asociado a un estado y una etapa.

3. Utilidad o beneficio u(i).

4. Restricciones de costo asocia p(i) con un m´aximo Costo, si hay Costos

5. Restricciones de utilidad asocia u(i) con un m´ınimo de Utilidad si hay Utili-dades

6. Caso base relacionada con la funci´on objetivo. Requerido

7. Caso Inductivo en funci´on de la F.O. Requerido con condici´on y estos con datos asociados a las variables de decisi´on

8. Caso transitivo o mejoras al algoritmo, que se puede desarrollar luego de aplicar el inductivo. Para acelerar la respuesta. Opcional

9. Operador funci´on objetivo min., m´ax. Requerido

10. Pregunta, es el estado para el cual se quiere evaluar funci´on objetivo. En el caso del morral como maximiz´o el morral si el tama˜no es 0.3 metros c´ubicos.

11. Variables de decisi´n, que se deben guardar por estado, como quien es mi pre-decesor. Si quiero saber la ruta.

B.1.2. C´alculos y datos del programa 1. Rangos, dados por la inicializaci´on

2. Estados marcados o estados parcialmente ´optimos, dados por la inicializaci´on y modificados por la inducci´on, es decir, avance y control de etapas

3. Estados posibles , dados por la inicializaci´on y modificados por la inducci´on

4. Inicializaci´on de variables, en funci´on de otras o transformadas. Expl´ıcitamente estados alcanzables a partir de restricciones e inducci´on.

5. transformar restricciones en estados alcanzables o aceptar matriz de estados alcanzables.

Referencias

[1] Ravindra K. Ahuja. Network Flows, Theory, Algorithms and Applications. Num-ber 013617549X. Prentice Hall, Englewood Cliffs, New Jersey, 1993.

[2] Richard Bellman. Dynamic Programming. Princeton University Press, Princeton, N.J., 1956.

[3] Dimitri P. Bertsekas. Dynamic Programming and Optimal Control, volume II. Athena Scientific, Belmont, Massachusetts, 1995.

[4] Jaime Boh´orquez. Dise˜no efectivo de programas correctos. Editorial Escuela Colombiana de Ingenier´ıa, 2006.

[5] Gerald J. Lieberman Frederick Hillier. Introducci´on a la investigaci´on de

opera-ciones. McGraw - Hill, 3 edition, enero 1982. traducci´on de la tercera edici´on.

[6] Ronald L. Rivest Thomas Cormen, Charles E. Leiserson. Introduction to