3560902039074UTFSM

UNIVERSIDAD TECNICA FEDERICO SANTA MARIA
Peumo Repositorio Digital USM https://repositorio.usm.cl

Departamento de Arquitectura Arq_paso
2021
ENFOQUE METAHEURÍSTICO PARA

LA PLANIFICACIÓN DE
CONFERENCIAS BASADAS EN TRACKS
RIQUELME MACÍAS, FABIÁN MARCELO GUILLERMO
https://hdl.handle.net/11673/52725
Downloaded de Peumo Repositorio Digital USM, UNIVERSIDAD TECNICA FEDERICO SANTA MARIA
UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA
DEPARTAMENTO DE INFORMÁTICA
SANTIAGO DE CHILE - CHILE
“ENFOQUE METAHEURÍSTICO PARA LA PLANIFICACIÓN

DE CONFERENCIAS BASADAS EN TRACKS”
FABIÁN MARCELO GUILLERMO

RIQUELME MACÍAS
MEMORIA PARA OPTAR AL TÍTULO DE

INGENIERO CIVIL EN INFORMÁTICA
Profesor Guı́a: Elizabeth Montero

Profesor Correferente: José Luis Martı́
1
Agradecimientos
Este trabajo presenta el último paso para conseguir mi tı́tulo y por ende, es el mejor momen-
to para agradecer a la gente que me acompañó durante el proceso!
Quisiera agradecer a mi familia; especialmente a mi papá Daniel Riquelme Celis y mi mamá

Rosita Macias Rivera, gracias por criarme tan bien (en lo posible que salı́) y darme el apoyo
que siempre he recibido y por lograr entregar un hogar lleno de cariño. Se agradece a mis
hermanas Javiera y Sofı́a que junto a mis padres es imposible que no me hagan reı́r por alguna
tontera durante el dı́a; eso se agradece mucho.
Gracias especiales a mis dos pares de abuelos, que me criaron y cuidaron gran parte de mi
infancia, lo que no fue por compromiso, sino que me quieren mucho, donde por igual ellos
querı́an pasar tiempo conmigo y yo querı́a pasar tiempo con ellos. Mis abuelos maternos
que me cuidaron de más grande, mi tata Isaı́as Macı́as y me lela Rosita Rivera; y mis abuelos
paternos que me criaron de chiquito, mi tata Edmundo Riquelme y mi abuelita Gloria Celis.
Sin ellos toda mi vida hubiera sido diferente y estoy muy agradecido que me quisieran tanto
y me preocupo todos los dı́as que los veo en devolverles ese cariño.
Agradecimientos extras a mis compañeros y amigos; que sin ellos no me hubiera divertido
tanto en la universidad. Procrastinar con ustedes fue un honor caballeros, espero podamos
procrastinar en el futuro!
Finalmente gracias a mi profesora guı́a, que por suerte conocı́a de antemano e hizo que este
trabajo fuese divertido de hacer.
ÍNDICE GENERAL
Siglas 9
1 Introducción 10
2 Definición del problema 12

2.1 Problema de la Planificación de Conferencias basadas en Tracks . . . . . . . 12
2.2 The Genetic and Evolutionary Computation Conference . . . . . . . . . . . . 13
2.2.1 Programa/Grilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Artı́culo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.4 Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5 Celda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.6 Mejores Artı́culos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.7 HUMIES, ECIP y HOP . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Especificación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Solución actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Modelo matemático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1 Modelo simplificado . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.3 Constantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.4 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.5 Modelo extendido . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.6 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.7 Variables auxiliares . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2
3
2.6.8 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 Función Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Marco Conceptual 30
3.1 Estudios previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Taxonomı́a del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Estudios relevantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Propuesta de Solución 42
4.1 Construcción inicial de sesiones . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1 Construcción inicial aleatoria . . . . . . . . . . . . . . . . . . . . . . 43
4.1.2 Construcción inicial Greedy . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Representación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Función de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3 Estructura de la propuesta . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.4 Movimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.5 Parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 Experimentos 55
5.1 Formato de Instancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Generador de Instancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Análisis de instancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Instancias de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5 Sintonización de parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.6 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 Validación de la Solución 68
6.1 Resultados de Gurobi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Resultados de la heurı́stica . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.1 Sintonización manual . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2.2 Sintonización para mejor calidad . . . . . . . . . . . . . . . . . . . . 78
6.2.3 Sintonización para mejor tiempo . . . . . . . . . . . . . . . . . . . . 78
6.2.4 Comparativa entre sintonizaciones . . . . . . . . . . . . . . . . . . . 80
6.2.5 Análisis de convergencia . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3 Comparativa de Gurobi con Heurı́stica . . . . . . . . . . . . . . . . . . . . . 87
6.4 Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7 Conclusiones 91
ÍNDICE DE FIGURAS
2.1 Conferencia ilustrativa de 24 artı́culos, 3 tracks, 3 bloques horarios y 2 salones. 13

2.2 Planificación de la GECCO 2019 . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Diagrama de clases del problema (UML) . . . . . . . . . . . . . . . . . . . . 15
2.4 Pequeño programa de 15 sesiones y 5 tracks . . . . . . . . . . . . . . . . . . 15
2.5 Detalles de la composición de una sesión . . . . . . . . . . . . . . . . . . . . 16
2.6 Ejemplificación de definición de variables. (1) Simboliza el asignar las varia-
bles wps . (2) Simboliza la asignación de artı́culos en sesiones xas . (3) Simboliza
la asignación de ysrb , una sesión dentro de la grilla/programa. . . . . . . . . 21
3.1 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Asignación de 3 tuplas de artı́culos para un problema ABP de una conferencia
de 12 artı́culos y 4 sesiones paralelas. . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Intercambio entre sesiones para un problema ABP . . . . . . . . . . . . . . . 37
3.4 Intercambio de artı́culos de una misma sesión para un problema ABP . . . . 37
4.1 Programa construido mediante asignación secuencial izquierda-derecha arriba-

abajo (los números representan el orden de inserción en la grilla) . . . . . . . 46
4.2 Ilustración del intercambio de sesiones . . . . . . . . . . . . . . . . . . . . . 50
4.3 Intercambio de artı́culos, se eligen dos sesiones de un mismo track y se in-
tercambian dos artı́culos aleatorios de cada uno . . . . . . . . . . . . . . . . 52
6.1 Visualización de FreeViz: Correlación de variables respecto al objetivo del

tiempo para las instancias factibles . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 Ejemplo de gráfica con ejes lineales. . . . . . . . . . . . . . . . . . . . . . . 84
4
ÍNDICE DE FIGURAS 5
6.3 Convergencia para la instancia (5). Instancia que Gurobi determinó óptima
con el mayor tiempo de cómputo. Semilla (3717). Ejes en escalas logarı́tmicas. 85
6.4 Convergencia para la instancia (2). Una de las instancias para las que Gurobi
alcanzó un lı́mite de tiempo. Semilla (8355). Ejes en escala logarı́tmica. . . . . 86
6.5 Convergencia para la instancia (21). Instancia infactible con mayor tiempo de
cómputo. Semilla (5877). Ejes en escala logarı́tmica. . . . . . . . . . . . . . . 87
ÍNDICE DE TABLAS
3.1 Restricciones duras comunes para el Examination Timetabling . . . . . . . . 32

3.2 Restricciones blandas comunes para el Examination Timetabling . . . . . . . 33
5.1 Las 45 instancias seleccionadas. . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2 Subconjunto de instancias de entrenamiento del proceso de sintonización. . . 65
5.3 Resumen de configuraciones de parámetros . . . . . . . . . . . . . . . . . . 67
6.1 Resultados para 28 de 45 instancias para las que Gurobi encontró el óptimo.
Descendiente según tiempo de ejecución. . . . . . . . . . . . . . . . . . . . 70
6.2 Resultados para 5 de 45 instancias para las que Gurobi no alcanzó a encontrar
el óptimo. Descendiente según tiempo de ejecución. . . . . . . . . . . . . . 70
6.3 Resultados para 12 de 45 instancias para las que Gurobi determinó que no
existe solución. Descendiente según tiempo de ejecución. . . . . . . . . . . . 71
6.4 Resultados para análisis de correlación con métricas de Pearson y Spearman . 73
6.5 Resultados heurı́sticos para 28 instancias con óptimo conocido. 25 semillas.
Parámetros manuales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.6 Resultados heurı́sticos para 5 instancias con óptimo desconocido por tiempo.
25 semillas. Parámetros manuales. . . . . . . . . . . . . . . . . . . . . . . . 75
6.7 Resultados heurı́sticos para 12 instancias determinadas como infactibles. 25
semillas. Parámetros manuales. . . . . . . . . . . . . . . . . . . . . . . . . . 76
Parámetros para maximizar calidad. . . . . . . . . . . . . . . . . . . . . . . 79
25 semillas. Parámetros para maximizar calidad. . . . . . . . . . . . . . . . . 79
6
ÍNDICE DE TABLAS 7

semillas. Parámetros para maximizar calidad. . . . . . . . . . . . . . . . . . 80
Parámetros para minimizar tiempo. . . . . . . . . . . . . . . . . . . . . . . 81
25 semillas. Parámetros para minimizar tiempo. . . . . . . . . . . . . . . . . 81
semillas. Parámetros para minimizar tiempo. . . . . . . . . . . . . . . . . . . 82
6.14 Resumen acumulativo (suma) de las tres sintonizaciones para las 45 instan-
cias para 25 semillas distintas. 3×24×25 ejecuciones. . . . . . . . . . . . . . 82
6.15 Comparativa de los resultados de GUROBI con la heurı́stica para instancias
con óptimo conocido. Mejores valores . . . . . . . . . . . . . . . . . . . . . 89
con óptimo desconocido debido al tiempo. Mejores valores . . . . . . . . . . 89
determinadas como infactibles. Mejores valores . . . . . . . . . . . . . . . . 90
ÍNDICE DE ALGORITMOS
1 Construcción aleatoria de artı́culos en sesiones. . . . . . . . . . . . . . . . . . 43

2 Asignación de artı́culos a sesiones mediante un criterio de construcción greedy 44
3 Función de evaluación con factor de amplificación γ y cantidad de artı́culos
por sesión nAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 Flujo general de Simulated Annealing (SA) con enfriamiento proporcional y
recalentamiento lineal proporcional al número de iteraciones. . . . . . . . . . 49
5 Intercambio de sesiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Intercambio de chairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 Intercambio de Organizador . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8 Intercambio entre artı́culos . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9 Comportamiento general del generador de instancias . . . . . . . . . . . . . 59

10 Definición de un ILS adaptado a la búsqueda de parámetros(portado comple-
tamente desde el artı́culo[HHS07] y por ende los créditos van a su respectivo
autor). Donde IterativeFirstImprovement es una función que busca aleatoria-
mente el primer vecino de θ que sea mejor. . . . . . . . . . . . . . . . . . . . 64
8
SIGLAS
ABP attender-based perspective. 4, 18, 32, 35, 37, 41, 91

ACM Association for Computing Machinery. 13
ACO-SI Ant Colony Optimization and Swarm Intelligence. 17
B&B Branch & Bound. 31
CoSP Conference Scheduling Problem. 12, 30, 32, 54, 91

CS Complex Systems (Artificial Life / Artificial Immune Systems / Generative and Develop-
mental Systems /Evolutionary Robotics / Evolvable Hardware). 17
EMO Evolutionary Multiobjective Optimization. 14, 17
GECCO The Genetic and Evolutionary Computation Conference. 10, 12–14, 16, 25, 28, 33, 35,
38, 39, 60, 62, 67, 91, 92
ILS Iterated Local Search. 64
PBP presenter-based perspective. 32, 33, 35, 38, 39, 41, 91
RWA Real World Applications. 16, 17
SA Simulated Annealing. 8, 31, 38, 45, 47, 49, 52, 83, 92

SIGEVO Special Interest Group on Genetic and Evolutionary Computation. 13
9
CAPÍTULO
INTRODUCCIÓN
Las conferencias cientı́ficas son un aspecto esencial del mundo académico. Permiten a los
presentadores exponer su trabajo, a los participantes asistir a charlas de interés y de esa
forma complementar la instancia con retroalimentación activa de un tema particular de es-
tudio. Sin embargo, realizar una conferencia puede esconder grandes gastos y problemas.
Costos que van desde la inversión inicial de organizar un evento hasta los gastos en viajes in-
ternacionales. De este último es incluso posible encontrar un costo medioambiental [Gré08],
llevándonos a preguntar qué tan sustentable es una conferencia [Neu+20].
Al enfocarse en las personas, es posible notar que la correcta planificación del evento juega
un papel clave en el buen uso del tiempo. Los planificadores usualmente se ven abrumados
por la gran cantidad de tiempo que toma programar una planificación exitosa y el efecto que
ésta puede tener en sus asistentes. No se ha mencionado, además, que los participantes
pueden tener roles claves en la sociedad, caso notable es el de los obstetras [GLV07], el cual
debido a una gran conferencia anual logran disminuir la tasa de natalidad en las fechas de
dicha conferencia. Finalmente debido a la condición global actual se empezó cuestionar más
que nunca el tema de las conferencias online, para las cuales ya se están realizando estudios
[MMW20] enfocados en mejorar la experiencia de éstas.
El problema a tratar en este documento consiste en la formulación, diseño y estudio de un

algoritmo de planificación y organización de charlas para conferencias The Genetic and Evo-
lutionary Computation Conference (GECCO) 1 . Buscando, a través del uso de técnicas heurı́sti-
cas, soluciones de calidad que estén a la altura de situaciones reales en tiempos acotados.
1
https://gecco-2019.sigevo.org/index.html/HomePage
10
CAPÍTULO 1. INTRODUCCIÓN 11
El problema general consiste en un conjunto de artı́culos que deben ser programados dentro
de sesiones en un programa especifico, programa que puede estar extendido en múltiples
dı́as y horarios. Cada artı́culo está enfocado en un tema en particular, es presentado por un
expositor y está asociado a una categorı́a temática (track). Todo esto junto a un importante
número de restricciones espacio-temporales que dificultan el proceso de programación de
una adecuada planificación final.
Las dificultades y necesidades de este problema radican principalmente en la diversidad y

cantidad de restricciones que se deben cumplir, asociadas a imposibilidades espaciales que
los expositores puedan tener al no poder estar en dos lugares a la vez o bien las temporales de
acuerdo a las disponibilidades horarias de los expositores. Finalmente existen necesidades
particulares de cada conferencia y veremos que las GECCO al ser una conferencia orientada
en tracks requiere el cumplimiento de restricciones adicionales que permiten definir una
nueva variante del problema y, por ende, un nuevo caso de estudio.
En este trabajo de memoria se propone un modelo matemático de programación lineal para

dos formulaciones alternativas del problema estudiado. Además, se propone un generador
de instancias que permite generar casos de prueba para el estudio del problema. Por últi-
mo, se propone un acercamiento de búsqueda local para encontrar solución a los casos de
pruebas más complejos.
Se presenta un proceso de evaluación que resuelve los casos de pruebas sencillos usando el
modelo matemático propuesto implementado en el solver Gurobi y los casos más comple-
jos usando el algoritmo de búsqueda local. A partir de los resultados presentados es posible
concluir que ambos acercamientos son capaces de encontrar soluciones de calidad en gran
parte de los problemas. Por otro lado en los casos más complejos el acercamiento heurı́sti-
co es capaz de encontrar soluciones de muy buen nivel en tiempos muy acotados, siendo
incluso capaz de entregar recomendaciones para resolver instancias que son consideradas
infactibles. Ası́, los acercamientos pueden ser considerados como herramientas eficientes
para la toma de decisiones administrativas con respecto a la planificación de una conferen-
cia, minimizando los costos asociados y generando un buen marco de estudio del problema.
CAPÍTULO
DEFINICIÓN DEL PROBLEMA
En este capı́tulo se presenta una definición general del problema de planificación de con-
ferencias también conocido como Conference Scheduling Problem (CoSP). La definición se
enfoca principalmente en las conferencias GECCO. Se detallan los actores e involucrados,
participantes y asistentes, el problema actual y las dificultades futuras. Todo esto a fin de
determinar qué recursos son escasos y convierten al CoSP en un problema de difı́cil resolu-
ción. En detalle este capı́tulo entregará la definición formal del problema acompañado de un
modelo matemático de programación lineal para el problema.
2.1. Problema de la Planificación de Conferencias basadas en

Tracks
El CoSP corresponde a un problema de programación (Scheduling), para el cual se necesita

asignar eventos, en este caso las presentaciones de artı́culos, a un lugar fı́sico y horario en
particular. Una conferencia puede tener muchos horarios disponibles, incluso disperso en
muchos dı́as, mientras que, por otro lado, la misma conferencia puede tener muchas habi-
taciones, permitiendo ası́ la planificación de muchos eventos en paralelo. Esta última idea es
la que determina lo que se conoce como Programa o Grilla2D de una conferencia. Es posible
extender esta definición con más recursos y restricciones asociadas al evento.
Un problema CoSP puede ser definido a partir de artı́culos que deben ser expuestos exacta-
12
CAPÍTULO 2. DEFINICIÓN DEL PROBLEMA 13
mente una vez a lo largo del programa de la conferencia. Se busca que la planificación pueda
entregar una grata experiencia tanto para los asistentes como para los expositores. Por esto
algunas conferencias organizan las exposiciones de acuerdo a temas de interés. Ası́, es po-
sible entender un track como una categorı́a temática o lı́nea de estudio a la que pertenece
cada artı́culo.
La Figura 2.1 provee un breve ejemplo de una conferencia de 3 Tracks, diferenciados por
colores distintos, con 24 artı́culos agrupados en seis sesiones utilizando dos salones y tres
bloques horarios. Además, se considera que cada sesión puede contener cuatro artı́culos.
Para este ejemplo, los artı́culos 13, 14, 15, 16, 5, 6, 7 y 8 pertenecen al track verde y, por
ende, son afines entre si en términos de área de estudio. Una conferencia basada en tracks
tiene como principal enfoque evitar sesiones de un mismo track en paralelo. Esto para que
los asistentes interesados en tracks especı́ficos puedan asistir a cada una de las sesiones y
puedan atender todas las presentaciones del tema. La conferencia ilustrativa de la Figura 2.1
representa una conferencia de juguete que posee una solución trivial.
HORARIO 1 HORARIO 2 HORARIO 3
SALON 1 1 2 3 4 5 6 7 8 9 10 11 12
SALON 2 13 14 15 16 17 18 19 20 21 22 23 24
Figura 2.1: Conferencia ilustrativa de 24 artı́culos, 3 tracks, 3 bloques horarios y 2 salones.

Fuente: Contenido Original
2.2. The Genetic and Evolutionary Computation Conference
Las conferencias The Genetic and Evolutionary Computation Conference (GECCO) 1 son una
de las conferencias más selectivas del campo de la inteligencia artificial, siendo además la
más importante de la SIGEVO de la ACM, por lo tanto, su planificación es clave para los
académicos e investigadores del área.
El enfoque utilizado por dicha conferencia consiste en organizar un programa para el cual
cada artı́culo sea programado en las mismas sesiones junto a otros artı́culos de una misma
Área de Estudio (Track)2 . Se considera, además, que las sesiones se programan dispersas
a lo largo de distintos bloques de tiempo, con exposiciones en paralelo a lo largo de una
cantidad de salas disponibles. Para las GECCO cada uno de los artı́culos pertenecen a uno
de los 13 tracks definidos, y como se mencionó antes, cada uno de los artı́culos dentro de la
misma sesión comparten track.
1
https://gecco-2019.sigevo.org/index.html/Program
2
https://forum.wordreference.com/threads/track-conference.1654475/
La planificación que tuvo lugar el año 2019 se presenta en la Figura 2.2. La imagen muestra
dos dimensiones, una dimensión espacial denotada por las filas de la tabla que representan
las salas disponibles para las sesiones y una dimensión temporal indicando todos los bloques
de horarios para los cuales es posible programar una sesión. La planificación tuvo un total
de 56 sesiones, 13 tracks, 7 horarios, 8 salones utilizados y máximo 4 artı́culos por sesión. Es
posible observar, además, que cada sesión se identifica por una sigla seguida de un número,
la sigla representa el track correspondiente mientras que el número es un identificador de la
sesión a fin de diferenciar las sesiones de un mismo track. Concretamente es posible observar
que la primera sesión del salón “South Hall 1A” fue llevada a cabo el dı́a lunes 15 de Julio
Schedule and Floor Plans 29
por la mañana y se presentaron artı́culos únicamente del track Evolutionary Multiobjective
Optimization (EMO). Las 13 categorı́as pueden ser revisadas en el sitio web de la GECCO.
Parallel Sessions, Monday, July 15 through Wednesday, July 17
Monday Monday Monday Tuesday Tuesday Tuesday Wednesday

July 15 July 15 July 15 July 16 July 16 July 16 July 17
10:40-12:20 14:00-15:40 16:10-17:50 10:40-12:20 14:00-15:40 16:10-17:50 09:00-10:40
EMO1 EMO2 GA1 RWA4 CS3 EMO4 EMO5
South +GECH3
Hall 1A
p. 73 p. 75 p. 78 p. 82 p. 83 p. 86 p. 89
EML1 HUMIES GP3 DETA1 ENUM2 ECOM5 GP4
South +SBSE2
Hall 1B +THEORY2
p. 73 p. 60 p. 78 p. 80 p. 84 p. 86 p. 90
GP1 GP2 ENUM1 GA2 GA3 GA4 GA5
Club A
p. 73 p. 75 p. 77 p. 81 p. 84 p. 87 p. 89
ECIP1 ECIP2 ECIP3 HOP1 HOP2 HOP3 HOP4
Club B
p. 64 p. 64 p. 64 p. 81 p. 84 p. 87 p. 90
ACO-SI1 THEORY1 GECH1 ACO-SI2 RWA5 THEORY3
Club C
p. 72 p. 76 p. 78 p. 80 p. 85 p. 88
ECOM1 ECOM2 EMO3 ECOM3 ECOM4 RWA7 GECH4
Club D
p. 72 p. 75 p. 77 p. 81 p. 83 p. 87 p. 89
CS1 SBSE1 EML2 CS2 EML3 EML4 DETA2
Club E
p. 72 p. 76 p. 77 p. 80 p. 83 p. 86 p. 89
RWA1 RWA2 RWA3 GECH2 RWA6 RWA8 RWA9
Club H
p. 74 p. 75 p. 78 p. 81 p. 85 p. 88 p. 90
Authors
Panorama Poster
Hall Setup
Sessions with best

HUMIES ECiP HOP
paper nominees
Figura 2.2: Planificación de la GECCO 2019

Fuente: GECCO 2019
A lo largo de esta sección se definirá en detalle el caso de estudio, donde se busca que un con-
junto de artı́culos sean planificados dentro de un programa en sesiones distribuidas espacio-

temporalmente, y que cada sesión tenga únicamente artı́culos un mismo track. La Figura 2.3
presenta un breve modelo de clases para entender la estructura del problema.
1 1+ 1+ 1
EXPOSITOR ARTICULO SESION
1+ 1+
1
1
TRACK
Figura 2.3: Diagrama de clases del problema (UML)

A continuación se presentan las principales componentes del problema.
2.2.1. Programa/Grilla
Un programa consiste en una grilla bidimensional que ubica sesiones a lo largo del tiempo
y espacio. A su vez cada sesión ubica artı́culos de un mismo track. La Figura 2.4 muestra un
ejemplo de una conferencia pequeña de quince sesiones y con cinco tracks.
Figura 2.4: Pequeño programa de 15 sesiones y 5 tracks

2.2.2. Artı́culo
Un artı́culo consiste en un documento que debe ser expuesto dentro de una sesión. Cada
artı́culo pertenece a un único track. Cada artı́culo debe tener al menos un expositor. Es im-
portante indicar que un expositor puede presentar varios artı́culos. Un ejemplo de un artı́culo
serı́a “Control Parameter Sensitivity Analysis of the Multi-guide Particle Swarm Optimization
Algorithm” de los autores “Kyle Harper Erwin (Allan Gray, University of Stellenbosh) y Andries
Engelbrecht (University of Stellenbosh)”3 .
2.2.3. Sesión
Una sesión es un conjunto de artı́culos de un mismo track. Históricamente dentro de las

GECCO las sesiones consideran entre tres y cinco artı́culos. Por ejemplo, para la planificación
de la GECCO-2019 (Figura 2.2), la sesión de Real World Applications (RWA) (octava fila y pri-
mera columna) está compuesta por tres charlas de un mismo track, presentadas de forma
secuencial por sus respectivos expositores y dirigidas por al menos un maestro de ceremonia
que este presente durante toda la sesión en cada uno de los artı́culos, y asistido igualmente
por algún organizador del track. A continuación de listan los tres artı́culos dentro de dicha
sesión.
A Hybrid Evolutionary Algorithm Framework for Optimising Power Take Off and Place-
ments of Wave Energy Converters
A Novel Hybrid Scheme Using Genetic Algorithms and Deep Learning for the Recons-
truction of Portuguese Tile Panels
Multiobjective Shape Design in a Ventilation System with a Preference-driven Surrogate-

assisted Evolutionary Algorithm
10:40
A Hybrid Evolutionary Algorithm Framework for Optimisin...
A Novel Hybrid Scheme Using Genetic Algorithms...
Multiobjective Shape Design in a Ventilation System....

12:20
Figura 2.5: Detalles de la composición de una sesión

Fuente: Contenido Original, información desde la GECCO
3
https://gecco-2019.sigevo.org/index.html/Accepted+Papers
2.2.4. Tracks
Los tracks corresponden a categorı́as temáticas, o bien áreas de estudio. Un track consiste en
un tema especı́fico para el cual un grupo de investigadores interesados en el área propone
dicha categorı́a como parte de la conferencia. Hasta la fecha de la última conferencia existı́an
13 tracks distintos en GECCO. Algunos de los más conocidos Ant Colony Optimization and
Swarm Intelligence (ACO-SI), Complex Systems (Artificial Life / Artificial Immune Systems /
Generative and Developmental Systems /Evolutionary Robotics / Evolvable Hardware) (CS)
y Real World Applications (RWA). Mas información puede encontrarse en el sitio web de la
conferencia4 .
Cada track tiene un comité que organiza y revisa los artı́culos enviados, determina los artı́cu-
los nominados a mejor artı́culo y asigna los maestros de ceremonia (chairs) y organizadores
que estarán presentes en cada una de las sesiones.
2.2.5. Celda
Una celda corresponde a un espacio dentro de la grilla, su único propósito es servir de con-
tenedor para una sesión. Una conferencia no necesariamente va a llenar cada uno de los
espacios disponibles en la grilla con sesiones.
2.2.6. Mejores Artı́culos
Los mejores artı́culos corresponden a artı́culos nominados a participar por un reconocimien-

to como el mejor artı́culo en su categorı́a (best paper), y por ende para cada track existe un
único ganador.
Históricamente los tracks tienen la facultad para nominar un subconjunto de los artı́culos
pertenecientes a dicho track para mejor artı́culo. Luego dichos artı́culos son planificados en
una misma sesión y votados por los asistentes. Como ejemplo la GECCO-2019 tuvo 13 tracks,
de los cuales 11 nominaron artı́culos. En mas detalle el track Evolutionary Multiobjective Op-
timization (EMO) de entre sus más de 30 artı́culos, únicamente nominó 4 y los planificó en la
sesión EMO2 (primera fila y primera columna). Las sesiones con las presentaciones de estos
artı́culos se presentan destacados con una estrella ? en la Figura 2.2.
4
https://gecco-2020.sigevo.org/index.html/Program+Tracks
2.2.7. HUMIES, ECIP y HOP
Corresponden a tracks particulares que van mas allá de la mera presentación de un artı́culo,
dichas sesiones no nominan artı́culos a mejor artı́culo.
2.3. Actores
Para las conferencias GECCO se tiene los siguientes involucrados: expositores, organizado-
res, chairs, y un comité de planificación. En primer lugar los expositores corresponden a
personas encargadas de presentar artı́culos. Estas personas pueden ser o no el autor del
artı́culo en cuestión y cada expositor puede presentar mas de un artı́culo para una misma
conferencia. Los organizadores tienen un papel más que nada administrativo, pero se busca
que al menos un organizador pueda estar presente en las sesiones de sus respectivos tracks.
Los chair corresponden a los maestros de ceremonia de cada sesión y se necesita que estén
presentes en la sesión completa. Históricamente cada track tiene dos chairs.
Finalmente los asistentes, que corresponden a las personas naturales y académicos que asis-
ten a la conferencia, son clave en la especificación del problema de planificación de confe-
rencias basadas en preferencias de asistentes (attender-based perspective (ABP)[Van+18]),
pero son irrelevantes para esta formulación del problema.
2.4. Especificación del problema
A continuación se procederá a enumerar las especificaciones más importantes al momento

de realizar la planificación de una conferencia. Se necesita que cada artı́culo sea planificado
junto a otros de un mismo track, en sesiones a lo largo del programa, respetando preferen-
cias temporales y especiales de los expositores, chairs y organizadores, maximizar además la
asistencia a las sesiones con artı́culos nominados a mejor artı́culo y optimizando el uso del
espacio.
En resumen el problema se vuelve uno de asignar artı́culos en sesiones y sesiones en la

grilla respetando las restricciones. Sin embargo el modelo de satisfacción no permite que
una conferencia sea catalogada como exitosa, y por ende optimizar el uso del espacio es una
buena forma de evaluar la calidad del problema.
Se necesita optimizar la asistencia para los artı́culos nominados a “mejor artı́culo” a

fin de generar una votación con una suficiente población.
Se necesita minimizar la cantidad de sesiones, lo que implica minimizar la cantidad de

salones y horarios utilizados.
Se necesita que dos artı́culos de un mismo expositor estén idealmente separados al

menos por un intervalo de tiempo entre sesiones paralelas. Esto en el caso indesea-
ble que un expositor tenga que saltar de una sesión paralela a otra para presentar su
siguiente artı́culo.
Se necesita que cada sesión tenga al menos un chair que pueda estar presente durante
toda la sesión.
Se necesita que cada sesión tenga al menos un organizador que pueda estar presente
toda la sesión.
Se necesita cumplir con las preferencias horarias de los expositores. Estas preferencias
normalmente son una restricción o imposibilidad sobre ciertos bloques horarios.
Finalmente se busca optimizar el uso del espacio basado en la asistencia histórica que
cada track tiene y el tamaño de los salones a utilizar.
2.5. Solución actual
Actualmente hay 36 organizadores, 26 chairs y cerca de 90 encargados del comité de planifi-

cación. El conocimiento actual que se tiene de la planificación es que se hace a mano a partir
de la experiencia de conferencias pasadas. Esto obliga a realizar una cantidad importante
de intercambios de horarios y artı́culos dentro de lo posible hasta lograr un programa que
satisfaga la intuición experta.
2.6. Modelo matemático
A lo largo de esta sección se presenta un modelo matemático que considera, en primera

instancia, las restricciones esenciales del problema. Sin embargo la resolución estricta nor-
malmente dificulta encontrar soluciones factibles reales, por lo que mas adelante se extiende
el modelo para considerar el problema completo.
2.6.1. Modelo simplificado
Para la primera versión del modelo se presenta una versión simple del problema que permite
asignar artı́culos dentro de una sesión sin planificar internamente el orden de estos artı́cu-
los en cada sesión. El detalle de la planificación interna de cada sesión se planificará con el
modelo completo que se presenta en la siguiente sección.
Guı́a de sub-ı́ndices
Los ı́ndices a utilizar a lo largo de este documento seguirán normalmente la siguiente estruc-
tura.
a : (A)rticle/Artı́culo
b : (B)lock/Bloque
l : Subs(L)ot
r : (R)oom/Habitación (2.1)
p : (P)erson/Persona
s : (S)ession/Sesión
t : (T)rack
2.6.2. Variables
Debido a que el número de sesiones que se busca es el mı́nimo posible, es posible estimarlo
como la mı́nima cantidad por cada track de manera de lograr planificar todos los artı́culos.
Ası́, la cantidad de sesiones será considerado un valor constante a lo largo de la resolución
del modelo de programación lineal. A este parámetro se le denomina Ys .
Para el modelo se necesita manejar la asignación de artı́culos a sesiones xas , la asignación de

personas a sesiones wps y finalmente un método para asignar dichas sesiones en espacios y
tiempos ysrb . La figura Figura 2.6 muestra el proceso de asignación particularizando en tres
sesiones cualquiera; el punto (1) indica la variable wps que consiste en asignar expositores,
chairs y organizadores a una sesión. Para el punto (2) se planifican artı́culos (xas ) en sesiones,
sin embargo los artı́culos son quienes determinan al expositor y por ende la variable wps es
completamente dependiente de xas . Finalmente el punto (3) toma las sesiones previamente
construidas y las planifica en una grilla bidimensional de tamaño (Salones × Horarios)
xas ∈ (0, 1) = Artı́culo a se agenda en sesión s

wps ∈ (0, 1) = Persona p es asignada a sesión s (2.2)
ysrb ∈ (0, 1) = Sesión s se planifica en la celda (r,b)
1 2 3
Figura 2.6: Ejemplificación de definición de variables. (1) Simboliza el asignar las variables
wps . (2) Simboliza la asignación de artı́culos en sesiones xas . (3) Simboliza la asignación de
ysrb , una sesión dentro de la grilla/programa.
Variables auxiliares
Mas adelante se presentarán las restricciones del modelo, presentadas como un sistema
lineal y para escribir ciertas restricciones linealmente se necesita definir la siguiente variable
auxiliar.
σpsrb ∈ (0, 1) = La persona p se encuentra en la sesión s ubicada en (r,b) (2.3)
2.6.3. Constantes
A continuación se presenta un listado generado de constantes que ayudarán a la definición

del modelo.
Número de sesiones: La cantidad de sesiones es definida para cada instancia, dado que se
busca programar la conferencia minimizando la cantidad de sesiones a utilizar, es posible
determinar este la cantidad mı́nima de sesiones como las necesarias para planificar cada uno
de los artı́culos. Donde finalmente cada track tendrá un conjunto de sesiones disponibles.
Yt ∈ N = Cantidad de sesiones para el track t

articles(t)
Yt =
A
X
Por lo que la cantidad total de sesiones es Yt
t
Listado de Constantes
A ∈ N = Capacidad máxima de artı́culos por sesión
Ba ∈ (0, 1) = Artı́culo a es Best Paper
Fsr ∈ (0, 1) = Sesión s puede estar en salón el r
Tst ∈ (0, 1) = Sesión s pertenece al track t
Γa ∈ N = Track al que pertenece el artı́culo a
Λs ∈ N = Track al que pertenece la sesión s
∆sr ∈ N = Falta de espacio al planificar la sesión s en el salón r (2.4)
Autor(a) = Autor/Expositor del artı́culo a
Conf lictos(p) = Conjunto de bloques no permitidos para la persona p
Chairs(s) = Conjunto de chairs disponibles para la sesión s
Organizadores(s) = Conjunto de organizadores disponibles para la sesión s
Sesiones(t) = Conjunto de sesiones del track t
BestP aper() = Conjunto de todos los artı́culos que son best paper
La mayor parte del resto de las constantes del problema se explican por si solas, sin embargo,
a continuación se provee la descripción de aquellas que requieren especial consideración.
A: La capacidad máxima de artı́culos por sesión viene determinada por la duración de

los bloques de tiempo. Es un valor fijo e invariante de la sesión debido a que todos
los bloques del problema tienen una misma duración. En caso de considerar sesiones
de distinto tamaño, bastarı́a con extender esta misma variable por sobre la cantidad
de bloques (Ab ) y modificar las restricciones de acuerdo a los diferentes valores de
parámetros para obtener un modelo actualizado.
Autor(a)∪Chairs(s)∪Organizadores(s) ⊆ P ersonas: Cada conjunto de personas

es un subconjunto del espacio total de las personas disponibles.
∆sr : Las instancias originalmente informan la asistencia para los tracks, pero es posible
extender su valor para cada una de las sesiones pertenecientes al track. El parámetro
consiste en la diferencia entre la asistencia histórica y la capacidad del salón, o bien la
cantidad de espacio que faltó para cumplir con el histórico.
Hs ∈ N : Asistencia histórica de la sesión s.

Cr ∈ N : Capacidad del salón r.
(
Hs − Cr , si Hs > Cr
∆sr =
0, en otro caso
La decisión de extender esta constante por sesiones fue meramente debido a la facilidad de
escribir instancias y que son mucho mas cercanas a los datos provistos en la práctica.
2.6.4. Restricciones
A continuación se listan las restricciones del modelo matemático del problema.
1. Cada artı́culo debe ser planificado exactamente una vez.

X
xas = 1 ∀a (2.5)
s
2. Cada sesión no puede tener mas artı́culos que un máximo A.

X
xas ≤ A ∀s (2.6)
a
3. Cada sesión puede estar en una única celda (r, b) y a la vez cada celda solo puede ser
utilizada por una sesión. XX
ysrb = 1 ∀s (2.7)
r b
X
ysrb ≤ 1 ∀r, b (2.8)
s
4. Prohibir que un artı́culo se planifique en una sesión que no le corresponde por track.
xas = 0 ∀a, s, Γa 6= Λs (2.9)
5. Que un artı́culo sea planificado en una sesión implica que el autor también deberá
estar presente en esa sesión.
xas ≤ wps ∀a, s, p = autor(a) (2.10)

6. Que exista un artı́culo best paper en alguna sesión implica que la sesión será catalogada
como una contenedora de best paper ?.
xas · Ba ≤ bs ∀a, s (2.11)
7. Evitar que existan sesiones de un mismo track en paralelo.

XX
ysrb · Tst ≤ 1 ∀t, b (2.12)
s r
8. Evitar que autores/expositores tengan que presentar en bloques de tiempo con con-
flictos personales; ya sea por compromisos o la incapacidad de estar presente en dicho
horario.
wps + ysrb ≤ 1 ∀p, s, r, b ∈ conf lictos(p) (2.13)
9. Evitar que una persona cualquiera tenga que estar en más de dos sesiones paralelas al
mismo tiempo.
XX
σpsrb ≤ 1 ∀p, b (2.14)
s r
wps + ysrb − σpsrb ≤ 1 ∀p, s, r, b (2.15)
σpsrb ≤ wps ∀p, s, r, b (2.16)
σpsrb ≤ ysrb ∀p, s, r, b (2.17)
10. Planificar todos los best paper en una única sesión por cada uno de los tracks. Con-
siderando que la cantidad de best paper no será superior a la cantidad de artı́culos
por sesión, pueden ser planificados arbitrariamente en cualquier sesión. La siguiente
ecuación utiliza la primera sesión disponible para ello.
xas = 1 ∀t, a ∈ bestP aper(), s = sessions(t)0 (2.18)
11. Asegurarse que asista al menos un chair y un organizador a cada sesión de su respectivo
track y por ende respectiva sesión.
X
ysrb ≤ wps ∀s, r, b, p ∈ chairs(s) (2.19)
p
X
ysrb ≤ wps ∀s, r, b, p ∈ organizers(s) (2.20)
p
2.6.5. Modelo extendido
El modelo anterior puede ser extendido al micro manejo del tiempo para instancias en las
cuales la cantidad de restricciones es lo suficientemente grande para no lograr encontrar
una solución. Las GECCO no necesariamente deben seguir una relación 1-1 entre expositores
y artı́culos, y además la existencia de un expositor considerablemente solicitado puede gene-
rar soluciones infactibles considerando solo el modelo simplificado. En dichos casos confinar
a un expositor a una única sesión es un problema, ya que si la situación lo amerita dicha
persona deberı́a tener la capacidad de saltar entre sesiones (aunque esto fuese una solución
poco grata). Para esto se extiende el modelo a uno que considere los sub slot dentro de cada
sesión.
2.6.6. Variables
Las variables presentadas en el modelo simplificado serán extendidas para los subslot l des-
tacando los siguientes cambios:
La asignación de artı́culos xasl ahora incluye la dimensión l para cada uno de los subs-
lot.
La asignación de personas wpsl igualmente debe incluir la dimensión l para cada subs-
lot.
Se agregaron las variables cps y ops para representar que una persona designada como
chair u organizador debe estar en una sesión completa y no puede estar parcialmente
en una sesión.
xasl ∈ (0, 1) = Artı́culo a planificado en sesión s, subslot l (2.21)

ysrb ∈ (0, 1) = Sesión s en celda (r,b) (2.22)
wpsl ∈ (0, 1) = Persona p está en sesión s, slot l (2.23)
cps ∈ (0, 1) = Persona (chair) p en sesión s (2.24)
ops ∈ (0, 1) = Persona (organizador) p en sesión s (2.25)
2.6.7. Variables auxiliares
Del mismo modo que en el modelo simplificado, para poder escribir algunas restricciones
como expresiones lineales, es necesario definir la siguiente variable auxiliar.
σpslrb ∈ (0, 1) = La persona p en la sesión s y subslot l está en la celda (r,b) (2.26)
2.6.8. Restricciones
1. Cada artı́culo debe ser planificado una única vez.
XX
xasl = 1 ∀a (2.27)
s l
2. Cada sesión no puede tener más artı́culos que un máximo A.

XX
xasl ≤ A ∀s (2.28)
a l
3. Un subslot puede tener como máximo un solo artı́culo. (Nueva)

X
xasl ≤ 1 ∀s, l (2.29)
a
4. Cada sesión puede estar en una única celda (r, b) y a la vez cada celda solo puede ser
utilizada por una sesión a la vez.
XX
ysrb = 1 ∀s (2.30)
r b
X
ysrb ≤ 1 ∀r, b (2.31)
s
5. Prohibir que un artı́culo se planifique en una sesión que no le corresponde por track.
X
xasl = 0 ∀a, s, Γa 6= Λs (2.32)
l
6. Que un artı́culo sea planificado en una sesión implica que el autor/expositor también
deberá estar presente en esa sesión.
xasl ≤ wpsl ∀a, s, l, p = autor(a) (2.33)
7. Planificar todos los best paper en una única sesión por cada uno de los tracks, permi-
tiéndoles estar en cualquier subslot.
X
xasl = 1 ∀t,a ∈ BestP aper(), s = sessions(t)0 (2.34)
l
8. Evitar que existan sesiones de un mismo track en paralelo.

XX
ysrb · Tst ≤ 1 ∀t, b (2.35)
s r
9. Evitar que autores/expositores tengan que presentar en bloques de tiempo con con-
flictos personales; ya sea compromisos o la incapacidad de estar presente en dicho
horario.
wpsl + ysrb ≤ 1 ∀p, s, l, r, b ∈ conf lictos(p) (2.36)
10. Evitar que una persona cualquiera tenga que estar en más de dos sesiones paralelas al
mismo tiempo.
XX
σpslrb ≤ 1 ∀p, b, l (2.37)
s r
wpsl + ysrb − σpslrb ≤ 1 ∀p, s, l, r, b (2.38)
σpslrb ≤ wpsl ∀p, s, l, r, b (2.39)
σpslrb ≤ ysrb ∀p, s, l, r, b (2.40)
11. Asegurarse que asista al menos un chair y un organizador a cada sesión de su respectivo
track y por ende respectiva sesión.
X
ysrb ≤ cps ∀s, r, b, p ∈ chairs(s) (2.41)
p
X
A · cps ≤ wpsl ∀p, s (2.42)
l
X
ysrb ≤ ops ∀s, r, b, p ∈ organizadores(s) (2.43)
p
X
A · ops ≤ wpsl ∀p, s (2.44)
l
2.7. Función Objetivo
La propuesta de este modelo considera la minimización del espacio faltante de acorde a la

asistencia histórica de cada track.
Función Objetivo: Minimizar la falta del espacio
Considerar la asistencia histórica y la capacidad de los salones como una restricción dura no
resulta realista, pues considera que el problema podrı́a quedar sin solución por una persona
atendiendo una sesión de pie. Debido a esto, en este trabajo se opta por minimizar la falta
de asientos. Para ello es posible calcular un ∆sr que indique la diferencia absoluta entre la
capacidad histórica y la capacidad del salón y agregar una función objetivo de la forma:
XXX
mı́n z1 = ysrb · ∆sr
s r b
Espacio de búsqueda
Nuestro modelo matemático extendido finalmente consta de 5 tipos de variables distintas,

wasl , ysrb , wpsl , cps y ops , cada una binaria; no es difı́cil darse cuenta que la cantidad de solucio-
nes (incluyendo aquellas infactibles) es considerable. A continuación se presenta un cálculo
aproximado del espacio de búsqueda, el cual solo nos importa que el término final es expo-
nencial.
wasl · ysrb · wpsl · cps · ops =

2asl · 2asl · 2psl · 2ps · 2ps =
2s(l(2a+p)+2p) ∼ 2x → Exponencial
2.8. Resumen
En este capı́tulo se introduce el problema de planificación de conferencias. La presentación

del problema se centra especialmente en las conferencias orientadas en tracks, siendo la
GECCO el caso de estudio considerado.
Se definió cada una de las partes involucradas en las GECCO, esto es, recursos económicos,
temporales, espaciales, organizacionales y humanos. Junto con un conjunto de definiciones
que se resumirán nuevamente a continuación. La idea se puede resumir como determinar
el programa que asigna presentaciones de acuerdo a track y disponibilidad de expositores,
chairs y organizadores prohibiendo que sesiones del mismo track, ası́ como sesiones con best
paper se lleven a cabo en paralelo minimizando el mal uso de los salones.
Finalmente este capı́tulo propone dos modelos matemáticos que permiten resolver respec-
tivamente una versión simplificada y una versión compleja del problema de planificación de
conferencias. La primera versión modela el problema como un problema de satisfacción de
restricciones, sin embargo, la falta de granularidad que provee puede determinar un proble-
ma como infactible incluso cuando la solución está a muy poco de ser factible. La segunda
versión permite definir en detalle el programa de cada sesión. Esto aumenta su espacio de
búsqueda considerablemente y aumenta la cantidad de soluciones factibles para un proble-
ma cualquiera. Ası́, es posible observar que las soluciones del modelo simplificado son un
subconjuto de soluciones del modelo extendido. Ss ⊆ Se
La decisión de que modelo utilizar dependerá de las restricciones de la conferencia en la que

se esté pensando, ya que a menor cantidad de restricciones el modelo simplificado entre-
gará una solución que mantenga a cada uno de los expositores en una única sesión. Por otro
lado, la versión extendida permite encontrar soluciones cuando las instancias son considera-
blemente más complejas y en las que se necesita sacrificar la comodidad de los expositores
en pro de la conferencia.
CAPÍTULO
MARCO CONCEPTUAL
Planificar una conferencia siempre ha sido tema de estudio, donde la solución natural, y por
ende, la primera y ampliamente utilizada hasta el dı́a de hoy consiste en reunir un grupo de
trabajo que con pizarra y papel en mano comienza a organizar y distribuir charlas a lo largo
de bloques de tiempo. En sus inicios, a falta de videoconferencias, los organizadores debı́an
reunirse presencialmente en algún paı́s anfitrión a realizar una apropiada programación del
evento [Dos+17]. Este enfoque puede resultar para conferencias pequeñas, donde la capa-
cidad humana aún puede entregar buenos resultados en un tiempo razonable, sin embargo
el tiempo se ha encargado de moverse a conferencias de niveles colosales de las cuales la
planificación terminaba por resultar en un gran dolor de cabeza.
3.1. Estudios previos
Conference Scheduling Problem (CoSP) es un problema sumamente particular de una gran

familia de problemas, los problemas de scheduling o planificación, que incluyen tanto asig-
nación de tareas como de recursos.
El trabajo de [Jan+15] ofrece un vasto estudio de los problemas de planificación de tareas

con ventanas de vencimiento. Estos problemas en términos generales consisten en un con-
junto de tareas, donde cada una de ellas tiene un periodo de tiempo para el cual debe estar
completada. Si la tarea es terminada antes o después incurre en penalizaciones bien por an-
ticipación o tardanza. El trabajo se encarga de mostrar distintas definiciones del problema y
30
CAPÍTULO 3. MARCO CONCEPTUAL 31
las clasifica en dos categorı́as. La primera categorı́a considera los problemas donde la ven-
tana de vencimiento es entregada desde un comienzo mientras que la segunda categorı́a
considera los problemas donde se debe asignar dichas ventanas (principalmente asignar el
inicio de la ventana de vencimiento). El autor además provee un completo estudio sobre las
soluciones de cada una de las variantes encontradas. Estas van desde el uso de algoritmos
personalizados, el uso de heurı́sticas e incluso técnicas completas como Branch & Bound
(B&B).
Dentro de la misma familia de problemas de planificación es posible encontrar la familia de

Educational Timetabling. Esta familia está formada por un conjunto de problemas asocia-
dos a la planificación de tareas académicas, ya sea horarios de clases, exámenes, reuniones,
presentaciones, sesiones de estudio, entre otros.
Dentro del Educational Timetabling el trabajo de [Sch99] entrega un vasto estudio sobre la
planificación de clases y exámenes en un perı́odo fijo de tiempo, por ejemplo semanas. El
problema considera un conjunto dado de alumnos, cursos, docentes e instalaciones en que
se necesita elegir la mejor planificación para realizar clases y/o exámenes. Dicha programa-
ción debe evitar, entre otras restricciones, que una persona deba estar en dos lugares a la
vez.
El estudio presenta además un resumen de las variantes más comunes del problema, nor-
malmente por temas de instalaciones o por situaciones que generalmente suceden en la
práctica. Por mencionar algunas se tienen las clases simultaneas (e.g. dos clases deben pla-
nificarse en un mismo salón), múltiples profesores (e.g. cuando un curso tiene mas de un
profesor asignado), salones especiales (e.g. clases en laboratorios), entre otros. Finalmente
el artı́culo indica que las soluciones mas comunes encontradas en la literatura hacen uso de
heurı́sticas directas como Simulated Annealing (SA), Búsqueda Tabú, Algoritmos Genéticos,
entre otros acercamientos de búsqueda heurı́stica.
Por otro lado, este trabajo además presenta los tres principales problemas del área de Educa-
tional Timetabling. Primero School Timetabling, que es la planificación de clases escolares,
es decir, normalmente considera grupos de alumnos, evitando que los profesores y alumnos
tengan más de una clase programada al mismo tiempo. Es importante notar que, en la épo-
ca escolar, las clases son normalmente compartidas por un grupo de alumnos y por ende la
planificación se hace para una clase completa y no para alumnos independientes. Existen de
todas formas excepciones a esto último, por ejemplo, las clases de educación fı́sica donde
dos clases tienen la misma materia a la vez. El segundo es el Course Timetabling, que es la
planificación de las clases de cursos universitarios evitando la programación en un mismo
horario de clases con alumnos en común. La programación de cursos universitarios conside-
ra cada alumno como un elemento particular del problema y no existe un sı́mil a las “clases”
del School Timetabling. Por último, el Examination Timetabling que particulariza la planifi-
cación de exámenes universitarios. En este problema se busca entre otras cosas, minimizar el
traslape de estudiantes extendiendo, en lo posible, el tiempo entre exámenes (i.e. no dejar
exámenes consecutivos) o bien requisitos especiales como lo serı́an el planificar exámenes
en salones contiguos.
Para el Examination Timetabling el estudio de [Qu+09] presenta una detallada definición

del problema acompañado de una investigación sobre la literatura acerca de los estudios
relevantes y las nuevas tendencias para la resolución del problema. El estudio entrega deta-
lles sobre las restricciones duras, restricciones blandas y objetivos comunes. A continuación
se presentan dos tablas, la Tabla 3.1 muestra las dos restricciones duras clásica presentes
en cualquier Examination Timetabling, que son la asignación de recursos y la suficiencia de
recursos para llevar a cabo la planificación. La Tabla 3.2 muestra las restricciones blandas
más comunes consideradas en este tipo de problemas. Considera, por ejemplo, exámenes
consecutivos, exámenes contiguos o precedencia entre exámenes.
El hecho de enumerarlas no es por que sean de interés particular para el problema estudiado
en este trabajo de tı́tulo, sino mas bien, debido a que todas son extensibles para la mayorı́a
de los problemas de planificación y, de hecho, cambiando los eventos exámenes por expo-
siciones de artı́culos en las restricciones es posible conformar fácilmente un problema de
planificación de conferencias.
Restricciones duras
1 Sin exámenes con recursos en común (estudiantes, salas) asignados simultánea-
mente
2 El número de estudiantes asignados a un salón necesita estar bajo la capacidad del
salón, y debe haber suficientes salones para todos los exámenes
Tabla 3.1: Restricciones duras comunes para el Examination Timetabling

Fuente: Traducción del artı́culo de [Qu+09]
A pesar de la posibilidad sencilla de generalizar el concepto de conferencia y su definición co-

mo problema de optimización, la literatura del CoSP no presenta instancias estándar como sı́
se proveen para problemas más estudiados como serı́a el por ejemplo el Course Timetabling.
La literatura del CoSP normalmente resuelve conferencias particulares.
En [Van+18] se lleva a cabo un estudio que entrega un amplio análisis de la literatura de la

planificación de conferencias. En su estudio Vangerven identifica dos enfoques diferencia-
dos para el problema de planificación de conferencias, del tipo presenter-based perspective
(PBP) donde uno de los enfoques busca planificar artı́culos en sesiones de un mismo tema
y evitar que las mismas sesiones de un mismo tema se lleven a cabo en paralelo. Y por otro
lado están las attender-based perspective (ABP) que buscan planificar la conferencia maximi-
zando la felicidad de los asistentes con respecto al evento, dicha conformidad puede medirse
tanto como por el buen uso del espacio ([Van+18]), la cantidad de charlas de interés a las que
realmente lograrán asistir o bien cuanto deberán moverse para asistir a todo lo que desean.
En palabras simples se espera que atiendan a la mayor cantidad de exposiciones de interés
de la forma mas cómoda posible.
En su estudio [Van+18], el autor propone solucionar un problema ABP donde busca maximi-
Restricciones blandas
1 Distribuir los conflictos de exámenes en forma uniforme y no en bloques de tiempo
consecutivos
2 Grupos de exámenes que deban realizarse al mismo tiempo en el mismo dı́a o lugar
3 Exámenes que deban ser consecutivos
4 Planificar todos los exámenes, o los mas largos, tan pronto como sea posible
5 Se debe cumplir un orden o precedencia entre exámenes
6 Limitada cantidad de estudiantes y/o exámenes por bloques de tiempo
7 Requisitos de tiempo (e.g. exámenes que no puedan ser planificados en ciertos
bloques de tiempo)
8 Exámenes que tengan conflicto al panificares en el mismo dı́a en bloques cercanos
9 Exámenes pueden dividirse en ubicaciones similares
10 Solo se pueden asignar exámenes de misma duración en la misma sala
11 Recursos necesarios (e.g. instalaciones del salón)
Tabla 3.2: Restricciones blandas comunes para el Examination Timetabling

Fuente: Traducción del artı́culo de [Qu+09]
zar la asistencia de los asistentes y minimizar la cantidad de movimientos entre sesiones que
tengan que hacer. Por otro lado, el acercamiento presenter-based perspective (PBP) es muy
cercano a las conferencias GECCO que se consideran como caso de estudio de este trabajo
de tı́tulo, conferencia donde los temas son conocidos como tracks. Este estudio está fuerte-
mente relacionado con este trabajo de tı́tulo y será analizado en detalle en la Sección 3.3.
Existen otro tipo de alternativas para mejorar la experiencia de planificar una conferencia,
éstas son por ejemplo el entregar herramientas que faciliten la organización y visualización
del programa. Sticky Schedule [Dos+17] consiste en una aplicación de muchos usuarios que
permite la interacción y uso de múltiples pantallas compartidas a gran escala para tener una
visualización completa y granular del programa final. Este tipo de soluciones no resuelven el
problema como tal, pero contribuyen a que el proceso de planificación pueda realizarse por
un conjunto de personas de manera ordenada.
Cobi [Zha+13] consiste en una aplicación que facilita e involucra a la comunidad en el proceso
de planificación, ayudando a recolectar preferencias, restricciones y afinidades temáticas a
fin de contribuir de manera sistemática, visual e informada a la toma de decisiones sobre la
planificación. Nuevamente esta es una solución atı́pica, sin embargo, este tipo de aplicacio-
nes viene a resolver un problema distinto, que se asocia a su capacidad que se tiene para
recolectar información y saber como usarla.
Uist [Gri+16] busca mejorar la experiencia de los usuarios mediante aplicaciones que ayuden
a descubrir intereses, charlas y exposiciones mediante una plataforma web que permita a los
presentadores subir vı́deos cortos sobre sus futuras exposiciones. Uist finalmente se com-
porta como un sistema de recomendaciones que ayuda a visibilizar los temas y artı́culos de
una conferencia; este tipo de sistemas tampoco resuelve el problema como tal pero mejora
la experiencia del público al simplificar la etapa de descubrimiento, ya que probablemente
para el público en una conferencia de más de 100 artı́culos sea difı́cil leer cada uno de los
resúmenes.
PRESS [Lau+16] otra aplicación, consiste en un sistema recomendador personalizado para

cada usuario, donde este entrega sus preferencias directas sobre artı́culos o un conjunto de
palabras claves para determinar sus intereses interés; luego la aplicación utiliza modelos de
Maching Learning para determinar la planificación óptima de cada persona y sugerir artı́cu-
los interesantes.
3.2. Taxonomı́a del problema
Los problemas de planificación representan un conjunto de problemas que poseen ciertas

caracterı́sticas en común. Estas son normalmente la asignación de recursos, la asignación de
bloques de horario, la satisfacción de restricciones y un proceso de optimización acorde a
alguna función objetivo.
Las dos principales categorı́as de los problemas de planificación son el Timetabling Problem
y el Job Scheduling. Las cuales difieren principalmente por el uso de un espacio fı́sico en
tiempos particulares.
Sin embargo bajo ciertas interpretaciones se pueden encontrar muchas similitudes entre
ambos. Por ejemplo el problema de asignación de tareas con muchos procesadores puede
ser visto como un problema de asignación de eventos en salones paralelos, incluso mas aún,
el problema de planificación de conferencias basadas en temas (tracks) puede ser visto como
una planificación de tareas con precedencia donde una sesión debe ir antes que otra, y no
puede ejecutarse la siguiente hasta que la anterior esté completa.
La variante de problema de planificación estudiada en este trabajo de tı́tulo cae dentro de los
Timetabling. Dentro de los problemas basados en planificación de eventos, y más particu-
larmente en los de ı́ndole académica. Los problemas basados en eventos pueden considerar
desde reuniones, campeonatos [SMK04], exhibiciones[LL10] y horarios de buses [Zha+21].
Poco esfuerzo se ha hecho por crear una taxonomı́a por el problema, sin embargo esto pro-
bablemente es debido a la cantidad exponencial de variantes que pueden nacer según las
restricciones particulares de cada problema, sin mencionar que muchas variantes, según la
interpretación, pueden traslapar a otras categorı́as. A continuación se entrega un esfuerzo

por dar una taxonomı́a sencilla al problema. La taxonomı́a pone al problema de estudio bajo
la categorı́a de los problemas basados en eventos, luego para los que es necesario entregar
un programa (problemas de Timetabling), particularmente en la sección de planificación de
conferencias, enfocado principalmente en la perspectiva de los presentadores y finalmente
dentro de los problemas que deben dividir las sesiones temáticamente.
1 Problemas de Planificación
2 Eventos
3 Timetabling
4 Examination Timetabling
5 Course Timetabling
6 School Timetabling
7 Conference Timetabling
8 attender-based perspective (ABP)
9 presenter-based perspective (PBP)
10 Basadas en temas/tracks
11 GECCO ;
12 EURO-K ;
13 Tareas / Trabajos
14 Flow Shop Problem
15 Planificación de Procesos
16 Planificación de viajes
17 ...
3.3. Estudios relevantes
Basado en preferencias
Las conferencias basadas en preferencias (ABP del artı́culo [Van+18] referenciado en la sec-
ción previa) buscan, como su nombre lo indica, satisfacer en mayor parte las necesidades y
preferencias de los asistentes antes que de los presentadores.
El problema particular que busca resolver [Van+18], es una planificación ABP de sesiones
de una conferencia a fin de maximizar la asistencia del público. Esto se logra considerando
como primer objetivo planificar los artı́culos de forma que cada persona del público pueda
asistir a la presentación de la mayor cantidad de artı́culos de interés. Como segundo objetivo
se busca minimizar la cantidad de “movimientos entre sesiones” que puedan existir. Estos
movimientos entre sesiones se producen cuando alguna persona del público debe salir de
Figura 3.1: Clustering

Fuente: Google Images
una sesión a fin de asistir a otra que se esté exponiendo en paralelo.
[Van+18] con estos objetivos resuelve la planificación de tres conferencias distintas (MathS-
port, MAPSP y ORBEL). El autor propone una solución basada en un algoritmo de dos etapas
que incluyen el uso de programación lineal y heurı́sticas.
La primera etapa (modelo lineal) se encarga de construir las “tuplas” de artı́culos en paralelo
a fin de minimizar la inasistencia. Esto se hace con un vector de preferencias de cada persona
del público minimizando los costos asociados a la inasistencia. Como resultado de esta etapa
se obtienen N vectores de artı́culos que serán expuestos en paralelo. Como ejemplo en la
Figura 3.2 se tiene una conferencia de 12 artı́culos en la que se determinaron 3 tuplas. El
resultado indica que, por ejemplo, exponer los artı́culos (2), (11), (1) y (6) en paralelo generan
la menor inasistencia total para cada una de las personas del público.
La segunda etapa (heurı́stica) busca de forma unidimensional la planificación de cada uno

de los N vectores de artı́culos anteriores en un programa final a fin de minimizar los saltos
2 11 1 6
5 7 3 8
4 12 9 10
Figura 3.2: Asignación de 3 tuplas de artı́culos para un problema ABP de una conferencia de
12 artı́culos y 4 sesiones paralelas.
entre sesiones. La heurı́stica corresponde a un método de búsqueda local que permite co-
mo movimientos el intercambio entre sesiones (Figura 3.3) o el intercambio entre artı́culos
dentro de una misma sesión (Figura 3.4).
2 11 1 6 5 7 3 8
5 7 3 8 2 11 1 6
4 12 9 10 4 12 9 10
Figura 3.3: Intercambio entre sesiones para un problema ABP

2 11 1 6 2 6 1 11
5 7 3 8 5 7 3 8
4 12 9 10 4 12 9 10
Figura 3.4: Intercambio de artı́culos de una misma sesión para un problema ABP
El artı́culo de [Van+18] presenta como la instancia más compleja tratada las conferencias
ORBEL, con 4 sesiones paralelas y un aproximado de 80 artı́culos totales. En este caso, los
resultados obtenidos por su propuesta alcanzan tiempos de cómputo del orden del minuto
como máximo.
El trabajo de [Sam04] ofrece un extenso estudio de la planificación basada en preferencias,

tomando en cuenta estrategias de decisión tales como la flexibilidad horaria, preferencias

por presentadores, charlas, sesiones, bloques, adyacencia espacial y temporal. En el mismo
trabajo se define las caracterı́sticas y decisiones que se deben tomar al planificar una con-
ferencia. La primera caracterı́stica consiste en determinar la flexibilidad de la planificación,
es decir, qué tan redundante puede ser la conferencia respecto a sesiones o presentaciones
repetidas, la cantidad de sesiones o bien la cantidad de horarios disponibles. La segunda ca-
racterı́stica se relaciona con la definición de tipos de preferencias, donde se determina por
mencionar algunas, las preferencias sobre horarios, composición interna de sesiones o bien
adyacencia espacial. El problema descrito en particular fue el estudio de la conferencia An-
nual Meeting of the Decision Sciences Institute. Caso de estudio de 213 sesiones, 10 bloques
de tiempos disponibles y las preferencias de 520 personas. El algoritmo utilizado para el es-
tudio fue Simulated Annealing (SA) con un tiempo estimado de 40[min] para la resolución
del problema con las dimensiones antes mencionadas.
Basado en Tracks y similares
El objeto de estudio de este documento consiste en entregar una mejor experiencia para los
presentadores confeccionando una planificación categorizada en áreas para los asistentes.
En [SPV18] los autores plantean el problema de planificación de las conferencias EURO-K 1

la cual es una de las conferencias mas grandes del mundo, y dentro del estudio de la litera-
tura la más grande encontrada. La que se presenta en el artı́culo fue la planificación de la
EURO-K 2016 que contó con cerca de 2000 participantes, aproximadamente 2000 artı́culos
a ser expuestos, con un total de 463 sesiones a lo largo de 25 áreas de estudio Se pueden
considerar las áreas de estudio como sı́miles de la definición de tracks en este estudio. En
comparación con cualquier otra conferencia las EURO-K han sido de proporciones masivas.
Las EURO-K siguen una planificación PBP, y al igual que las GECCO buscan ser planificadas
según la temática de los artı́culos. El problema de las EURO-K ([SPV18]) considera la planifica-
ción final factible que permita satisfacer múltiples necesidades y objetivos sobre un conjunto
de artı́culos, edificios, salones, horarios y personas.
Para resolver el problema, primero los organizadores de un área en particular (track), gene-
ran de antemano cada una de las sesiones y planificación interna de ellas, es decir, deter-
minan el orden de los artı́culos de cada sesión. Los organizadores crean grupos de sesiones
(dentro del artı́culo llamados streams) que deben ser planificadas en secuencia en un mis-
mo salón e idealmente no deben ser interrumpidos. Por último se presenta un conjunto de
instalaciones donde cada una tiene su respectivo listado de salones.
Ası́, la mayor parte de la planificación “micro” se lleva a cabo por los organizadores y no por
la propuesta de solución. La propuesta que utilizan es un modelo de programación lineal
entera que busca satisfacer y minimizar lexicográficamente, según el siguiente listado, las
1
https://www.euro-online.org/web/pages/312/euro-k-conferences
siguientes necesidades:
1. Todas las sesiones de una área de estudio (track) deben ser planificadas en un único
edificio. Esto de forma de concentrar la atención del público interesado.
2. Correlación entre las áreas de estudio según la contigüidad de los edificios, es decir,
que áreas de estudio similares se encuentren cercanas las unas de las otras.
3. Minimizar la cantidad de salones a utilizar después de planificar cada uno de los streams.
Esto a fin de facilitar la navegación del público.
4. Minimizar la cantidad de “interrupciones” de un stream. Un stream como se mencionó

son sesiones de una misma área que se presentan consecutivamente, y su interrupción
(e.g. bloque libre) puede llevar a que el público se retire.
5. Finalmente se busca minimizar el mal uso del espacio, es decir, que los salones donde
se planifican las sesiones tengan la suficiente cantidad de asientos para un número
estimado de asistentes.
El modelo anterior se puede dividir fácilmente en pequeños problemas, donde por ejemplo
el tercer objetivo puede ser resuelto independientemente para cada uno de los edificios. Las
pruebas del acercamiento demostraron que solo tarda unas cuantas horas en entregar una
solución que, además, cumple considerablemente con cada uno de los objetivos descritos.
En [CVC19] los autores estudiaron un problema similar al abordado en este trabajo de tı́tulo.
El problema estudiado fue la International Conference on Production Research 2018 para
la que se generaron instancias similares que tenı́an entre 120 y 240 artı́culos o charlas a pre-
sentar. A diferencia de este trabajo (y de las EURO-K), este tipo de conferencias no tiene un
sı́mil de lo que se denomina un track, si no más bien uno de los objetivos del problema es
agrupar artı́culos similares y crear sesiones con artı́culos comunes. La definición es principal-
mente un modelo de programación lineal y su resolución se llevo a cabo mediante técnicas
heurı́sticas basadas en GRASP y generación de columnas. Para cada una de las instancias se
entregó un lı́mite de tiempo de 1[hr] para los solver matemáticos (Gurobi). Por otro lado la
propuesta heurı́sticas lograba alcanzar su soluciones en menos de 1[min].
Aun por el lado de las PBP, pero en otra área se tiene el trabajo de [VMF17] el cual busca
agrupar (clustering) artı́culos dentro de sesiones según su contenido considerando restric-
ciones adicionales a la agrupación. En este artı́culo se proponen dos nuevas modificaciones
a algoritmos de agrupación uno mediante un modelo de programación lineal y otro a partir
de una modificación del algoritmo K-Medoids. El artı́culo trabaja sobre las planificaciones
de las conferencias 13th International Conference on Machine Learning and Applications,
ICMLA-14 y 27th y 28th Conference on Artificial Intelligence of Association for the Advan-
cement of Artificial Intelligence, AAAI-13, AAI-14 que, a diferencia de las GECCO, no tienen
tracks definidos. El autor incluso indica que en este tipo de conferencias la variedad de temas
es considerablemente alta. La solución implica el uso de técnicas como el procesamiento del

lenguaje natural seguido de los algoritmos de agrupamiento. Los resultados reportados es-
tuvieron al nivel de las instancias reales y además todos se obtuvieron en tiempos acotados
de unos cuantos milisegundos.
En [BCS21] se busca formular una versión del problema que considere tanto la perspectiva de
los organizadores como la de los participantes y presentadores. Su definición busca entonces
planificar artı́culos con tópicos similares en sesiones comunes. Los organizadores por un lado
ven su trabajo simplificado debido a que no se necesita mayor recolección de datos y los
participantes se ven beneficiados debido a que las sesiones tendrán artı́culos similares y,
probablemente, de interés para el que asista. Desde la perspectiva del expositor se prohı́be
que éste tenga dos artı́culos en sesiones paralelas. El problema estudiado es una versión
bastante relajada del problema de planificación de conferencias en general y el mismo autor
la define como flexible.
El estudio presenta como solución tres modelos matemáticos. El primero un modelo de pro-
gramación lineal que permite resolver instancias pequeñas y medianas. El segundo que mo-
dela el problema como uno de agrupamiento que resuelve mediante técnicas de Branch &
Cut instancias más grandes que el primero. El tercer modelo de agrupamiento con Set Parti-
tioning resuelto mediante Branch Cut & Price resulta la propuesta más efectiva resolviendo
las instancias más grandes. Las instancias utilizadas fueron instancias reales y artificiales deri-
vadas de las conferencias XV Latin American Robotics Symposium (LARS) y la Brazilian Logic
Conference (EBL) que involucran 86 y 96 artı́culos respectivamente. Para los tres modelos
un lı́mite de tiempo de 12[hrs] fue establecido donde los dos primeros modelos para las ins-
tancias artificiales más grandes no alcanzaron siquiera a resolver la relajación del problema,
mientras que el último modelo tuvo un desempeño mucho mejor llegando como máximo a
las 5[hrs] de tiempo de cómputo en los casos más complejos.
3.4. Resumen
A lo largo de este capı́tulo se presentó un estudio del estado del arte del problema. Este
estado del arte incluye una gran cantidad de problemas cercanos como lo serı́an los Job
Scheduling, variantes y problemas de planificación de eventos y los de Educatonal Timeta-
bling.
Para este último se presentan sus principales variantes School Timetabling, Course Timeta-
bling y Examination Timetabling. Problemas que, si bien en un principio no están relaciona-
das por completo al problema que se resuelve en este trabajo, proveen mucha información
respecto a tipos de restricciones y objetivos que podrı́an extenderse a cualquier problema
de planificación.
Se observa también que existe una tendencia no menor al desarrollo de aplicaciones para
usuarios a fin de facilitar ya sea el trabajo de los organizadores o el nivel de información

que maneja el público antes de asistir a alguna conferencia. Esto muestra un cierto grado
de resistencia contra los sistemas automatizados y que aun gran parte de la planificación se
lleva por decisiones completamente humanas.
Se presenta también un intento por determinar la taxonomı́a del problema, donde cierta-
mente su desarrollo es complejo y probablemente no esté del todo correcto. Esto debido
que, como se mencionó antes, ciertos problemas pueden catalogarse al mismo tiempo en
dos categorı́as distintas.
Finalmente se presenta un estudio detallado de las dos variantes mas significativas del pro-
blema; attender-based perspective (ABP) y presenter-based perspective (PBP). Se explican en
detalle los dos artı́culos más importantes encontrados en la literatura. El estudio de [Van+18]
con la resolución de un problema ABP y el estudio de [SPV18] con la resolución de un proble-
ma PBP. Esta última es la mas cercana a este trabajo y uno de los pocos artı́culos que define
en concepto tracks en el problema de planificación de conferencias.
CAPÍTULO
PROPUESTA DE SOLUCIÓN
La solución propuesta en este documento puede considerarse una propuesta en dos fases
que busca soluciones de calidad permitiendo que el algoritmo recorra zonas infactibles del
espacio de búsqueda. En la primera fase se utiliza una construcción inicial greedy aleatoria
que puede resultar en soluciones infactibles. Y en la segunda fase, se utiliza un algoritmo de
búsqueda local Simulated Annealing con recalentamiento.
4.1. Construcción inicial de sesiones
La primera etapa del algoritmo parte con un conjunto total de artı́culos A, agrupados úni-
camente por el track al que pertenecen. Dado los requisitos del problema, la primera fase
debe determinar para cada uno de los tracks la cantidad mı́nima de sesiones necesarias para
programar cada uno de sus artı́culos. Por ejemplo, considerando una conferencia cualquiera
que tiene 100 artı́culos, que permite cuatro artı́culos por sesión y donde un trackarbitrario
tiene 14 artı́culos, es posible calcular la cantidad de sesiones para ese track como 14

4
→ 4.
El mismo procedimiento debe aplicarse a cada uno de los tracks para obtener ası́ la canti-
dad total de sesiones a programar para la conferencia. Una vez obtenidas éstas cantidades
se consideran dos alternativas de construcción de sesiones: un algoritmo de construcción
aleatorio y un algoritmo de construcción greedy.
42
CAPÍTULO 4. PROPUESTA DE SOLUCIÓN 43
4.1.1. Construcción inicial aleatoria
El primer algoritmo de construcción (Algoritmo 1) consiste en desconocer cualquier conflic-

to que pueda existir entre artı́culos y bloques horarios y asigna artı́culos a cada una de las
sesiones arbitrariamente, únicamente respetando que los artı́culos estén en sesiones de sus
correspondientes tracks. Luego, para completar las sesiones, selecciona aleatoriamente un
chair y un organizador para la sesión. Esta opción asegura únicamente cumplir con que los
artı́culos estarán dentro de sesiones de un mismo track, y por ende no asegura el cumpli-
miento de ninguna otra restricción.
1 for track : tracks do

2 articles = track.articles;
3 for session : track.sessions do
4 s articles = pop random from articles ;
5 session.articles = s article ;
6 session.chair = random chair ;
7 session.organizer = random organizer ;
Algoritmo 1: Construcción aleatoria de artı́culos en sesiones.
4.1.2. Construcción inicial Greedy
El segundo algoritmo de construcción toma, para cada track, su listado de artı́culos, bara-
jados en orden aleatorio y se van asignando artı́culos a sesiones siguiendo los siguientes
pasos:
1. Se toma un artı́culo cualquiera y se busca la sesión con menos conflictos de tiempo.

Para determinar la cantidad de conflictos en una sesión se debe considerar el artı́culo
a insertar y los artı́culos ya presentes en la sesión. Suponiendo que el costo de insertar
un artı́culo cualquiera y en la sesión i, viene dado por Zi (y) para la cual el vector ~xj
representa un vector de conflictos binarios para el j-ésimo artı́culo dentro de la sesión
i, mientras que ~y es el vector de conflictos para el artı́culo a insertar.
X
Zi (y) = ~xj · ~y
j
2. El cálculo anterior solo es valido si es que los conflictos totales no abarcan todos los
bloques disponibles. En caso de que el artı́culo no pueda encontrar una sesión que
satisfaga lo mı́nimo, será planificado en la primera sesión con suficiente espacio.
En el Algoritmo 2, especı́ficamente en la Lı́nea 11, se determina el cálculo de una función

de costo. Esta función se detalla más adelante en el Algoritmo 3, pero por el momento se
1 for track: tracks do

2 for article: track.articles do
3 if article is best paper? then
4 track.sessions[0].add(article) ;
5 for article: track.articles do
6 if article is not best paper? then
7 best = INF ;
8 best session = NULL ;
9 for session: track.sessions do
10 if article fits in session then
11 cost = (number of block conflicts if article is scheduled there) ;
12 if cost<best then
13 best = cost ;
14 best session = session ;
15 if best = INF then

16 best-session = choose random empty session from (track) ;
17 best session.add(article) ;
18 for session : track.sessions do
19 session.chair = random chair ;
20 session.organizer = random organizer ;
Algoritmo 2: Asignación de artı́culos a sesiones mediante un criterio de construcción

greedy
puede decir que los conflictos de tiempo no son inherentes de los artı́culos, sino mas bien
son heredados del expositor que debe presentar dicho artı́culo.
De manera intuitiva se puede pensar que los casos más complejos de resolver sean aque-
llos con pocas sino únicas soluciones, por ende, la asignación de artı́culos en sesiones serı́a
igualmente única. Dicho esto se puede dar aproximar el tamaño de espacio de búsqueda y
complejidad si se intentase resolver el problema solo por estos medios. En este caso para ca-
da track se tendrı́a que resolver un problema de asignación O(|artı́culos|), donde |artı́culos|
representa la cantidad de artı́culos de dicho track.
A pesar de que es posible repetir varias veces la etapa de la construcción inicial o incluso ex-
tenderla con otros algoritmos greedy mas sofisticados, pruebas preliminares determinaron
que ejecutar mas una vez la construcción inicial (tanto aleatoria como greedy) no generaba
mejores resultados en la siguiente fase, y por ende el proceso repetitivo no aportaba valor
en el proceso, por lo que finalmente se determinó que una vez era suficiente.
4.2. Simulated Annealing
En este trabajo de tı́tulo se propone un algoritmo de búsqueda local iterativa estocástica muy
utilizado en el ámbito de la optimización combinatoria. Simulated annealing es un algoritmo
muy general que con reglas sencillas permite explotar y diversificar según la etapa del pro-
ceso de búsqueda del algoritmo. La propuesta consiste en llevar a cabo simulated annealing
con enfriamiento proporcional, recalentamientos periódicos, mecanismos de detección de
estancamiento, temperaturas iniciales de acorde a la calidad y mecanismos de castigo para
soluciones infactibles.
Este capı́tulo comienza describiendo la representación del problema, donde se muestra un

ejemplo de solución para el algoritmo ilustrado con un ejemplo. Se presenta también el cálcu-
lo de la función de evaluación, donde se justifican las penalizaciones, se indica el espacio de
exploración permitido y de que manera se permite el movimiento sobre dicho espacio. Ası́
también se presenta el algoritmo como tal y su comportamiento esperado, donde se expli-
can las bases de SA y se asocia con el problema real. Se presentan los cuatro movimientos
permitidos para la búsqueda local, que son el intercambio de sesiones, el intercambio de
chairs u organizadores y el intercambio de artı́culos. Por último, se presentan los paráme-
tros especı́ficos del problema, como las tasas de enfriamiento, recalentamiento, número de
iteraciones, entre otros. El capı́tulo finaliza con un resumen y conclusiones de la propuesta.
4.2.1. Representación
La representación a utilizar en esta etapa será la grilla general del programa de tamaño Ha-
bitaciones × Bloques. Donde cada celda de la grilla estará utilizada por cero o una sesión de
las construidas en la etapa de construcción descrita en la sección 4.1.
La Figura 4.1 muestra un ejemplo de representación de solución. La grilla fue poblada con el
proceso de construcción como se explica a continuación. El criterio para poblar la grilla es
ir secuencialmente por cada track asignando de izquierda a derecha, asignando por salón
cada una de las sesiones. Observando el ejemplo de la Figura 4.1 en que se tiene una grilla
de 5 tracks, donde se elige aleatoriamente cada track y se planifican sus sesiones. Primero se
considera el track celeste que tiene cuatro sesiones y se planifica en la misma sala en bloques
consecutivos la mayor cantidad de sesiones posible. Luego se considera el track amarillo que
posee cuatro sesiones. Su primera sesión queda planificado en el primer horario disponible y
se continúan asignando con el siguiente salón desde el primer bloque horario nuevamente.
La misma lógica se aplica tanto para los tracks morado, rojo y verde. La figura muestra un
ejemplo básico y los bloques horarios podrı́an ser los de un mismo dı́a o estar divididos en
varios dı́as.
A pesar de que ésta asignación permite comenzar el proceso de búsqueda con un buen pro-
grama, esta construcción inicial no revisa el cumplimiento de las restricciones de conflictos
con bloques de horario ası́ como tampoco la asignación de una persona en mas de una se-
sión en paralelo. Por otro lado, tampoco considera el objetivo de minimización del mal uso
del espacio.
1 2 3 4 5
6 7 8 9 10
11 12 13 14 15
Figura 4.1: Programa construido mediante asignación secuencial izquierda-derecha arriba-

abajo (los números representan el orden de inserción en la grilla)
4.2.2. Función de evaluación
La propuesta en este documento corresponde principalmente a la resolución de un proble-

ma de satisfacción de restricciones que, además, busca minimizar la falta de espacio acorde
a la asistencia histórica. Dicho eso se puede definir la función de evaluación como la fal-
ta de espacio que se obtiene al planificar las sesiones en celdas en particular, sumado a la
cantidad de restricciones duras insatisfechas ponderadas por un factor (γ > 1) tal que el
algoritmo priorice minimizar dichos conflictos. Además, si se utiliza un valor de γ suficiente-

mente grande se puede determinar intuitivamente cuando la solución es factible y cuantas
restricciones duras se están violando. Esto es debido a los órdenes de magnitud de las pena-
lizaciones. Igualmente habrán restricciones duras más penalizadas que otras, por ejemplo la
asignación de organizadores representan un conflicto en bloque y debiesen ser penalizadas
proporcionalmente al tamaño del bloque, es decir, amplificadas por un factor nAS (número
de artı́culos por sesión).
El Algoritmo 3 muestra el proceso de cálculo de función de evaluación implementado. Los

castigos asociados se pueden resumir como:
Lı́neas 4, 6 y 9: Penalizar la presencia de una persona en bloques de tiempo en los

cuales no puede estar presente. Amplificado por ser una restricción dura y a nivel de
bloque (+1 ∗ nAS ∗ γ).
Lı́neas 12 y 14: Penalizar la programación de dos sesiones de en un mismo bloque que

compartan chair u organizador. Amplificado por ser una restricción dura y a nivel de
bloque (+1 ∗ nAS ∗ γ).
Lı́nea 16: Penalizar la presencia de dos sesiones en un mismo bloque de un mismo

track. Amplificado por ser una restricción dura y a nivel de bloque (+1 ∗ nAS ∗ γ).
Lı́neas 19, 20, 24 y 26: Penalizar la presencia del presentador de un artı́culo como chair
u organizador en otra sesión y viceversa. Amplificado por ser una restricción dura y a
nivel de bloque (1 ∗ nAS ∗ γ).
Lı́nea 28: Penalizar que un expositor tenga dos artı́culos programados en el mismo
bloque y sub slot de tiempo.
Lı́nea 30: Penalizar la falta de espacio necesaria acorde a la asistencia histórica de cada
sesión respecto al track al que pertenece.
4.2.3. Estructura de la propuesta
El algoritmo propuesto corresponde a un algoritmo de búsqueda local basado en Simulated

Annealing. La idea es construir soluciones que cumplan las restricciones duras y permita mi-
nimizar la falta de espacio de acorde a la asistencia histórica. Se busca utilizar un proceso
iterativo reparador que principalmente busque soluciones factibles, mejore soluciones ac-
tuales y permita el desplazamiento por zonas infactibles del problema a fin de volver factible
el resultado. El Algoritmo 4 muestra el flujo que sigue cualquier algoritmo Simulated Annea-
ling con recalentamiento. Como solución inicial del SA, se toma la solución parcial construi-
da anteriormente por el algoritmo greedy y se planifica en el sentido de la escritura (véase
Figura 4.1). El algoritmo propuesto corresponde a un SA bastante estándar, con una única
input : Una solución S con grilla grid

output: Un escalar que representa el costo de la solución
1 cost = 0 ;
2 for column : grid do
3 for session1 : column do
4 if session1.chair cannot be there then
5 cost += nAS * γ
6 if session1.organizer cannot be there then
7 cost += nAS * γ
8 for article : session1.articles do
9 if article.author cannot be there then
10 cost += nAS * γ
11 for session2 : column do
12 if session1.chair = session2.chair then
13 cost += nAS * γ
14 if session1.organizer = session2.organizer then
15 cost += nAS * γ
16 if session1.track = session2.track then
17 cost += nAS * γ
18 for article1 : session1 do
19 if article1.author = session2.chair then
20 cost += nAS * γ
21 if article1.author = session2.organizer then
22 cost += nAS * γ
23 for article2 : session2 do
24 if session1.chair = article2.author then
25 cost += nAS * γ
26 if session1.organizer = article2.author then
27 cost += nAS * γ
28 if article1.author = article2.author then
29 cost += γ
30 cost += space cost of schedule session 1 there ;
31 return cost
Algoritmo 3: Función de evaluación con factor de amplificación γ y cantidad de artı́cu-
los por sesión nAS
diferencia en su diseño. La diferencia radica en que la cantidad en que aumenta la tempera-

tura en cada recalentamiento sigue un comportamiento lineal proporcional a la cantidad de
iteraciones y no uno proporcional a la temperatura previa. Ası́, se considera un aumento de
la temperatura en la iteración i + 1 como Ti+1 = Ti + β(iteraciones) con un factor β > 0 en
función de la cantidad de iteraciones. Y con el paso de las iteraciones estos recalentamientos
serán cada vez menos intensos. Esto se muestra en la Lı́nea 4 del Algoritmo 4.
1 Ti = temperatura inicial;
2 for i = 1 → N do
3 if χ iterations without improvement then
4 Ti+1 += β − (β − 1) · Ni
5 Sn = choose random from neighbour(S) ;
6 ∆ = quality(Sn ) - quality(S) ;
7 if ∆ < 0 then
8 S = Sn
9 else
10 if exp( −∆
T
) > rand(0, 1) then
11 S = Sn
12 Ti+1 = Ti ∗ α
Algoritmo 4: Flujo general de Simulated Annealing (SA) con enfriamiento proporcio-
nal y recalentamiento lineal proporcional al número de iteraciones.
4.2.4. Movimientos
Para el proceso de búsqueda local el algoritmo propuesto considera cuatro movimientos. A

continuación se explica en detalle cada uno de los movimientos implementados.
Intercambio de Sesiones
El propósito principal del intercambio de sesiones consiste en hacer un movimiento macro

de al solución actual a fin de explorar el espacio de soluciones lo mejor posible. El proce-
so consiste en tomar dos sesiones aleatorias de la grilla e intercambiarlas de posición. Este
movimiento es el de mayor diversificación ya que consiste en mover muchos artı́culos al mis-
mo tiempo y por ende es un movimiento con muchas posibilidades de volver infactible una
solución. Este movimiento puede volver infactible la solución por las siguientes razones:
1. Las nuevas posiciones pueden tener algún artı́culo, con algún expositor que tenga el
nuevo bloque como un horario no deseado (o imposible al que asistir).
2. Las nuevas posiciones podrı́an permitir que dos sesiones de un mismo track se plani-
fiquen en paralelo.
3. Las nuevas posiciones podrı́an crear nuevos conflictos tanto para chairs como con or-
ganizadores que ya estaban planificados en otras sesiones en el mismo horario.
La Figura 4.2 muestra un pequeño ejemplo donde dos sesiones arbitrarias de dos tracks dis-
tintos se intercambian de posición (las sesiones pueden ser de cualquier track y no se impide
ambas sean de un mismo track). Se acompaña del Algoritmo 5 que muestra detalladamente
el proceso de intercambio.
Todo estos cálculos son penalizados en la función de costos que se presenta en el Algoritmo 3.
De todas maneras, el movimiento provee una gran oportunidad para explorar el espacio
de búsqueda, e incluso preliminarmente se podrı́a esperar que este movimiento deberı́a
predominar en etapas tempranas del algoritmo, donde los movimientos macro destacan más
que los granulares.
Figura 4.2: Ilustración del intercambio de sesiones

1 Function swap sessions(S: solution) do

2 S1 , S2 = choose two random sessions from S;
3 swap position in grid(S1 , S2 )
Algoritmo 5: Intercambio de sesiones
Intercambio de chair
El intercambio de chairs se realiza a fin de encontrar una asignación de chairs suficientes para

cubrir todo un bloque horario (una columna dentro de la grilla). Gracias a que las columnas
son independientes basta con lograr, para cada columna, determinar la asignación de chairs
tal que no se traslapen.
Es necesario que este movimiento se realice durante todo el proceso de búsqueda, ya que
el intercambio de sesiones, organizadores y artı́culos puede, en efecto, volver infactible la
asignación de chairs. Para hacer el cambio se elige una sesión aleatoria, y un chair aleatorio
del track de la sesión en cuestión, véase Algoritmo 6.
1 Function swap chair(S: solution) do

2 session = choose random sesion from S ;
3 session.chair = choose random from (session.track.chairs) ;
Algoritmo 6: Intercambio de chairs
Intercambio de Organizadores
El intercambio de organizadores, tal como el intercambio de chairs, se lleva a cabo para po-
der encontrar una asignación de organizadores suficientes tal que no tengan mas de una
responsabilidad en un mismo bloque horario. Es necesario también que este movimiento se
realice a lo largo de todo el proceso de búsqueda, ya que el intercambio de sesiones, chairs
y artı́culos puede en efecto volver infactible la asignación. Para hacer el cambio se elige una
sesión aleatoria, y un organizador aleatorio del track correspondiente a la sesión en cuestión,
véase Algoritmo 7.
1 Function swap organizer(S: solution) do

2 session = choose random sesion from S ;
3 session.organizer = choose random from (session.track.organizers) ;
Algoritmo 7: Intercambio de Organizador
Intercambio de Artı́culos
El propósito del intercambio de artı́culos es generar movimientos granulares de la grilla prin-

cipal con respecto a la conformación de sesiones. Sin este movimiento las sesiones estarı́an
condicionadas a la construcción inicial y, por ende, podrı́an fácilmente estancar el proceso
de mejoras.
Para llevar a cabo este movimiento se eligen dos sesiones aleatorias de un mismo track, luego
desde cada sesión se elige aleatoriamente un artı́culo y finalmente se intercambian, véase Fi-
gura 4.3 y Algoritmo 8. Este intercambio permite respetar que cada artı́culo esté en sesiones
válidas respecto al track, sin embargo no asegura que alguno de los dos artı́culos hayan que-
dado en una posición inválida o bien en conflicto con algún chair u organizador. Este cambio
puede generar cualquier infactibilidad en la solución, tanto por horarios como conflictos con
chairs y organizadores que estén ya programados en alguna sesión paralela. Nuevamente
recordar que todas los ajustes infactibles son castigados por la función de evaluación según
el Algoritmo 3.
La Figura 4.3 muestra un ejemplo de como se realiza el intercambio entre artı́culos. En el

ejemplo se toman dos sesiones aleatorias del track azul, y de cada una de las sesiones se eli-
ge aleatoriamente un artı́culo a intercambiar. Las sesiones no tienen porqué estar contiguas
y pueden encontrarse en cualquier horario y salón, y la solución no tiene tampoco porqué
ser factible. De hecho en el mismo ejemplo se tiene que el track verde para el primer blo-
que horario tiene dos sesiones en paralelo, lo cual es infactible, y será reparado en futuras
mejoras con los otros movimientos.
3 10 13
7 14 21
Figura 4.3: Intercambio de artı́culos, se eligen dos sesiones de un mismo track y se intercam-
bian dos artı́culos aleatorios de cada uno
1 Function swap articles(S: solution) do

2 track = choose random track from S ;
3 s1 , s2 = choose two random sesion from (track) ;
4 a1 = choose random article from s1 ;
5 a2 = choose random article from s2 ;
6 swap positions(a1 , a2 ) ;
Algoritmo 8: Intercambio entre artı́culos
4.2.5. Parámetros
La versión utilizada de Simulated Annealing (SA) corresponde al algoritmo estándar con op-
ción de estancamiento y recalentado. A continuación se listan cada uno de los parámetros
definidos y en la Sección 5.5 del capı́tulo Experimentos se presenta el proceso de sintoniza-

ción de parámetros realizado en este trabajo de tı́tulo.
Parámetros propios de SA
Temperatura inicial: Valor inicial de la temperatura del algoritmo. Este valor normal-
mente debe elegirse teniendo en cuenta la magnitud que tengan la capacidad de los
salones, la asistencia histórica, y el factor de multiplicación. Esto debido a que lo ideal
es castigar en varios órdenes de magnitud a las soluciones infactibles, por ejemplo en
una conferencia con salones de capacidad 30 y un factor de multiplicación 1000 será
fácil discernir que una solución es factible o no. Por otro lado, para una conferencia
con capacidades para 200 personas por salón y utilizando un factor de multiplicación
500 para la función de evaluación, se podrı́a llegar a confundir una solución infactible
con una que hizo un mal uso del espacio.
Tasa de Enfriamiento α ∈ [0, 1]: Factor por el cual disminuye la temperatura en cada
iteración. Tt+1 = Tt ∗ α.
Iteraciones: N ∈ N Cantidad de iteraciones de SA que realizará el algoritmo, a su vez

indica la cantidad de veces que aplicará la tasa de enfriamiento.
Iteraciones para recalentar χ ∈ N: Número de iteraciones necesarias consecutivas

para que el algoritmo determine un óptimo local y, por ende, ejecute un recalenta-
miento.
Multiplicador al recalentar β ∈ N: Factor β ≥ 1 que determina en cuanto se aumen-

tará la temperatura al momento de recalentar Tt+1 = Tt + β − (β − 1) · ( iters
N
). Donde
el numerador iters representa la iteración actual en la que se encuentra el algoritmo.
Parámetros especı́ficos del problema El algoritmo desarrollado implementa cuatro movi-

mientos distintos para lograr explorar el espacio de búsqueda, y se necesita que en cada ite-
ración se elija cuál de todos utilizar. Para cada uno de los movimientos se define un parámetro
que controla su probabilidad de uso. Éstos se listan a continuación.
Multiplicador de infactibilidad : Factor γ por el cual penalizar los costos de las restric-
ciones duras insatisfechas en las soluciones.
P1 : Probabilidad de intercambiar dos sesiones de ubicación en la grilla completamente.
P2 : Probabilidad de intercambiar un chair de una sesión arbitraria de la grilla.
P3 : Probabilidad de intercambiar un organizador de una sesión arbitraria de la grilla.
P4 : Probabilidad de intercambiar dos artı́culos aleatorios.

4.3. Resumen
Este capı́tulo presenta una propuesta de algoritmo heurı́stico para resolver el Conference
Scheduling Problem (CoSP). Inicialmente se utiliza un algoritmo de construcción de sesio-
nes a fin de maximizar la factibilidad de las soluciones iniciales y ası́ evitar trabajo futuro.
En esta construcción se presentaron dos enfoques, uno completamente aleatorio y un enfo-
que greedy. Ninguna de las dos opciones asegura una factibilidad inicial, pero se espera que
simplifiquen el proceso de búsqueda local posterior.
El algoritmo implementa una función de costo en el Algoritmo 3, la cual permite hacer cálcu-
los eficientes, debido a que cada movimiento genera a lo mas diferencias de costos en máxi-
mo dos columnas de la grilla del programa. El método de búsqueda local sigue la estructura
de un Simulated Annealing estándar, con enfriamiento proporcional, recalentamientos recu-
rrentes lineales en proporción del número de iteraciones. Además, considera cuatro movi-
mientos especializados para el proceso de búsqueda en vecindarios: intercambio de sesio-
nes, el cambio de un chair, el cambio de un organizador y el intercambio de artı́culos.
CAPÍTULO
EXPERIMENTOS
En este capı́tulo se presentan los experimentos realizados para la validación de las estrategias
propuestas para resolver el problema de planificación de conferencias basadas en tracks.
Primero se presenta el formato que tienen las instancias de prueba propuestas. Se presenta
también un generador para crear instancias similares al tamaño de las GECCO. A continuación
se presentan las 45 instancias de pruebas utilizadas en este trabajo de tı́tulo. Posteriormente
se presenta un análisis dimensional de las instancias y se propone un indicador cualitativo de
análisis de complejidad. Finalmente se presenta el proceso de sintonización de parámetros
para la ejecución del algoritmo heurı́stico propuesto.
5.1. Formato de Instancias
Para los experimentos se trabajó con un formato de instancias que satisfacen las necesidades
de los modelos presentados en la Sección 2.6. En el repositorio1 de este trabajo pueden
encontrarse el conjunto de instancias de pruebas utilizadas.
La estructura general de las instancias entrega secuencialmente los siguientes datos:
Definición de las constantes principales como nA, nP, nB, nR, nT, nAS
1
https://github.com/keleron/memoria-conference-scheduling
55
CAPÍTULO 5. EXPERIMENTOS 56
Por cada artı́culo hay una tupla compuesta por el id, el track al que pertenece, la per-
sona que es expositor y si corresponde a un best paper.
Luego por cada persona hay tiene una tupla compuesta por el id, y una lista de bloques
para los cuales existe conflicto.
Luego por cada track hay una tupla compuesta por el id y la asistencia histórica.
Luego por cada salon hay una tupla compuesta por el id y la capacidad del salón.
Luego por cada track hay una tupla compuesta por el id y una lista de las personas que
son chairs de dicho track.
Luego por cada track hay una tupla compuesta por el id y una lista de las personas que
son organizadores de dicho track.
En el Texto 5.1 se muestra un ejemplo reducido de una instancia de prueba. En este ejemplo
cada lı́nea que comienza con un # indica únicamente un comentario y esas lı́neas son igno-
radas al momento de la lectura. Estas lı́neas sirven claramente para la claridad del formato
de las instancias.
Lı́nea 1: Las constantes de la estructura del problema, en el ejemplo tendrı́amos nA =

150, nP = 80, nB = 4, nR = 5, nT = 14 y nAS = 4 que representan, respecti-
vamente, la cantidad artı́culos, la cantidad de participantes, la cantidad de bloques, la
cantidad de salones, la cantidad de tracks y la cantidad de artı́culos por sesión permi-
tidos.
Para las siguientes lı́neas: El primer número de cada lı́nea corresponde al identificador
(ID) de la entidad en cuestión.
Lı́nea 3: Por cada uno de los artı́culos se especifica el track al que pertenece (con
t < nT ), un expositor que presenta el artı́culo en la conferencia (con p < nP ) y si
el artı́culo es un nominado a best paper o no ∈ (0, 1). En el ejemplo se tiene el artı́culo
0, perteneciente al track 3, presentado por la persona 28, y no está nominado a mejor
artı́culo. Luego, el artı́culo 1 perteneciente al track 7, presentado por la persona 23 y
está nominado a mejor artı́culo.
Lı́nea 8: Por cada persona se especifica un listado de bloques-conflicto en los que la

persona no puede estar presente en la conferencia. En el ejemplo se tiene que la per-
sona 0 tiene conflictos de horario en los bloques horarios 1 y 2. Luego, la persona 1
tiene conflictos en los bloques horarios 4, 3 y 6.
Lı́nea 13: Por cada track se indica la asistencia histórica. En el ejemplo se tiene el track
0 que, históricamente, tiene 30 asistentes por sesión y el track 1 que históricamente
tiene 10 asistentes por sesión.
1 # ARTICULOS HUMANOS TOTAL BLOQUES SALONES TRACKS ARTICULOS POR SESION

SESIONES POR DIA
2 150 80 4 5 14 4
3 # ARTICULO TRACK PRESENTADOR BEST - PAPER
4 0 3 28 0
5 1 7 23 1
6 ...
7 149 13 79 1
8 # PERSONA CONFLICTO ( CON TIEMPO )
9 0 1 2
10 1 4 3 6
11 ...
12 79 < bloque > < bloque > < bloque > ...
13 # TRACK ASISTENTES HISTORICOS
14 0 30
15 1 10
16 ...
17 13 < asistentes >
18 # SALON CAPACIDAD
19 0 10
20 1 20
21 ...
22 3 < capacidad >
23 # TRACK CHAIRS
24 0 13 14
25 1 37 28
26 ...
27 13 < chair > < chair > < chair > ...
28 # TRACK ORGANIZADORES
29 0 36 27 34
30 1 24 2
31 ...
32 13 < organizador > < organizador > < organizador > ...
Texto 5.1: Ejemplo de una instancia con 150 artı́culos, 80 personas, 4 salones, 5 bloques
horarios, 14 tracks y 4 artı́culos por sesión.
Lı́nea 18: Por cada salón se indica su capacidad. En el ejemplo se tiene que el salón 0
tiene capacidad para 10 personas, mientras que el salón 1 tiene capacidad para 20.
Lı́nea 23: Por cada track se indica el listado de chairs disponibles. En el ejemplo se tiene
que el track 0 tiene como chairs disponibles a las personas 13 y 14; y el track 1 tiene
como chairs disponibles a las personas 37 y 28.
Lı́nea 29: Por cada track se indica el listado de organizadores disponibles. En el ejemplo
se tiene que el track 0 tiene como organizadores disponibles a las personas 36, 27 y 34
y el track 1 tiene como organizadores disponibles a las personas 24 y 2.
5.2. Generador de Instancias
Para facilitar el desarrollo de este trabajo se creo un generador de instancias (disponible en el

repositorio) que pudiese crear instancias similares a las GECCO tanto en cantidad de artı́culos
como en la distribución espacio temporal.
El generador permite fijar la cantidad de artı́culos nA, la cantidad de personas nP , la can-

tidad de bloques de horario nB, la cantidad de salones nR, la cantidad de tracks nT , la
cantidad de artı́culos por sesión nAS y el porcentaje de conflictos temporales totales C.
El generador de instancias fue implementado en lenguaje de programación Python (3.9.5).

La implementación permite especificar todos los valores de la lı́nea 2 del Texto 5.1. El gene-
rador de instancias por defecto elige un número de tracks que poseen artı́culos nominados,
y asigna para cada uno de esos tracks aleatoriamente entre 3 y 4 artı́culos a nominar. Final-
mente para las nominaciones especiales, les asigna un único track artificial diferente a todos
los demás.
La capacidad histórica y la capacidad de los salones se genera aleatoriamente en similares

órdenes de magnitud; estos valores para mayor precisión se prefiere que sean ajustados a
mano, ya que esto dependerá del lugar en que se lleve a cabo la conferencia y por ende no
es un valor que repita muy seguido.
Por otro lado la cantidad de conflictos viene dada por un porcentaje que especifica que tan
llena estará la matriz total de conflictos, esto es, considerando absolutamente todos los con-
flictos de bloques posibles. Para una conferencia cualquiera, una persona puede tener como
máximo nB − 1 conflictos horarios, ya que si tiene más, toda la conferencia serı́a su conflic-
to. Ası́ el espacio o matriz de conflictos tiene un tamaño nP · (nB − 1) y de ese espacio se
tiene un parámetro del generador para elegir cuanto porcentaje de conflictos será en efecto
agregado a la instancia; luego de eso los conflictos se reparten aleatoriamente.
El Algoritmo 9 muestra el procedimiento macro realizado para generar las instancias. Las
primeras lı́neas se encargan de crear cada uno de los arreglos de las instancias de artı́culos,
personas, salones, bloques y tracks. Primero el ciclo de la Lı́nea 7 genera nA−4 artı́culos con
tracks distribuidos uniformemente. Luego el ciclo de la Lı́nea 13 crea los 4 artı́culos restantes
que representan los “mejores artı́culos” de tracks especiales. Los tracks que se mencionaron
podı́an nominar un solo artı́culo y además todos ellos deben estar en una misma sesión, esto
mas que nada es un truco práctico en el que se separan en un track único para ellos. Luego se
mezclan aleatoriamente los artı́culos y personas. El ciclo de la Lı́nea 19 se encarga de asignar
expositores a cada artı́culo. Se hace de esta forma para asegurarse que no hay personas sin
responsabilidades. Luego, el ciclo de la Lı́nea 21 elige aleatoriamente por cada track, 3 o 4
artı́culos que serán nominados como mejor artı́culo. Finalmente de acuerdo al porcentaje
de conflictos elegido para generar la instancia se calcula cuántos conflictos representa ese
porcentaje y se van asignando conflictos a cada persona hasta alcanzar dicho número.
input : Param nA, nP , nR, nB, nAS, nT , nC

output: Una instancia del problema
1 set random seed to 777 ;
2 articles = [] ;
3 people = list of nB people ;
4 rooms = list of nR rooms ;
5 blocks = list of nB blocks ;
6 tracks = list of nT tracks ;
7 for a = 0 → (nA − 4) // for almost every article do
8 track = a % (nT-1) ;
9 // new article(id, track, author, is best) ;
10 article = new article(a, track, 0, false) ;
11 articles.add(article) ;
12 tracks[track].articles.add(article) ;
13 for a = (nA − 4) → (nA) // for last 4 do
14 article = new article(a, nT-1, 0, true) ;
15 articles.add(article) ;
16 tracks[track].articles.add(article) ;
17 shuffle(articles) ;
18 shuffle(people) ;
19 for a=0 to nA do
20 articles[a].author = people[a %nP] ;
21 for track in tracks do
22 number of best = choice(3,4) ;
23 for article in sample(track.articles, number of best) do
24 article.best = true
25 total conflicts = nP * (nB-1) ;
26 conflicts = 0 ;
27 while conflicts ¡total conflicts do
28 person = choose random person from (people);
29 block = choose random conflict ;
30 if person has more than one free block then
31 person.forbidden.add(block) ;
32 conflicts+=1 ;
Algoritmo 9: Comportamiento general del generador de instancias
5.3. Análisis de instancias
La factibilidad de cada instancia del problema viene determinada por un número de factores
diferentes, y determinar un horizonte conflictivo es difı́cil debido a la dimensionalidad de
todas las variables involucradas. A continuación se hará un esfuerzo por enumerar dichos
horizontes.
Número de artı́culos
Se necesita que la cantidad de artı́culos sea menor que la cantidad máxima de artı́culos que
la planificación puede albergar, donde una mayor holgura permite una fácil distribución de
los artı́culos en muchas sesiones, y además permite a los expositores tener mejores opciones
en términos de horarios.
Mientras menos holgura exista es menos probable que la instancia del problema tenga una
solución factible. Si se observa la Figura 2.2 que muestra el programa final de la GECCO2019
se puede verificar que dicha conferencia tuvo solo una sesión libre. En este caso la mayorı́a
de las sesiones tenı́a cuatro artı́culos por sesión y cerca de 10 sesiones tenı́an 3 artı́culos, se
puede decir que los organizadores hicieron un gran trabajo haciendo la planificación, ya que
la conferencia gozaba de poca holgura en términos de artı́culos y espacio. Sin embargo como
se verá más adelante esto es posible debido a otros factores.
Número de personas
Las personas son el gran recurso humano de la planificación y su administración es inhe-

rentemente compleja. Mientras menos responsabilidades tenga cada persona mas fácil es
asignarlo a un espacio y horario, es decir, mientras más expositores, chairs y organizadores
existan, mas fácil será encontrar una solución factible. En el caso ideal en que un expositor
tiene un solo artı́culo, y existen suficiente personal para dirigir las sesiones, cada persona
tiene un único lugar y una única tarea que realizar. Las GECCO, no respetan esa relación 1-1
y el personal es normalmente limitado. En este sentido es de interés explorar instancias del
problema para las cuales el recurso humano sea considerablemente escaso y cada persona
deba tener mas de una responsabilidad.
Tamaño de la grilla
El número de salones determina que tan paralelizables son las sesiones, permitiendo ası́
mas libertad para asignar sesiones de distintos tracks; y por otro lado la cantidad de horarios
simplifica en cierta medida el cumplir con restricciones como evitar tracks en paralelo. Sin
embargo no es tan sencillo y bajo esta situación, es posible que se presenten tres tipos de
escenarios:
1. En caso de que la cantidad de tracks sea mayor que la cantidad de salones disponibles.
En este caso la instancia se verá considerablemente beneficiada, ya que fácilmente se

podrá programar sesiones de distintos tracks en un mismo horario.
2. En caso de que la cantidad de tracks sea menor que la cantidad de salones disponibles.
En este caso se enfrentará un escenario más complejo de gestión de espacio, ya que
existirá la misma cantidad de tracks compitiendo por un espacio en un solo bloque
horario. Esto requiere desplazar a otros horarios algunas sesiones incrementando ası́
la posibilidad de planificar dos sesiones de un mismo track en paralelo.
3. Luego si se tiene una mayor cantidad de sesiones que de bloques disponibles, la instan-
cia se cataloga instantáneamente como infactible. Esto escapa totalmente del alcance
de este estudio y habrı́a que desarrollar un modelo que permita minimizar las sesiones
conformadas con artı́culos de diferentes tracks.
Hardware utilizado
Los experimentos reportados en este trabajo se realizaron en un equipo i5-8250U CPU @

1.60GHz, 1800 Mhz con 16GB de RAM con compilador g++ (Ubuntu 9.3.0-17ubuntu1 20.04)
9.3.0. Mientras que la sintonización de parámetros se realizó en un equipo i5-4690K de
3.50GHz con 16GB de RAM con compilador g++ (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005.
5.4. Instancias de pruebas
Las instancias de pruebas fueron creadas mediante el generador anterior con dimensiones
similares a la GECCO y dejando en valor constante la cantidad de artı́culos y la cantidad de
tracks, ya que parecen ser un estándar para dichas conferencias.
La cantidad total de instancias generadas viene determinada por la permutación de los si-
guientes parámetros:
Cantidad de artı́culos: Este valor se dejó siempre igual a la cantidad de artı́culos de la

GECCO2019, igual a 173 artı́culos.
Cantidad de Tracks: Del mismo modo, al igual que la GECCO2019, se dejó en 14 tracks.
Cantidad de Personas: La cantidad de personas puede ser o bien 130, 150 u 170.
Cantidad de salones: Debido a que la GECCO2019 tuvo 8 salones, las instancias gene-
radas tendrán 5, 6, 7, 8 u 9 salones.
Cantidad de bloques: Debido a que la GECCO2019 tuvo 7 bloques, las instancias gene-
radas tendrán 6, 7, 8 u 9 bloques.
Artı́culos por sesión: La Gecco2019 tuvo todas sus sesiones con un máximo de 4 artı́cu-
los por sesión, sin embargo como proceso exploratorio se generaron instancias con 4
o 5 artı́culos por sesión.
Cantidad de conflictos: Actualmente no se posee datos de los conflictos temporales

de alguna GECCO anterior, y con las instancias generadas se demostró empı́ricamente
que cualquier valor mayor a 30 % es una cantidad muy alta para una conferencia. Por
lo que este valor podrá ser o bien 10 %, 20 % o 30 %
En resumen se puede calcular la cantidad total de instancias resultantes mediante la mul-

tiplicación de las cardinalidades de cada opción, esto es nR ∗ nB ∗ nAS ∗ nP ∗ nC =
5 ∗ 4 ∗ 2 ∗ 3 ∗ 3 = 360 instancias.
A partir de este conjunto de instancias, es posible identificar que varias de ellas son infactibles
por naturaleza. Esto, dado que no hay suficientes celdas en la grilla del programa para plani-
ficar tantas sesiones y, por ende pueden, ser descartadas inmediatamente desde el conjunto
de pruebas. Luego, debido a que este trabajo quiere enfocarse en determinar las instancias
mas complejas se puede, del mismo modo, descartar cualquier instancia fácil. Una forma de
determinar la facilidad de una solución es ver cuanta holgura disponible posee dicha instan-
cia. Ası́ por ejemplo, si se genera una instancia donde el tamaño de la grilla tiene 50 celdas,
la cantidad de sesiones permitidas será o bien 50 o 49, que representa la menor holgura
posible.
En el desarrollo práctico de este trabajo se demostró la facilidad de muchas instancias y el re-

positorio de este trabajo provee un gran conjunto instancias y soluciones que resultaron ser
fáciles y además factibles. Estas instancias no se incluirán en la experimentación presentada
en este documento. Finalmente, este conjunto de instancias se denominó como instancias
“fáciles” debido a que tenı́an mucha holgura del mismo tipo antes mencionado. Finalmente,
luego de la reducción y la selección de instancias difı́ciles, este estudio considera un total
de 45 instancias, listadas en la Tabla 5.1. La semilla 777 fue utilizada al momento de generar
dichas instancias de pruebas, por lo que se pueden volver a generar usando la misma semilla
aleatoria y parámetros.
La misma tabla Tabla 5.1 muestra instancias de todo tipo de tamaños y posibles combina-
ciones de los parámetros en la generación. Cada parámetro está lo mas uniformemente dis-
tribuido a lo largo de las 45 instancias. Ciertamente no es posible construir fácilmente un
conjunto de instancias que sea uniforme respecto a sus parámetros, esto debido a que un
gran número de dichas instancias es inherentemente infactible. El orden de la tabla viene de-
terminado por la dificultad del problema de manera descendiente que se explicará en detalle
en la sección de resultados.
Instancias
ID INSTANCIA ID INSTANCIA
0 A173-P130-R5-B8-L5-T14-C0.3 23 A173-P170-R5-B8-L5-T14-C0.2
1 A173-P170-R6-B9-L4-T14-C0.2 24 A173-P170-R7-B6-L5-T14-C0.3
2 A173-P130-R9-B6-L4-T14-C0.3 25 A173-P150-R6-B9-L4-T14-C0.3
3 A173-P150-R7-B6-L5-T14-C0.2 26 A173-P150-R5-B8-L5-T14-C0.3
4 A173-P170-R9-B6-L4-T14-C0.1 27 A173-P150-R7-B6-L5-T14-C0.3
5 A173-P170-R9-B6-L4-T14-C0.2 28 A173-P170-R6-B7-L5-T14-C0.3
6 A173-P130-R9-B6-L4-T14-C0.1 29 A173-P170-R5-B8-L5-T14-C0.3
7 A173-P170-R6-B9-L4-T14-C0.3 30 A173-P150-R5-B8-L5-T14-C0.2
8 A173-P150-R9-B6-L4-T14-C0.2 31 A173-P170-R6-B9-L4-T14-C0.1
9 A173-P130-R7-B6-L5-T14-C0.2 32 A173-P130-R7-B6-L5-T14-C0.1
10 A173-P130-R6-B7-L5-T14-C0.2 33 A173-P170-R5-B8-L5-T14-C0.1
11 A173-P150-R6-B9-L4-T14-C0.2 34 A173-P150-R6-B9-L4-T14-C0.1
12 A173-P130-R5-B8-L5-T14-C0.1 35 A173-P150-R6-B7-L5-T14-C0.3
13 A173-P170-R7-B6-L5-T14-C0.2 36 A173-P130-R7-B6-L5-T14-C0.3
14 A173-P150-R6-B7-L5-T14-C0.2 37 A173-P130-R6-B7-L5-T14-C0.3
15 A173-P170-R6-B7-L5-T14-C0.1 38 A173-P130-R6-B9-L4-T14-C0.1
16 A173-P130-R6-B9-L4-T14-C0.3 39 A173-P130-R5-B8-L5-T14-C0.2
17 A173-P130-R6-B9-L4-T14-C0.2 40 A173-P170-R7-B6-L5-T14-C0.1
18 A173-P150-R9-B6-L4-T14-C0.1 41 A173-P150-R5-B8-L5-T14-C0.1
19 A173-P150-R7-B6-L5-T14-C0.1 42 A173-P150-R6-B7-L5-T14-C0.1
20 A173-P170-R6-B7-L5-T14-C0.2 43 A173-P130-R6-B7-L5-T14-C0.1
21 A173-P170-R9-B6-L4-T14-C0.3 44 A173-P130-R9-B6-L4-T14-C0.2
22 A173-P150-R9-B6-L4-T14-C0.3
Tabla 5.1: Las 45 instancias seleccionadas.
5.5. Sintonización de parámetros
En la Subsección 4.2.5 se indican los parámetros necesarios para la ejecución del algoritmo,
incluyendo además parámetros necesarios para la elección de movimientos y distribución
en la que se explora el vecindario.
Para la sintonización de parámetros se busca el mejor valor que puedan tomar los paráme-
tros del algoritmo ya sea para mejorar la calidad de las soluciones que se encuentran o bien
minimizar el tiempo de cómputo. Para este trabajo se utilizará el algoritmo ParamILS para
realizar dicho proceso.
ParamILS [HHS07] presenta una solución general basada en búsqueda local para encontrar la
configuración óptima de parámetros de un algoritmo. El sintonizador destaca principalmente
por evitar los problemas de confianza (over-confidence) y sobre ajuste (over-tunning), bus-
cando encontrar una configuración considerablemente buena con un bajo número de ins-
tancias y esfuerzo de cómputo.
input : Parameter configuration space Θ, neighbourhood relation N, procedure

better (compares θ, θ0 ∈ Θ)
output: Best parameter θ found
1 θ0 = default parameter configuration θ ∈ Θ ;
2 for i = 1...R do
3 θ = random θ ∈ Θ ;
4 if better(θ, θ0 ) then
5 θ0 = θ ;
6 θils = IterativeFirstImprovement(θ0 , N) ;
7 while not TerminationCriterion() do
8 θ = θils ;
9 // PERTURBATION ;
10 for i=1...S do
11 θ = random θ0 ∈ N ;
12 // LOCAL SEARCH ;
13 θ = IterativeFirstImprovement(θ, N) ;
14 // ACCEPTANCE ;
15 if better(θ, θils ) then
16 θils = θ ;
17 with probability prestart do θils = random θ ∈ Θ ;
Algoritmo 10: Definición de un ILS adaptado a la búsqueda de parámetros(portado
completamente desde el artı́culo[HHS07] y por ende los créditos van a su respectivo
autor). Donde IterativeFirstImprovement es una función que busca aleatoriamente
el primer vecino de θ que sea mejor.
ParamILS consiste en un algoritmo estándar de Iterated Local Search (ILS), el Algoritmo 10

portado desde el artı́culo original muestra su estructura principal. En un principio el ciclo de
la lı́nea 2 indica múltiples generaciones aleatorias de configuraciones de parámetros. Luego
el ciclo de de la lı́nea 7 lleva a cabo múltiples iteraciones del algoritmo. Cada iteración lle-
va a cabo una perturbación (Lı́nea 10) que consiste en moverse aleatoriamente dentro del
vecindario. Dicha perturbación se logra a través de la modificación de uno o mas valores
de parámetros de la configuración actual θ) y posteriormente una búsqueda local (Lı́nea 13).
Finalmente compara las soluciones ,y a partir de una probabilidad dada, determina si el algo-
ritmo debe volver a empezar (Lı́nea 17). El mismo artı́culo ([HHS07]) entrega dos definiciones
del algoritmo, una donde utiliza la función better() con el mero valor de la función objetivo y
una versión Focused ILS, que vuelve más compleja la definición interna de better() incluyen-
do en el cálculo la cantidad de instancias necesarias para cada parámetro y el desempeño
que tiene el algoritmo con parámetros cualquiera θ. Considerando A(θ) como el desempeño
promedio del algoritmo con los parámetros θ, entonces una de las métricas para determinar
si una configuración es mejor que otra es, en efecto, comparar si A(θ) > A(θ0 ).
Conjunto de entrenamiento
0 A173-P130-R7-B6-L5-T14-C0.2.cs
1 A173-P150-R6-B9-L4-T14-C0.2.cs
2 A173-P170-R6-B9-L4-T14-C0.3.cs
3 A173-P150-R7-B6-L5-T14-C0.2.cs
Tabla 5.2: Subconjunto de instancias de entrenamiento del proceso de sintonización.
El artı́culo entonces presenta Focused ILS como una propuesta a fin de disminuir el tiempo
de cómputo necesario para encontrar la configuración óptima de parámetros.
ParamILS lleva años liderando la sintonización de parámetros, tanto para competencias co-
mo para problemas reales, y continua siendo objeto de estudio. Un trabajo notable es el
de [Hut+09]. El trabajo realiza un estudio completo de las familias de sintonizadores de
parámetros y extiende ParamILS con una propuesta que adaptativamente limita el tiempo
para la evaluación de configuraciones de parámetros.
En este caso los parámetros a sintonizar fueron la tasa de enfriamiento, el multiplicador de

infactibilidad, las iteraciones previas a un recalentamiento, el factor de recalentamiento y
las probabilidades de uso de cada operador. Los valores posibles para cada uno de éstos
parámetros se listan a continuación y son completamente análogos a los parámetros de la
Subsección 4.2.5.
Tasa de enfriamiento α = {0.9, 0.95, 0.999}
Multiplicador de infactibilidad γ = {100, 1000, 10000}
Iteraciones para recalentar χ = {1000, 10000}
Multiplicador al recalentar β = {1, 100, 1000}
p1 = {0, 0.25, 0.5, 0.75, 1.0}
p2 = {0, 0.25, 0.5, 0.75, 1.0}
p3 = {0, 0.25, 0.5, 0.75, 1.0}
p4 = 1 − p1 − p2 − p 3
Ambos procesos de sintonización consideran el mismo conjuntos de instancias de entrena-

miento. Las instancias fueron seleccionadas desde los conjuntos de instancias complejas que
se muestran en la Tabla 5.2. Ası́, éstas corresponden a un subconjunto de las instancias pa-
ra las cuales el solver de programación lineal Gurobi no fue capaz de encontrar la solución
óptima luego de 1[hr] de tiempo de cómputo.
Se seleccionó como la instancia mas difı́cil la instancia (3) A173-P150-R7-B6-L5-T14-C0.2,

que fue empı́ricamente una de las instancias para la cual el solver matemático de Gurobi no
pudo entregar resultados. Esta instancia considera 173 artı́culos, 150 participantes, 7 salas,
6 bloques, 5 timeslots, 13 tracks y un porcentaje total de conflictos del 20 %. En este caso
ni siquiera se pudo obtener una cota mı́nima luego de una hora de cómputo. De la misma
forma se utilizaron las otras tres instancias que muestran algunos de los tiempos de cómputo
más elevados de acuerdo a experimentos preliminares.
Para evaluar la calidad de las soluciones encontradas por el algoritmo heurı́stico propuesto
se calcula la diferencia porcentual entre la mejor solución encontrada por el solver, cuando la
hay, y respecto a la mejor solución obtenida en experimentos preliminares para la instancia
más compleja. En el caso del escenario de minimización de tiempo de ejecución se conside-
ra la diferencia porcentual previamente descrita ponderada por 1000 sumada al tiempo de
ejecución respectivo.
El algoritmo fue primeramente sintonizado manualmente, lo que fue considerando como

punto de partida para los procesos de sintonización de ParamILS. Dicha configuración toma
α = 0.999, γ = 100, p1 = p2 = p3 = p4 = 0.25, β = 1000, χ = 1000.
Los valores entregados por ParamILS en el escenario de minimización de la función de eva-

luación son α = 0.9, γ = 100, p1 = p2 = p3 = p4 = 0.25, β = 1000, χ = 1000. Estos
valores estarı́an enfocados en encontrar soluciones de calidad, sin embargo no difieren de la
sintonización manual, ya que el algoritmo de por sı́ encuentra en cada una de las instancias
el óptimo.
Para el escenario de minimización de tiempo ParamILS entregó la siguiente configuración:

α = 0.999, γ = 100, p1 = p2 = p3 = p4 = 0.25, β = 1000, χ = 10000. esta configu-
ración tampoco muestra una diferencia importante respecto a la sintonización manual ni la
sintonización que minimiza la función de evaluación.
La tabla Tabla 5.3 resume los valores obtenidos en este proceso. Acá se puede observar que la
sintonización manual no está lejos de los valores óptimos entregados por ParamILS y fueron
suficientes para la resolución de cada una de las instancias. Es importante indicar que las
probabilidades para elegir movimientos siempre fueron uniformes igual a un 0.25 % cada
una.
La primera sintonización eligió un valor mas bajo de α, γ, que se traduce en un Simulated

Annealing con un enfriamiento mas rápido y con menos castigo a las soluciones infactibles.
Ciertamente esto puede ser una mala interpretación de ParamILS por minimizar el valor in-
factibilidad de las soluciones.
Por otro lado, la segunda sintonización, fija un enfriamiento mas lento y una mayor cantidad
de iteraciones de estancamiento antes de un nuevo recalentamiento. Esto se traduce en un
Simulated Annealing con menos recalentamientos y de convergencia mas lenta.
Algoritmo α γ χ β p1 = p2 = p3 = p4
Manual 0.999 1000 1000 1000 0.25
Min. calidad 0.900 100 1000 1000 0.25
Min. tiempo 0.999 100 10000 1000 0.25
Tabla 5.3: Resumen de configuraciones de parámetros
5.6. Resumen
En este capı́tulo se presentó el escenario experimental para la futura validación de la solu-

ción. En este capı́tulo se presenta la definición de las instancias de pruebas acompañado de
un generador de instancias artificiales que permite emular conferencias de tamaño real, el
generador fue utilizado para crear cerca de 360 instancias distintas similares a la GECCO de
las cuales se eligió las 45 mas difı́ciles, es decir, aquellas con menos holgura y se descartó las
instancias inherentemente infactibles.
Además, se presentó el proceso de sintonización de parámetros usando el algoritmo Para-

mILS. Se discretizaron los parámetros necesarios y se consideraron dos escenarios para la
sintonización. Sintonización que considera como objetivo la calidad de las soluciones y otra
enfocada en disminuir los tiempos de ejecución de la heurı́stica propuesta.
CAPÍTULO
VALIDACIÓN DE LA SOLUCIÓN
En el presente capı́tulo se describen los resultados obtenidos al evaluar los métodos de reso-
lución en un conjunto de instancias de pruebas especialmente diseñado para este propósito.
En la primera parte de este capı́tulo se mostrarán los resultados obtenidos para cada una de
las 45 instancias de interés mediante el solver de programación lineal de Gurobi1 . A partir de
este proceso de resolución, las instancias son catalogadas respecto a los resultados obtenidos
en óptima, tiempo e infactible. Las instancias óptimas consideran los casos en que el solver
fue capaz de encontrar una solución óptima dentro de un tiempo de 1[hr]. Las instancias
tiempo son aquellas en que las que alcanzó el lı́mite de tiempo de 1[hr] sin encontrar la
solución óptima. Las instancias infactibles son aquellas en que el resultado del proceso dicta
que la instancia no tiene una solución que satisfaga todas las restricciones del problema.
Mas adelante en este capı́tulo se presentarán los resultados para las mismas instancias, pero
utilizando el algoritmo heurı́stico que se propuso en el Capı́tulo 4.
Acá se compara y analizan los resultados de las tres configuraciones de parámetros de interés
y se evalúa el proceso de sintonización. Mas adelante se entrega un análisis y gráfica de
convergencia para las instancias mas interesantes de cada tipo (óptimas, con lı́mite de tiempo
e infactibles).
Se presenta finalmente un análisis comparativo de los resultados obtenidos por el método

completo y el método heurı́stico.
1
https://www.gurobi.com/
68
CAPÍTULO 6. VALIDACIÓN DE LA SOLUCIÓN 69
6.1. Resultados de Gurobi
Los resultados reportados con el solver Gurobi consideran un tiempo máximo de ejecución
de 3600[s] = 1[hr]. A partir de éstas ejecuciones, es posible identificar entonces la solución
óptima, obtener la mejor solución encontrada en el lı́mite de tiempo especificado o bien
determinar que el problema no tiene solución.
La Tabla 6.1 muestra los resultados obtenidos en las instancias en que Gurobi fue capaz de
encontrar la solución óptima al problema en el lı́mite de tiempo especificado. En esta tabla
se muestra, para cada instancia, el valor de función objetivo encontrada (Z), la cota inferior
mı́nima de (Z) determinada por Gurobi (BOUND), la diferencia porcentual entre dichos valo-
res (GAP), el tiempo de ejecución utilizado para encontrar (Z) (TIME) y finalmente el estado
en que finalizó el proceso (STATUS).
Todas las instancias listadas en la Tabla 6.1 presentan un GAP igual a cero, es decir, el proceso
de resolución utilizando Gurobi determinó que fue posible encontrar la solución óptima.
Las instancias de la Tabla 6.1 se presentan ordenadas de manera descendiente respecto al

tiempo de ejecución. Ası́, se listan primero las instancias que requieren mayor tiempo de
ejecución para conseguir la solución óptima, por lo que podrı́an considerarse las más com-
plejas de esta categorı́a. En este caso se determinó que 28 de las 45 instancias quedaron en la
categorı́a con valor óptimo y que, además, son variadas en tiempos de cómputo. En este ca-
so 12 de 21 instancias demoraron entre [0-15] minutos, 7 instancias demoraron entre [15-30]
minutos, 6 instancias tomaron entre [30-45] minutos y tres instancias requirieron tiempos
superiores a 45 minutos. En este conjunto de instancias se encuentra una amplia variedad
de caracterı́sticas. Esta variedad viene dada principalmente por número de salones, horarios
y subslot disponibles. A partir de la tabla se observa primero que, respecto al número de
personas, no es posible observar una tendencia clara para determinar la dificultad del pro-
blema, donde cantidades de 130, 150 y 170 parecen estar distribuidas uniformemente a lo
largo de la tabla. Con respecto al número de salones se observa una ligera tendencia que
a mayor cantidad de salones el problema es más complicado, sin embargo esto es solo una
tendencia visual. Al observar el valor de (R)ooms en las instancias se ve que, en un principio,
las (R9) son predominantes en la primera mitad de la tabla y las (R5 y R6) dominantes al final.
Luego, para la cantidad de bloques se observa una tendencia a la inversa que el caso de los
salones, esto es, a menor cantidad de bloques se ve que las instancias son mas difı́ciles.
Como ejemplo de lo anterior se pueden considerar instancias (44), (13), (29) y (28) como
las cuatro instancias con R9, donde las primeras tres se encuentran dentro de las instancias
con mayor tiempo, y la última en las de tiempo medio. Análogamente con R6 se observa
que la mayorı́a está disperso en las instancias con mejor tiempo de ejecución, sin embargo,
no parecen haber instancias suficientes para determinar que, en efecto, R6 no se distribuye
uniformemente en términos del tiempo.
Estos últimos análisis, respecto a la cantidad de bloques y salones disponibles, están fuerte-
ID INSTANCIA Z BOUND GAP TIME[s] STATUS

5 A173-P170-R9-B6-L4-T14-C0.2 44 44 0 2983 OPTIMAL
6 A173-P130-R9-B6-L4-T14-C0.1 65 65 0 2915 OPTIMAL
7 A173-P170-R6-B9-L4-T14-C0.3 139 139 0 2541 OPTIMAL
8 A173-P150-R9-B6-L4-T14-C0.2 21 21 0 2521 OPTIMAL
9 A173-P130-R7-B6-L5-T14-C0.2 30 30 0 2184 OPTIMAL
10 A173-P130-R6-B7-L5-T14-C0.2 15 15 0 2165 OPTIMAL
11 A173-P150-R6-B9-L4-T14-C0.2 261 261 0 2095 OPTIMAL
12 A173-P130-R5-B8-L5-T14-C0.1 134 134 0 2094 OPTIMAL
13 A173-P170-R7-B6-L5-T14-C0.2 30 30 0 1655 OPTIMAL
14 A173-P150-R6-B7-L5-T14-C0.2 166 166 0 1498 OPTIMAL
15 A173-P170-R6-B7-L5-T14-C0.1 21 21 0 1450 OPTIMAL
16 A173-P130-R6-B9-L4-T14-C0.3 61 61 0 1448 OPTIMAL
17 A173-P130-R6-B9-L4-T14-C0.2 33 33 0 1381 OPTIMAL
18 A173-P150-R9-B6-L4-T14-C0.1 22 22 0 1186 OPTIMAL
19 A173-P150-R7-B6-L5-T14-C0.1 15 15 0 1111 OPTIMAL
20 A173-P170-R6-B7-L5-T14-C0.2 52 52 0 1067 OPTIMAL
23 A173-P170-R5-B8-L5-T14-C0.2 41 41 0 834 OPTIMAL
30 A173-P150-R5-B8-L5-T14-C0.2 52 52 0 633 OPTIMAL
31 A173-P170-R6-B9-L4-T14-C0.1 76 76 0 632 OPTIMAL
32 A173-P130-R7-B6-L5-T14-C0.1 24 24 0 629 OPTIMAL
33 A173-P170-R5-B8-L5-T14-C0.1 40 40 0 611 OPTIMAL
34 A173-P150-R6-B9-L4-T14-C0.1 32 32 0 600 OPTIMAL
38 A173-P130-R6-B9-L4-T14-C0.1 175 175 0 485 OPTIMAL
39 A173-P130-R5-B8-L5-T14-C0.2 21 21 0 431 OPTIMAL
40 A173-P170-R7-B6-L5-T14-C0.1 119 119 0 417 OPTIMAL
41 A173-P150-R5-B8-L5-T14-C0.1 17 17 0 403 OPTIMAL
42 A173-P150-R6-B7-L5-T14-C0.1 37 37 0 396 OPTIMAL
43 A173-P130-R6-B7-L5-T14-C0.1 5 5 0 326 OPTIMAL
Tabla 6.1: Resultados para 28 de 45 instancias para las que Gurobi encontró el óptimo. Des-
cendiente según tiempo de ejecución.
ID INSTANCIA Z BOUND GAP TIME[s] STATUS

0 A173-P130-R5-B8-L5-T14-C0.3 37 36 ∼0 3619 TIME
1 A173-P170-R6-B9-L4-T14-C0.2 176 175 ∼0 3601 TIME
2 A173-P130-R9-B6-L4-T14-C0.3 - - - 3600 TIME
3 A173-P150-R7-B6-L5-T14-C0.2 - - - 3600 TIME
4 A173-P170-R9-B6-L4-T14-C0.1 - - - 3600 TIME
Tabla 6.2: Resultados para 5 de 45 instancias para las que Gurobi no alcanzó a encontrar el
óptimo. Descendiente según tiempo de ejecución.
ID INSTANCIA TIME[s] STATUS

21 A173-P170-R9-B6-L4-T14-C0.3 1032 INFEASIBLE
Tabla 6.3: Resultados para 12 de 45 instancias para las que Gurobi determinó que no existe
solución. Descendiente según tiempo de ejecución.
mente relacionados uno con el otro, ya que ambos por si solos pueden significar poco, sin
embargo, juntos determinan el tamaño a la grilla de sesiones. Además que los resultados
indiquen una tendencia hacia ciertos tamaños apoyan la hipótesis propuesta en el análisis
de instancias de la Sección 5.3.
Es posible notar que a mayor cantidad de salones y menor cantidad de bloques el problema
resulta ser mas difı́cil, esto indica una conferencia mas paralelizable y con menos opciones de
bloques para cada sesión de los tracks. Estos resultados indican ciertamente que la cantidad
de tracks determina el horizonte del tamaño de la grilla para el cual el problema se vuelve
difı́cil de resolver.
Los últimos puntos a analizar corresponden a la cantidad de subslot de la instancia. La canti-

dad de subslot de las instancias de la tabla 6.1 están distribuidos uniformemente y no parece
haber una tendencia tan clara como la cantidad de salones y bloques previamente descrita.
En este caso, eso sı́, se observa que las instancias asociadas a conferencias con cuatro subs-
lot tienen una ligera tendencia a ser mas difı́ciles. Por ejemplo las instancias (44), (13), (39)
y (29), primeras en cantidad de tiempo, de ser en efecto mas difı́ciles su explicación radica
principalmente en que 4 subslot generan menos holgura que una de 5 subslot por el mero
hecho de permitir una mayor densidad de artı́culos por sesión.
Finalmente el porcentaje de conflictos muestra una clara correlación respecto a la dificul-

tad del problema, donde a mayor cantidad de conflictos más difı́cil es encontrar el óptimo.
En la Tabla 6.1 se observa claramente esta tendencia donde las instancias con porcentaje de
conflicto del 20 % están por sobre las demás, junto a algunas de 30 %. La Tabla 6.2 muestra
el conjunto de instancias de pruebas para las cuales no fue posible alcanzar la cota inferior
en el tiempo de cómputo especificado. El subconjunto considera 5 de 45 instancias totales.
Que esta tabla sea tan pequeña indica que éstas instancias son efecto las de más difı́cil re-
solución, ya sea por el tamaño de la grilla o bien por la cantidad de conflictos. En esta tabla
se presenta el valor objetivo Z indefinido para algunas instancias, lo que indica que Gurobi
no logró encontrar ninguna solución. Por otro lado, como se mencionó antes, BOUND es un
valor obtenido por Gurobi para determinar cual es, posiblemente, el valor mı́nimo de Z, y
como se puede observar acá ninguna instancia alcanza a tener Z=BOUND, y más aun, para
algunas instancias Gurobi no fue siquiera capaz de entregar esa cota mı́nima.
Continuando con la Tabla 6.2 se observa que, al ser una muestra de instancias considerable-
mente pequeña, no parece posible indicar alguna tendencia adicional respecto hacia donde
crece la dificultad del problema. A fin de encontrar algún patrón, se analizaron dichas ins-
tancias (disponibles en el repositorio) y las instancias no presentan ninguna distribución de
conflictos especial. Las restricciones se observan bien distribuidas en el conjunto completo
de personas de la instancia.
Finalmente la Tabla 6.3 presenta el conjunto de instancias para las cuales el solver Gurobi
indicó la condición infactible después de un tiempo de resolución menor a 1[h]. En este caso
es posible observar que la mayorı́a de las instancias infactibles fueron instancias con un 30 %
de conflictos y, la que presenta el menor tiempo de ejecución efectivamente es la instancia
de 20 % de conflictos. Esto podrı́a ser concluyente respecto a que la cantidad de conflictos
es determinante para saber si un problema tiene solución y que, además, 30 % parece ser
una cota superior para la cual el problema se vuelve imposible por naturaleza.
Para complementar el análisis previo a continuación se presenta un análisis estadı́stico de

correlación de variables. La Figura 6.1 muestra la visualización de FreeViz 2 del análisis es-
tadı́stico de correlación de variables, donde los ejes representan caracterı́sticas de la instan-
cia (con ejes subs(L)ot, (B)loques, (C)onflictos, (Personas) y (R)/Salas). En ésta, el color y
tamaño representan el tiempo de ejecución de dicha instancia. Esta figura fue creada úni-
camente con las soluciones de las instancias que resultaron tener un óptimo o alcanzar el
lı́mite de tiempo. La razón principal para no utilizar instancias infactibles fue el hecho que su
tiempo de ejecución es considerablemente bajo y, por ende, contradice los resultados an-
teriores. Además esto último nos indica un claro resultado, “si la instancia es infactible, el
resultado es veloz, pero si el solver tarda, es muy probable que tenga solución”.
Adicionalmente se provee en la Tabla 6.4 los resultados de correlación lineal respecto a las
variables que conforman una instancia con función objetivo el tiempo de ejecución. De la
tabla se puede concluir que la cantidad de conflictos es la caracterı́stica de las instancias que
más importa para determinar el tiempo de cómputo, seguido por la cantidad de salones.
Estos resultados avalan el análisis previo sobre los resultados, que confirman en efecto que
hay una leve relación entre los salones y la dificultad.
Con estos resultados se puede determinar estadı́sticamente qué instancias fueron las más
complicadas y aún más importante, empı́ricamente se puede discriminar las instancias de la
Tabla 6.2 como las instancias mas difı́ciles generadas. Dichas instancias son, por ende, impor-
2
https://orangedatamining.com/
Figura 6.1: Visualización de FreeViz: Correlación de variables respecto al objetivo del tiempo
para las instancias factibles
Correlación Conflictos Salones Subslot Bloques Personas

Pearson +0.501 +0.474 -0.350 -0.237 -0.007
Spearman +0.552 +0.391 -0.341 -0.222 +0.021
Tabla 6.4: Resultados para análisis de correlación con métricas de Pearson y Spearman
tantes para el proceso de sintonización de parámetros del algoritmo heurı́stico propuesto.
6.2. Resultados de la heurı́stica
En esta sección se presentan los resultados obtenidos al evaluar la heurı́stica propuesta en

las instancias de prueba generadas. El foco del análisis en este caso se centra principalmente
en la comparación de tres sintonizaciones de parámetros para 45 instancias con 25 semillas
distintas. Esto, seguido de un análisis de convergencia para las instancias mas interesantes
utilizando la sintonización de parámetros manuales para su fácil visualización.
A continuación se presentan los resultados para las tres sintonizaciones. Estos resultados
fueron obtenidos al ejecutar el algoritmo propuesto con las tres sintonizaciones de paráme-
tros mostradas en la Subsección 4.2.5 del capı́tulo Propuesta de Solución. Y corresponden a
la sintonización manual, a una sintonización que maximice la calidad y otra que minimice el
tiempo de ejecución.
6.2.1. Sintonización manual
Las Tabla 6.5, Tabla 6.6 y Tabla 6.7 muestran los resultados totales de ejecutar el algoritmo
con la sintonización manual. Cada una de las tablas resume la ejecución de cada instancia 25
veces. Para cada instancia se muestran los valores mı́nimo (Mı́n(Z)), máximo (Máx(Z)), y pro-
medio (P(Z)) de función objetivo obtenidas con las diferentes semillas. Además se muestra el
tiempo de ejecución promedio (P(T)) y el estado del proceso entregado por Gurobi (STATUS)
para referencia. Se considera que un experimento fue “perfecto” cuando Máx(Z)=Mı́n(Z)=P(Z).
Dichos experimentos de resaltan en las tablas de resultados usando un asterisco ∗.
Observando la Tabla 6.5, se puede verificar que:
Mı́n(Z): Se ve que para toda instancia determinada como óptima la heurı́stica fue capaz
de encontrar soluciones e intuitivamente se ve que son buenas soluciones. (Todas las
instancias alcanzaron el óptimo entregado por Gurobi)
Máx(Z): Vemos que la mayorı́a de las instancias tiene un valor igual a su mı́nimo, lo que
indica que la heurı́stica encontró 25 veces el mismo valor y por ende muestra cierta
estabilidad del algoritmo heurı́stico propuesto. Por otro lado, en las instancias que no
se obtiene el mismo valor mı́nimo, instancias (7), (8), (9), (16) y (17), la diferencia es
muy pequeña.
P(Z): Si se observa el valor promedio de función objetivo es posible revisar los casos
en los que el mı́nimo no calza con el máximo, instancias (7), (8), (9), (16) y (17), para
entender qué tan distribuido está, en cada caso, el conjunto de soluciones. La instancia
(7) encontró valores entre Z=139 y Z=140, con un P(Z)=139.0 lo que indica una fuerte
tendencia a Z=139. Mas en detalle es posible verificar que la instancia (7) en solo una
ejecución obtiene una función objetivo Z=140 y con las otras 24 semillas obtiene la
calidad óptima Z=139. En la instancia (8) 24/25 ejecuciones encontró el óptimo. En
la instancia (9) 11/25 (y las demás a una unidad del óptimo). Para la instancia (16) se
encuentra en 24/25 y para la instancia (17) se encuentra en 22/25.
P(T): Respecto al tiempo, se observa que la heurı́stica es capaz de resolver las instan-
cias en tiempos mucho menores que los requeridos por el solver Gurobi. Se observa
ID INSTANCIA Mı́n(Z) Máx(Z) P(Z) P(T)[s] STATUS

5 A173-P170-R9-B6-L4-T14-C0.2 44 44 44.0 * 12 OPTIMAL
6 A173-P130-R9-B6-L4-T14-C0.1 65 65 65.0 * 12 OPTIMAL
7 A173-P170-R6-B9-L4-T14-C0.3 139 140 139.0 6 OPTIMAL
8 A173-P150-R9-B6-L4-T14-C0.2 21 22 21.0 11 OPTIMAL
9 A173-P130-R7-B6-L5-T14-C0.2 30 31 30.6 8 OPTIMAL
10 A173-P130-R6-B7-L5-T14-C0.2 15 15 15.0 * 7 OPTIMAL
11 A173-P150-R6-B9-L4-T14-C0.2 261 261 261.0 * 5 OPTIMAL
12 A173-P130-R5-B8-L5-T14-C0.1 134 134 134.0 * 6 OPTIMAL
13 A173-P170-R7-B6-L5-T14-C0.2 30 30 30.0 * 8 OPTIMAL
14 A173-P150-R6-B7-L5-T14-C0.2 166 166 166.0 * 6 OPTIMAL
15 A173-P170-R6-B7-L5-T14-C0.1 21 21 21.0 * 7 OPTIMAL
16 A173-P130-R6-B9-L4-T14-C0.3 61 62 61.1 6 OPTIMAL
17 A173-P130-R6-B9-L4-T14-C0.2 33 34 33.1 6 OPTIMAL
18 A173-P150-R9-B6-L4-T14-C0.1 22 22 22.0 * 11 OPTIMAL
19 A173-P150-R7-B6-L5-T14-C0.1 15 15 15.0 * 8 OPTIMAL
20 A173-P170-R6-B7-L5-T14-C0.2 52 52 52.0 * 6 OPTIMAL
23 A173-P170-R5-B8-L5-T14-C0.2 41 41 41.0 * 5 OPTIMAL
30 A173-P150-R5-B8-L5-T14-C0.2 52 52 52.0 * 4 OPTIMAL
31 A173-P170-R6-B9-L4-T14-C0.1 76 76 76.0 * 5 OPTIMAL
32 A173-P130-R7-B6-L5-T14-C0.1 24 24 24.0 * 8 OPTIMAL
33 A173-P170-R5-B8-L5-T14-C0.1 40 40 40.0 * 5 OPTIMAL
34 A173-P150-R6-B9-L4-T14-C0.1 32 32 32.0 * 8 OPTIMAL
38 A173-P130-R6-B9-L4-T14-C0.1 175 175 175.0 * 6 OPTIMAL
39 A173-P130-R5-B8-L5-T14-C0.2 21 21 21.0 * 5 OPTIMAL
40 A173-P170-R7-B6-L5-T14-C0.1 119 119 119.0 * 8 OPTIMAL
41 A173-P150-R5-B8-L5-T14-C0.1 17 17 17.0 * 5 OPTIMAL
42 A173-P150-R6-B7-L5-T14-C0.1 37 37 37.0 * 7 OPTIMAL
43 A173-P130-R6-B7-L5-T14-C0.1 5 5 5.0 * 7 OPTIMAL
Tabla 6.5: Resultados heurı́sticos para 28 instancias con óptimo conocido. 25 semillas.
Parámetros manuales.

0 A173-P130-R5-B8-L5-T14-C0.3 36 36 36.0 * 5 TIME
1 A173-P170-R6-B9-L4-T14-C0.2 175 175 175.0 * 6 TIME
2 A173-P130-R9-B6-L4-T14-C0.3 10 4011 810.7 13 TIME
3 A173-P150-R7-B6-L5-T14-C0.2 42 42 42.0 * 8 TIME
4 A173-P170-R9-B6-L4-T14-C0.1 168 168 168.0 * 12 TIME
Tabla 6.6: Resultados heurı́sticos para 5 instancias con óptimo desconocido por tiempo. 25
semillas. Parámetros manuales.

21 A173-P170-R9-B6-L4-T14-C0.3 8069 12073 8870.9 12 INFEASIBLE
Tabla 6.7: Resultados heurı́sticos para 12 instancias determinadas como infactibles. 25 semi-
llas. Parámetros manuales.
también una ligera tendencia a aumentar el tiempo de ejecución a medida que la ins-
tancia se vuelve más compleja. Al observar por ejemplo las instancias (21), (22) y (24) se
nota que están dentro de las más difı́ciles y resultan ser las que más tiempo necesitan
(12, 12 y 9 segundos respectivamente), sin embargo tomando el panorama completo
esta tendencia no parece ser tan clara, ya que, por ejemplo, las instancias (36) y (44)
están dentro de las más fáciles con 8 y 12 segundos.
La Tabla 6.6 resume los resultados obtenidos por el algoritmo heurı́stico propuesto para el
conjunto de instancias para las que Gurobi no fue capaz de encontrar la solución óptima
en el tiempo dado. La tabla presenta la misma información de mı́nimo, máximo y promedio
de función objetivo, tiempo de ejecución promedio y estatus del proceso de Gurobi. Las
observaciones respecto a estos resultados se resumen a continuación:
Mı́n(Z): Todas las instancias tienen un valor mı́nimo que avala la ventaja del uso de un
método heurı́stico, siendo éste siempre capaz de encontrar una solución de calidad en
el tiempo dado.
Máx(Z): Todas las instancias, a excepción de la número (2), comparten mı́nimo y máxi-
mo por lo que se sigue demostrando la estabilidad de la heurı́stica. La instancia (2)
alcanzó un máximo de Z=4011, que indica que el resultado fue infactible, al menos en
una ejecución. Esto nos indica que dicha instancia seguramente es la mas difı́cil para el
algoritmo heurı́stico propuesto, y que en ciertos casos la heurı́stica no puede encontrar
siquiera un resultado válido respecto a factibilidad.
P(Z): Solo la instancia (2) es de interés en este caso. La instancia (2) entrega un P(Z)=810.7,
que indica que en un número no menor de ejecuciones se obtuvo un valor de función
objetivo distinto a Z=10. Al observar los resultados en detalle, semilla por semilla, se tie-
ne que la instancia (2) obtuvo como resultado en seis ocasiones Z=10, en 13 ocasiones
Z=11, en una ocasión Z=12 y en 5 ocasiones entregó un Z > 4000. Esta instancia desta-
ca considerablemente por sobre las demás, en ninguna otra instancia se presenta esta
variedad de resultados. Es probable que esta instancia requiera mas tiempo de eje-
cución para entregar siempre la solución óptima. La instancia no parece tener alguna
distribución de conflictos anormal, los conflictos se distribuyen de manera equitativa
entre los diferentes actores del problema.
T(Z): No hay suficientes datos como para concluir una tendencia. Si consideramos éstas
instancias y las de la tabla anterior tampoco se ve una tendencia en los tiempos de
ejecución.
Finalmente analizando la Tabla 6.7 se presentan los resultados de la heurı́stica en las instan-
cias que se sabe, gracias a Gurobi, que son inherentemente infactibles. A partir de dichos
resultados se puede concluir lo siguiente:
Mı́n(Z): Todas las instancias muestran valores mucho mas altos que los resultados an-
teriores. Esto lógicamente se debe a su infactibilidad y penalización por restricciones
duras incumplidas. Para la sintonización manual se consideró un multiplicador por cas-
tigo de 1000, por lo que se puede estimar intuitivamente cuántas restricciones duras
Z
están siendo incumplidas con ∼ 1000 . Tomando como ejemplo la instancia (21) se tiene
un valor de Z=8069 que indica que, aproximadamente, se podrı́a esperar que existan
8 restricciones duras incumplidas en la solución y una calidad de 69. De todas maneras
es relevante notar que estos valores siguen siendo pequeños, y entregan información
aproximada de qué tan cerca se está de tener una solución factible en cada caso. Esta
información podrı́a ser útil para los organizadores para solicitar mayor disponibilidad
o flexibilidad a los expositores en un caso real de la planificación de la conferencia.
Máx(Z): La mayorı́a de las instancias no comparte este valor con su mı́nimo, en casos
infactibles el algoritmo no siempre va a converger al mismo valor ya que probablemen-
te, se encontrará en continua exploración, sin embargo, los valores son muy similares
a su mı́nimo, y converge en términos de órdenes de magnitud. Las instancias que no
coinciden en órdenes de magnitud son las instancias (21), (22) y (26), para las cuales, es
muy probable, que el proceso de exploración sea más agresivo. La instancia que pre-
senta las mayores diferencias es la instancia (21) con Mı́n(Z)=8069 y Máx(Z)=12073.
Sin embargo gracias a que el factor de multiplicación considerado en éstas pruebas es
1000, hacer la comparativa con esos dos números no es justo para la heurı́stica y lo
mejor serı́a comparar de acuerdo a órdenes de magnitud. Ası́, se observa que la so-
lución listada como Z=8069 representa en realidad 8 restricciones incumplidas y 69
de calidad de uso de espacio (8,69) y la solución listada como Z=12073 representan en
realidad 12 restricciones incumplidas y 73 de calidad respecto al uso de espacio (12,73).
Esto implica que si se hace la comparación considerando solo infactibilidades se puede
decir que Mı́n(Z)∼Máx(Z).
P(Z): No hay nada destacable del valor promedio mas que lo mencionado anteriormen-
te. Todas las instancias tienen una tendencia del promedio hacia el Mı́n(Z). Justificando
nuevamente la estabilidad de la heurı́stica.
T(Z): No parece haber alguna tendencia en como se distribuye el tiempo de cómputo
en éstas instancias.
6.2.2. Sintonización para mejor calidad
Las Tabla 6.8, Tabla 6.9 y Tabla 6.10 muestran los resultados de ejecutar el algoritmo heurı́sti-
co con la sintonización de parámetros obtenida al considerar como objetivo la optimización
de la calidad final. Aquı́ es importante mencionar que uno de los parámetros distintos, con
respecto a la sintonización manual, es el factor de castigo para restricciones incumplidas que
en vez de ser 1000 es 100.
En la Tabla 6.8 se observa que las columnas Mı́n(Z) y Máx(Z) son invariantes respecto a los
resultados obtenidos con la sintonización manual. La columna P(Z) muestra diferencias, para
las cuales la actual sintonización tiene un desempeño ligeramente peor que la sintonización
manual. Con esto podemos concluir que las instancias con óptimo conocido no presentan
una mayor variación respecto a los parámetros que optimizan la calidad y además son equi-
valentes. En términos de tiempo fue mejor por décimas de segundos y, como se verá mas
adelante en la Tabla 6.14, solo en términos acumulados se nota la diferencia.
En la Tabla 6.9 se observa que la columna Mı́n(Z) es invariante respecto de la sintonización

manual. Las columnas Máx(Z) y P(Z) en la instancia (2) disminuyeron considerablemente su
valor, sin embargo, esto es causado principalmente porque se usa un menor multiplicador de
castigo. Para comparar dichos resultados deberı́amos separar las restricciones incumplidas
de la calidad de uso de espacio. Ası́, utilizando la sintonización manual se obtuvo una solución
que a lo mucho considera 4 restricciones incumplidas, mientras que para esta sintonización
la mejor solución considera 8 restricciones incumplidas.
En la Tabla 6.10 se observa lo antes mencionado nuevamente. Las columnas Mı́n(Z), Máx(Z)
y P(Z) se ven disminuidas en cerca de un orden de magnitud lo que no representa que los
parámetros estén realmente encontrando mejores soluciones. Haciendo el mismo análisis en
las instancias “diferentes” ((21), (22) y (26)) se observa que, de manera equivalente, mues-
tran los mismos cambios en la magnitud entre los valores mı́nimos y máximos. Por lo que la
evidencia muestra que los casos particulares se comportan del mismo modo.
6.2.3. Sintonización para mejor tiempo
Las Tabla 6.11, Tabla 6.12 y Tabla 6.13 muestran los resultados de ejecutar el algoritmo con
la sintonización que considera como objetivo la minimización de los tiempos de ejecución.

5 A173-P170-R9-B6-L4-T14-C0.2 44 44 44.0 * 11 OPTIMAL
6 A173-P130-R9-B6-L4-T14-C0.1 65 65 65.0 * 11 OPTIMAL
7 A173-P170-R6-B9-L4-T14-C0.3 139 140 139.1 5 OPTIMAL
8 A173-P150-R9-B6-L4-T14-C0.2 21 22 21.2 11 OPTIMAL
9 A173-P130-R7-B6-L5-T14-C0.2 30 31 30.7 8 OPTIMAL
10 A173-P130-R6-B7-L5-T14-C0.2 15 15 15.0 * 6 OPTIMAL
11 A173-P150-R6-B9-L4-T14-C0.2 261 261 261.0 * 5 OPTIMAL
12 A173-P130-R5-B8-L5-T14-C0.1 134 134 134.0 * 5 OPTIMAL
13 A173-P170-R7-B6-L5-T14-C0.2 30 30 30.0 * 8 OPTIMAL
14 A173-P150-R6-B7-L5-T14-C0.2 166 166 166.0 * 6 OPTIMAL
15 A173-P170-R6-B7-L5-T14-C0.1 21 21 21.0 * 6 OPTIMAL
16 A173-P130-R6-B9-L4-T14-C0.3 61 62 61.0 5 OPTIMAL
17 A173-P130-R6-B9-L4-T14-C0.2 33 33 33.0 * 5 OPTIMAL
18 A173-P150-R9-B6-L4-T14-C0.1 22 22 22.0 * 11 OPTIMAL
19 A173-P150-R7-B6-L5-T14-C0.1 15 15 15.0 * 8 OPTIMAL
20 A173-P170-R6-B7-L5-T14-C0.2 52 52 52.0 * 6 OPTIMAL
23 A173-P170-R5-B8-L5-T14-C0.2 41 41 41.0 * 5 OPTIMAL
30 A173-P150-R5-B8-L5-T14-C0.2 52 52 52.0 * 5 OPTIMAL
31 A173-P170-R6-B9-L4-T14-C0.1 76 76 76.0 * 6 OPTIMAL
32 A173-P130-R7-B6-L5-T14-C0.1 24 24 24.0 * 8 OPTIMAL
33 A173-P170-R5-B8-L5-T14-C0.1 40 40 40.0 * 5 OPTIMAL
34 A173-P150-R6-B9-L4-T14-C0.1 32 32 32.0 * 5 OPTIMAL
38 A173-P130-R6-B9-L4-T14-C0.1 175 175 175.0 * 5 OPTIMAL
39 A173-P130-R5-B8-L5-T14-C0.2 21 21 21.0 * 5 OPTIMAL
40 A173-P170-R7-B6-L5-T14-C0.1 119 119 119.0 * 8 OPTIMAL
41 A173-P150-R5-B8-L5-T14-C0.1 17 17 17.0 * 5 OPTIMAL
42 A173-P150-R6-B7-L5-T14-C0.1 37 37 37.0 * 6 OPTIMAL
43 A173-P130-R6-B7-L5-T14-C0.1 5 5 5.0 * 6 OPTIMAL
Parámetros para maximizar calidad.

0 A173-P130-R5-B8-L5-T14-C0.3 36 36 36.0 * 5 TIME
1 A173-P170-R6-B9-L4-T14-C0.2 175 175 175.0 * 5 TIME
2 A173-P130-R9-B6-L4-T14-C0.3 10 801 136.3 11 TIME
3 A173-P150-R7-B6-L5-T14-C0.2 42 42 42.0 * 8 TIME
4 A173-P170-R9-B6-L4-T14-C0.1 168 168 168.0 * 11 TIME
semillas. Parámetros para maximizar calidad.

Tabla 6.10: Resultados heurı́sticos para 12 instancias determinadas como infactibles. 25 se-
millas. Parámetros para maximizar calidad.
Nuevamente es importante mencionar que uno de los parámetros distintos es el factor de

castigo para restricciones incumplidas que, en vez de ser 1000 es 100.
En la Tabla 6.11 se observa que las columnas Mı́n(Z), Máx(Z) y P(Z) son invariantes respecto
a los obtenidos con la sintonización de mejor calidad. Se observa en este caso que el P(T)
disminuyó en 1 segundo en las instancias (5) y (6), sin embargo, la diferencia es mı́nima y
posiblemente sea coincidencia. Hay solo un caso especial que es la instancia (9) que su valor
de Máx(Z) en todos los otros experimentos tenia un Z=31, pero en éste experimento aumento
a Z=32. No es un cambio considerable para los resultados, pero tampoco es despreciable.
Observando la Tabla 6.12 se ve que las columnas Mı́n(Z), Máx(Z) y P(Z) se mantuvieron inva-
riantes respecto a la sintonización de mejor calidad.
En la Tabla 6.13 se observa el único cambio en los resultados, donde tanto Mı́n(Z), Máx(Z) y
P(Z) empeoraron en calidad considerablemente.
6.2.4. Comparativa entre sintonizaciones
En las tres secciones anteriores se compararon la sintonización de parámetros manual, pa-

ra mejor calidad y para mejor tiempo. De la que se puede concluir que no hay diferencia
aparente entre la mayor parte de los resultados. Todas las configuraciones de parámetros
logran, después de cierta cantidad de ejecuciones, encontrar el óptimo y la mayorı́a además
compartir su mı́nimo con su máximo. La Tabla 6.14 entrega un resumen total para cada una
de las sintonizaciones, donde cada casilla es el valor acumulativo de las 45 instancias. Esta ta-
bla, debido al factor de castigo, no permite comparar la sintonización manual directamente,

5 A173-P170-R9-B6-L4-T14-C0.2 44 44 44.0 * 11 OPTIMAL
6 A173-P130-R9-B6-L4-T14-C0.1 65 65 65.0 * 11 OPTIMAL
7 A173-P170-R6-B9-L4-T14-C0.3 139 140 139.1 5 OPTIMAL
8 A173-P150-R9-B6-L4-T14-C0.2 21 22 21.1 11 OPTIMAL
9 A173-P130-R7-B6-L5-T14-C0.2 30 32 30.9 8 OPTIMAL
10 A173-P130-R6-B7-L5-T14-C0.2 15 15 15.0 * 6 OPTIMAL
11 A173-P150-R6-B9-L4-T14-C0.2 261 261 261.0 * 5 OPTIMAL
12 A173-P130-R5-B8-L5-T14-C0.1 134 134 134.0 * 5 OPTIMAL
13 A173-P170-R7-B6-L5-T14-C0.2 30 30 30.0 * 8 OPTIMAL
14 A173-P150-R6-B7-L5-T14-C0.2 166 166 166.0 * 6 OPTIMAL
15 A173-P170-R6-B7-L5-T14-C0.1 21 21 21.0 * 6 OPTIMAL
16 A173-P130-R6-B9-L4-T14-C0.3 61 62 61.3 5 OPTIMAL
17 A173-P130-R6-B9-L4-T14-C0.2 33 34 33.2 5 OPTIMAL
18 A173-P150-R9-B6-L4-T14-C0.1 22 22 22.0 * 11 OPTIMAL
19 A173-P150-R7-B6-L5-T14-C0.1 15 15 15.0 * 8 OPTIMAL
20 A173-P170-R6-B7-L5-T14-C0.2 52 52 52.0 * 6 OPTIMAL
23 A173-P170-R5-B8-L5-T14-C0.2 41 41 41.0 * 5 OPTIMAL
30 A173-P150-R5-B8-L5-T14-C0.2 52 53 52.0 * 5 OPTIMAL
31 A173-P170-R6-B9-L4-T14-C0.1 76 76 76.0 * 5 OPTIMAL
32 A173-P130-R7-B6-L5-T14-C0.1 24 24 24.0 * 8 OPTIMAL
33 A173-P170-R5-B8-L5-T14-C0.1 40 40 40.0 * 5 OPTIMAL
34 A173-P150-R6-B9-L4-T14-C0.1 32 32 32.0 * 5 OPTIMAL
38 A173-P130-R6-B9-L4-T14-C0.1 175 175 175.0 * 5 OPTIMAL
39 A173-P130-R5-B8-L5-T14-C0.2 21 21 21.0 * 5 OPTIMAL
40 A173-P170-R7-B6-L5-T14-C0.1 119 119 119.0 * 8 OPTIMAL
41 A173-P150-R5-B8-L5-T14-C0.1 17 17 17.0 * 5 OPTIMAL
42 A173-P150-R6-B7-L5-T14-C0.1 37 37 37.0 * 6 OPTIMAL
43 A173-P130-R6-B7-L5-T14-C0.1 5 5 5.0 * 6 OPTIMAL
Parámetros para minimizar tiempo.

0 A173-P130-R5-B8-L5-T14-C0.3 36 36 36.0 * 5 TIME
1 A173-P170-R6-B9-L4-T14-C0.2 175 175 175.0 * 5 TIME
2 A173-P130-R9-B6-L4-T14-C0.3 10 412 123.2 11 TIME
3 A173-P150-R7-B6-L5-T14-C0.2 42 42 42.0 * 8 TIME
4 A173-P170-R9-B6-L4-T14-C0.1 168 168 168.0 * 11 TIME
semillas. Parámetros para minimizar tiempo.

Tabla 6.13: Resultados heurı́sticos para 12 instancias determinadas como infactibles. 25 se-
millas. Parámetros para minimizar tiempo.
sin embargo es posible estimar debido a la magnitud que valor le corresponde a la sintoniza-
ción manual. Ası́, la fila “MANUAL ESCALADO” permite realizar esta comparación. Con esto
se puede concluir que tanto para Mı́n(Z), Máx(Z), P(Z) la sintonización manual “escalada”
obtuvo los mejores resultados.
TIPO ΣMı́n(Z) ΣMáx(Z) ΣP(Z) Σ P(T)[s]

MANUAL 96075 118103 100883 338
MANUAL ESCALADO 9608 11810 10088 338
MEJOR 11569 15665 12420 316
TIEMPO 12375 14496 12791 315
Tabla 6.14: Resumen acumulativo (suma) de las tres sintonizaciones para las 45 instancias
para 25 semillas distintas. 3×24×25 ejecuciones.
Los resultados generales indican que la heurı́stica es lo suficientemente buena para encon-
trar resultados en cualquier caso, lo que hace pensar además que es lo suficientemente es-
table independiente de la semilla con la que se trate. Aún mas importante, en el hecho que
en un principio este trabajo no contemplaba resolver instancias infactibles, sin embargo, la
heurı́stica fue lo suficientemente buena para minimizar de todas formas la cantidad de res-
tricciones incumplidas, lo que permite entregar información útil a los organizadores de una
conferencia dada acerca de la cantidad mı́nima de cambios necesarias para volver la actual
instancia en una factible. Normalmente dichos cambios podrı́an ser pedirle a los expositores
que flexibilicen su disponibilidad horaria o bien considerar solicitar más personal.
6.2.5. Análisis de convergencia
A continuación se presenta un análisis de convergencia de los procesos de búsqueda de la

heurı́stica en diferentes escenarios. Para esto se seleccionaron las instancias (5) como re-
presentante del escenario de instancias con óptimo conocido (semilla 3717). Se selecciona
la instancia (2) pues además fue la única instancia que, para ciertas semillas, terminó entre-
gando soluciones infactibles (semilla 8355). Finalmente se considera la instancia (21) como
representante de las instancias infactibles. Cada una de ellas representa la más difı́cil en su
categorı́a y por ende candidatas para un análisis de convergencia.
Los gráficos de convergencia muestran la relación de calidad de solución versus tiempo (ite-
raciones) para las diferentes ejecuciones del algoritmo.
La Figura 6.2 muestra un proceso de búsqueda tı́pico. Los puntos rojos muestran soluciones
infactibles mientras que los verdes representan soluciones factibles. Recordando que la so-
lución inicial para SA no es aleatoria, sino un conjunto de técnicas greedy es posible afirmar
que tiene un decaimiento considerablemente rápido en la calidad de la solución (Z) y tem-
pranamente llega a la zona de “estancamiento”. La zona comienza en un principio solo con
soluciones infactibles y continua mejorando hasta encontrar soluciones factibles. Finalmente
la heurı́stica continua buscando mejores soluciones y de ser necesario vuelve a recalentar. Se
aprecia que el recalentamiento funciona e incluso permite a la heurı́stica navegar por solu-
ciones infactibles durante toda la ejecución del algoritmo. Algo curioso de mencionar es que
debido a que se utiliza un factor de castigo y un recalentamiento lineal, la gráfica es atı́pica
respecto a las gráficas de los SA estándar.
Los gráficos que se presentan en la siguientes secciones se presentan en escala logarı́tmica

para mejorar el proceso de inspección de los procesos de búsqueda respectivos.
Convergencia para instancia óptima
El gráfico de convergencia en la Figura 6.3 muestra el proceso de convergencia de la instancia

(5). En este caso, en las primeras 104 iteraciones se presenta la mayor mejora en la calidad,
pero aún siendo incapaz de generar soluciones factibles. Luego cercano a la iteración 105
se encuentra la primera solución factible y se continua mejorando continuamente. Se ob-
serva además que las soluciones factibles están presente en todas calidades y, por ende, la
heurı́stica es capaz de explorar zonas factibles cercanas, y también volver a visitar solucio-
nes infactibles a fin de tener una mayor exploración. Como se mencionó anteriormente este
gráfico es atı́pico respecto a un SA ya que lo normal es que la calidad máxima de las solu-
ciones vaya disminuyendo con el tiempo. Otra cosa importante y que sorprende es que las
soluciones infactibles exploradas desde la iteración 104 en adelante parecen estar divididas
en niveles. Esto se explica principalmente al factor de infactibilidad que multiplica por 1000
cada restricción insatisfecha. Por ende la cantidad de lı́neas determina distintos “niveles de
infactibilidad” comunes dentro de una instancia, ya que en la Figura 6.3 se distinguen cerca
A173-P130-R9-B6-L4-T14-C0.3
600000
500000
400000
Objetivo(Z)
300000
200000
100000
0
0 1 2 3 4 5
Iteraciones 1e6
Figura 6.2: Ejemplo de gráfica con ejes lineales.
de 8 lı́neas horizontales se puede indicar que existen 8 niveles de dificultad distintos y que
además implica que la heurı́stica es capaz de empeorar cerca de 8 veces su solución a fin de
explorar nuevas zonas de búsqueda.
Convergencia para instancia con lı́mite de tiempo
La Figura 6.4 muestra el proceso de convergencia de la instancia (2). Es importante indi-

car que, en este caso, Gurobi determinó tiempo insuficiente y que, además, la heurı́stica en
ciertas ejecuciones no fue capaz de encontrar el óptimo. Viendo la figura se observa un com-
portamiento considerablemente distinto a la instancia anterior. En este caso, en las primeras
103 iteraciones no se presenta ninguna mejora notable y pareciera que el proceso está es-
tancado. Luego, alrededor de la iteración 104 se tiene una importante mejora. Esto último
indica que la instancia por naturaleza es muy infactible, y que necesitó de una gran cantidad
de iteraciones para encontrar el camino correcto hacia otro espacio de búsqueda. A partir
de las 104 iteraciones se observa que la heurı́stica encontró un “nuevo espacio” al, proba-
A173-P170-R9-B6-L4-T14-C0.2
104
Objetivo(Z)
103
102
101 102 103 104 105 106

Iteraciones
Figura 6.3: Convergencia para la instancia (5). Instancia que Gurobi determinó óptima con el
mayor tiempo de cómputo. Semilla (3717). Ejes en escalas logarı́tmicas.
blemente, haber resuelto las restricciones que menos libertad de movimiento permitı́an.
Finalmente recién cerca de las iteraciones 106 se encuentra la primera solución factible y
continua con la mejora de la calidad. A diferencia de la gráfica anterior ésta encontró una
solución factible mucho mas tarde y necesitó cerca de 10 veces más iteraciones para lograr-
lo. Se observa también que hay un menor numero de lı́neas horizontales rojas distinguibles,
y además mucho espacio entre la primera lı́nea de soluciones infactibles y el conjunto de
soluciones factibles. Esto implica que el algoritmo debe lograr una mejorı́a muy grande en
muy pocos movimientos lo que podrı́a explicar entonces porqué en algunas ejecuciones el
algoritmo no es capaz de encontrar soluciones factibles. Esto, pues aparentemente se nece-
sita explorar un vecindario de soluciones muy particular para poder continuar mejorando la
solución.
A173-P130-R9-B6-L4-T14-C0.3
106
105
104
Objetivo(Z)
103
102
101
100 101 102 103 104 105 106 107
Iteraciones
Figura 6.4: Convergencia para la instancia (2). Una de las instancias para las que Gurobi al-
canzó un lı́mite de tiempo. Semilla (8355). Ejes en escala logarı́tmica.
Convergencia para instancia infactible
La Figura 6.5 muestra el proceso de convergencia de la instancia (21). La instancia 21 fue

determinada como infactible por Gurobi y la instancia que más tiempo le tardó determinar
como infactible. Por ende, podemos suponerla como la instancia más difı́cil en esta categorı́a.
Por su parte, la heurı́stica encuentra su mejor solución infactible en 12[s]. Se observa en este
caso un comportamiento similar a la gráfica para la instancia óptima (Figura 6.3) con una
fuerte mejorı́a hasta la iteración 103 seguido de mejoras continuas durante el resto de la
ejecución.
Como es de esperarse no hay puntos factibles (de color verde), sin embargo, que no existan
soluciones factibles permite observar de mejor manera los niveles de infactibilidad antes
mencionados. Esto, gracias también a que la escala ahora lo permite. En este caso se ve
que el algoritmo es capaz de empeorar su solución a fin de explorar una gran cantidad de
veces durante el proceso. La cantidad de niveles de infactibilidad observados corresponden
a aproximadamente 12 niveles. Además este gráfico permite observar de manera más fácil
cuando ocurren recalentamientos y fuertes estancamientos. El primer “gran” estancamiento

ocurrió cerca de las iteraciones 105 hasta que logró salir luego de empeorar su calidad.
A173-P170-R9-B6-L4-T14-C0.3
104
Objetivo(Z)
103
100 101 102 103 104 105 106 107

Iteraciones
Figura 6.5: Convergencia para la instancia (21). Instancia infactible con mayor tiempo de
cómputo. Semilla (5877). Ejes en escala logarı́tmica.
6.3. Comparativa de Gurobi con Heurı́stica
Las Tabla 6.15, Tabla 6.16 y Tabla 6.17 resumen los resultados obtenidos tanto por el solver
Gurobi como los obtenidos por el algoritmo heurı́stico propuesto en este trabajo de tı́tulo. En
cada caso se muestra el valor de función objetivo obtenido por el solver, su tiempo de con-
vergencia en segundos y el estado del proceso indicado por éste mismo. Además se muestra
la calidad promedio de las soluciones encontradas por la heurı́stica y el tiempo promedio de
resolución en segundos usando la configuración de parámetros manual.
De la Tabla 6.15 se puede verificar que, en estos problemas, ambos acercamientos fueron
siempre capaces de encontrar la solución óptima al problema. Eso sı́, los tiempos de cómpu-
to requeridos por Gurobi son de dos a tres órdenes de magnitud mayores que los tiempos
requeridos por cada ejecución del algoritmo heurı́stico propuesto.
En la Tabla 6.16 se muestran las instancias en que Gurobi no pudo encontrar la solución ópti-
ma en el tiempo máximo de 1[hr] dado, se observa que la heurı́stica fue capaz de encontrar
siempre soluciones de mejor calidad. En las instancias (0) y (1) de esta tabla, la solución en-
contrada por la heurı́stica consigue valores de función objetivo inferiores que el solver. En
los tres casos restantes la heurı́stica obtiene soluciones factibles en tiempos muy acotados,
cosa que le fue imposible al solver en la hora dada para el proceso de resolución.
Por último, en la Tabla 6.17 se presenta el resumen de resultados para las instancias deter-
minadas infactibles por Gurobi. En este caso la heurı́stica coincide con el solver, pero a di-
ferencia de éste, es capaz de reportar soluciones que minimizan la insatisfacción de dichas
restricciones. Como se indicó anteriormente, esta información puede ser útil para promover
la flexibilidad de dichos temas, cambiando tal vez los roles de algunos asistentes de modo
de obtener soluciones viables para todos. Los tiempos de cómputo de la heurı́stica como en
todos los casos anteriores se mantiene por debajo de los 15 segundos en promedio.
6.4. Resumen
En este capı́tulo se presentaron los resultados de la evaluación de los acercamientos pro-

puestos usando un conjunto de instancias de pruebas para diversos casos de análisis. En pri-
mer lugar se presentan los resultados obtenidos por el solver matemático Gurobi que define
la primera clasificación de instancias de pruebas. A partir de estos experimentos es posible
clasificar las instancias en casos para los cuales Gurobi encontró el óptimo antes de 1[hr],
instancias para las cuales luego de la hora de ejecución Gurobi no es capaz de alcanzar el
óptimo y, finalmente, instancias que Gurobi determinó como infactibles.
A partir de dichos resultados se comprobaron algunas de las intuiciones previas del Sec-
ción 5.3 del Experimentos y se analizó hacia donde crece realmente la complejidad del pro-
blema. Se presentó también un gráfico (Figura 6.1) y la Tabla 6.4 a fin de justificar la correla-
ción que existe entre las caracterı́sticas de las instancias y sus tiempos de ejecución.
En la segunda parte se este capı́tulo se presentan los resultados obtenidos por la heurı́sti-
ca para las tres sintonizaciones de parámetros: manual, mejor solución y mejor tiempo. La
Tabla 6.14 mostró un resumen acumulado general de 25 × 45 ejecuciones que finalmente
demostró lo invariante del comportamiento. Aún ası́ la sintonización tuvo este comporta-
miento debido a la sintonización de un factor de castigo, y por ende el navegar por zonas
infactibles tiene un valor inherentemente mas bajo (revisar el capı́tulo para mas detalles).
La comparación de dichas configuraciones permitió encontrar buenos resultados y demos-

trar una estabilidad del algoritmo heurı́stico propuesto en términos de convergencia. A partir
ID INSTANCIA Z TIME.G STATUS HEU TIME.H

5 A173-P170-R9-B6-L4-T14-C0.2 44 2983 OPTIMAL 44 12
6 A173-P130-R9-B6-L4-T14-C0.1 65 2915 OPTIMAL 65 12
7 A173-P170-R6-B9-L4-T14-C0.3 139 2541 OPTIMAL 139 6
8 A173-P150-R9-B6-L4-T14-C0.2 21 2521 OPTIMAL 21 11
9 A173-P130-R7-B6-L5-T14-C0.2 30 2184 OPTIMAL 30 8
10 A173-P130-R6-B7-L5-T14-C0.2 15 2165 OPTIMAL 15 7
11 A173-P150-R6-B9-L4-T14-C0.2 261 2095 OPTIMAL 261 5
12 A173-P130-R5-B8-L5-T14-C0.1 134 2094 OPTIMAL 134 6
13 A173-P170-R7-B6-L5-T14-C0.2 30 1655 OPTIMAL 30 8
14 A173-P150-R6-B7-L5-T14-C0.2 166 1498 OPTIMAL 166 6
15 A173-P170-R6-B7-L5-T14-C0.1 21 1450 OPTIMAL 21 7
16 A173-P130-R6-B9-L4-T14-C0.3 61 1448 OPTIMAL 61 6
17 A173-P130-R6-B9-L4-T14-C0.2 33 1381 OPTIMAL 33 6
18 A173-P150-R9-B6-L4-T14-C0.1 22 1186 OPTIMAL 22 11
19 A173-P150-R7-B6-L5-T14-C0.1 15 1111 OPTIMAL 15 8
20 A173-P170-R6-B7-L5-T14-C0.2 52 1067 OPTIMAL 52 6
23 A173-P170-R5-B8-L5-T14-C0.2 41 834 OPTIMAL 41 5
30 A173-P150-R5-B8-L5-T14-C0.2 52 633 OPTIMAL 52 4
31 A173-P170-R6-B9-L4-T14-C0.1 76 632 OPTIMAL 76 5
32 A173-P130-R7-B6-L5-T14-C0.1 24 629 OPTIMAL 24 8
33 A173-P170-R5-B8-L5-T14-C0.1 40 611 OPTIMAL 40 5
34 A173-P150-R6-B9-L4-T14-C0.1 32 600 OPTIMAL 32 8
38 A173-P130-R6-B9-L4-T14-C0.1 175 485 OPTIMAL 175 6
39 A173-P130-R5-B8-L5-T14-C0.2 21 431 OPTIMAL 21 5
40 A173-P170-R7-B6-L5-T14-C0.1 119 417 OPTIMAL 119 8
41 A173-P150-R5-B8-L5-T14-C0.1 17 403 OPTIMAL 17 5
42 A173-P150-R6-B7-L5-T14-C0.1 37 396 OPTIMAL 37 7
43 A173-P130-R6-B7-L5-T14-C0.1 5 326 OPTIMAL 5 7
Tabla 6.15: Comparativa de los resultados de GUROBI con la heurı́stica para instancias con
óptimo conocido. Mejores valores

0 A173-P130-R5-B8-L5-T14-C0.3 37 3619 TIME 36 5
1 A173-P170-R6-B9-L4-T14-C0.2 176 3601 TIME 175 6
2 A173-P130-R9-B6-L4-T14-C0.3 - 3600 TIME 11 13
3 A173-P150-R7-B6-L5-T14-C0.2 - 3600 TIME 42 8
4 A173-P170-R9-B6-L4-T14-C0.1 - 3600 TIME 168 12
Tabla 6.16: Comparativa de los resultados de GUROBI con la heurı́stica para instancias con
óptimo desconocido debido al tiempo. Mejores valores

21 A173-P170-R9-B6-L4-T14-C0.3 - 1032 INFEASIBLE 8069 12
Tabla 6.17: Comparativa de los resultados de GUROBI con la heurı́stica para instancias deter-
minadas como infactibles. Mejores valores
de dichos resultados se observa que el algoritmo heurı́stico casi siempre llegaba al mismo
nivel de calidad obtenido por el solver en tiempos mucho más acotados.
Finalmente para la heurı́stica se comparan los procesos de convergencias de tres de las ins-
tancias mas difı́ciles. Se considera una de cada clasificación, una con óptimo conocido, una
con lı́mite de tiempo alcanzado y una determinada como infactible. Se pudo comprobar la
convergencia visualmente y observar cómo el algoritmo fue capaz de mejorar sus soluciones
y escapar de espacios infactibles, incluyendo el comportamiento para la mas difı́cil de las
instancias. Dicha sección explica el ¿por qué? y ¿cómo? el algoritmo explora gráficamente el
espacio de búsqueda.
Al final del capı́tulo se presentó la comparativa entre los resultados encontrados por Gurobi
y la heurı́stica. Respecto a calidad la heurı́stica siempre fue capaz de encontrar el óptimo
para alguna ejecución. La cantidad de ejecuciones para las cuales no se encontró el óptimo
fue muy baja y, a partir de esto se puede concluir que en esos casos es suficiente ejecutar
la heurı́stica una vez más. En términos de tiempo la heurı́stica nunca superó los 15[s], y si se
pone en contraste con las instancias de mas de 1[hr] es notable la mejorı́a en varios órdenes
de magnitud.
CAPÍTULO
CONCLUSIONES
En este trabajo de tı́tulo se estudio a profundidad los problemas del Conference Scheduling
Problem (CoSP). Más especı́ficamente se consideró como caso de estudio las The Genetic
and Evolutionary Computation Conference (GECCO), una de las conferencias mas grandes e
importantes del área de investigación de algoritmos meta-heurı́sticos y genéticos. Este tra-
bajo presentó una formalización completa de la definición de las GECCO describiendo los
recursos, actores y restricciones asociadas considerando como foco principal la planificación
de la conferencia considerando la agrupación de artı́culos por temas o tracks.
Actualmente el proceso de planificación de este tipo de conferencia se lleva a cabo de for-

ma manual, lo que lo vuelve un proceso complicado y largo. Ası́, cumple con dos grandes
requisitos para ser candidato a una automatización.
En este trabajo se presentó un estudio del estado del arte, a partir del cual se entiende que
la literatura divide los problemas del CoSP en attender-based perspective (ABP) y presenter-
based perspective (PBP). Ası́, el problema de planificación de conferencias GECCO puede ser
clasificado en la segunda categorı́a. La literatura muestra una clara tendencia a preferir estu-
diar problemas basados en los asistentes, donde la mayorı́a de los artı́culos se enfocaban en
resolver ese tipo de problemas. De los pocos artı́culos referentes a la planificación de tracks,
[SPV18] presentó el estudio más relevante para este trabajo de tı́tulo. En este estudio, a pe-
sar de no resolver el mismo problema que este trabajo, entrega una definición formal y clara
de este tipo de problemas. Por otro lado, en la literatura se encontró una cantidad conside-
rable de aplicaciones de usuario para facilitar la planificación manual, ya sean aplicaciones
móviles para recolección de datos, sistemas de recomendación y hasta incluso herramientas
91
CAPÍTULO 7. CONCLUSIONES 92
de pizarra.
El trabajo de [SPV18] es complementario al de este trabajo y como trabajo futuro serı́a bueno
poder o bien extender el algoritmo de [SPV18] con las funcionalidades de el problema es-
tudiado en este trabajo, o bien extender la heurı́stica propuesta a las necesidades de las
conferencias EURO-K.
En este trabajo se presenta la definición formal del problema de planificación de conferencias

basadas en tracks. Incluye dos formalizaciones matemáticas con modelos de programación
lineal. El primero considera el proceso de planificación de sesiones de una forma simplifica-
da y ”más estricta“ que la segunda, ya que los expositores al tener menor libertad de movi-
miento, es decir, no permitirles cambiar de salones durante las sesiones, permite definir un
espacio de búsqueda de mucho menor tamaño. La segunda versión del modelo agrega una
dimensión adicional del tiempo para la planificación interna de las sesiones. Dichos modelos
son parcialmente intercambiables. El primero puede incluso ser de utilidad para cualquier
lector que desee planificar eventos con menos flexibilidad de movimiento. Por otro lado el
segundo modelo es más complejo, pero permite gracias a su granularidad encontrar solu-
ciones a problemas más especı́ficos. Este último modelo fue el utilizado durante todo este
trabajo de tı́tulo ya que representa el conjunto de instancias más complejas de resolver.
Este trabajo también presenta la propuesta de un acercamiento de búsqueda heurı́stica para

encontrar soluciones al problema en estudio. Se presenta ası́ un algoritmo Greedy seguido
de una busca local Simulated Annealing (SA) con recalentamiento. La propuesta utiliza cuatro
movimientos distintos, el intercambio de sesiones, cambio de chair, cambio de organizadores
y el intercambio de artı́culos. Todos estos necesarios para moverse en espacios factibles e
infactibles.
Ası́, se utiliza como función de evaluación la calidad de las soluciones respecto al uso de
espacio y la cantidad de restricciones incumplidas. Este último se multiplica por un factor lo
suficientemente alto para dar prioridad en su minimización. El algoritmo propuesto debido a
su estructura asegura que se usará la mı́nima cantidad de sesiones y que cada sesión estará
conformada por artı́culos de un mismo track, sin embargo, todo el resto de restricciones, ya
sea sesiones de un mismo track en simultáneo, personas en dos lugares a la vez y en tiempos
no preferidos, son minimizadas en la función de evaluación.
Además la propuesta del algoritmo presenta un SA atı́pico, donde los recalentamientos tie-
nen un aumento lineal-proporcional a la cantidad de iteraciones y no solo proporcional a la
temperatura previa (véase Capı́tulo 4).
En el capı́tulo de experimentos se presenta el escenario de experimentación propuesto para

evaluar los acercamientos. Acá se presenta el formato de las instancias de pruebas. Además
se presenta el generador de instancias artificiales similares a las GECCO. Se presentó tam-
bién un análisis preliminar de las caracterı́sticas (número de artı́culos, número de personas,
número de salones, número de bloques horarios, número de subslot, número de tracks y
cantidad de conflictos) de las instancias de pruebas y cómo la relación entre dichas carac-
terı́sticas podrı́an afectar a la dificultad de las instancias. Finalmente se presentó el proceso

de sintonización de parámetros del algoritmo heurı́stico.
El capı́tulo de la validación presenta los resultados experimentales de la evaluación de los

acercamientos propuestos en este trabajo. Se presentan los resultados obtenidos al utilizar
el solver matemático Gurobi y se contrastan con los resultados de la heurı́stica. A partir de
los resultados de gurobi es posible clasificar el conjunto de instancias propuestas en tres
categorı́as como instancias con óptimo conocido, con tiempo insuficiente para alcanzar el
óptimo e instancias infactibles.
Los resultados determinan que la heurı́stica es capaz de encontrar el óptimo para todas las
instancias con óptimo conocido Tabla 6.15. Por otro lado se encontró la cota inferior para
las instancias para las cuales se tuvo tiempo insuficiente y se conocı́a una cota Tabla 6.16,
mientras que para aquellas de tiempo insuficiente, pero sin información de cota, no se pue-
de saber si encuentra el óptimo, solo se puede saber que se obtuvieron soluciones factibles
y relativamente buenas comparadas a instancias similares. Para las instancias infactible los
resultaron indicaron, gracias a la función de evaluación y las penalizaciones de las insatisfac-
ciones de restricciones, que las soluciones encontradas en estos casos no estaban muy lejos
de ser factibles. En estos casos, las soluciones que obtuvo la heurı́stica, tenı́an a lo más 12
restricciones incumplidas.
Debido a que este trabajo presenta la primera heurı́stica utilizada para resolver este proble-
ma en particular no se tienen resultados de otro tipo de heurı́stica, por lo que únicamente
se puede concluir que es rápida respecto a un solver completo y no respecto a otro tipo de
heurı́sticas.
Por otro lado los resultados obtenidos con las configuraciones de parámetros obtenidas me-
diante la sintonización de parámetros no mostraron ninguna mejora considerable ni en ca-
lidad ni en tiempo respecto a los resultados obtenidos con la sintonización manual. Como
trabajo futuro se considera mejorar el proceso de sintonización utilizando un sintonizador
que no requiera discretizar los parámetros. Esto debido a que el trabajo actual limita la can-
tidad de parámetros a probar, cuando por ejemplo, tanto la tasa de enfriamiento es un valor
inherentemente real y no discreto. Además es importante evaluar los resultados finales sin
considerar el factor de penalización de infalibilidades para mejorar la comparación de resul-
tados.
Finalmente como trabajo futuro se podrı́a considerar extender el algoritmo para obtener los
parámetros adaptativamente, ya que como se vio en el Capı́tulo 6, Figura 6.4 ciertas instan-
cias tienen dificultad para encontrar el movimiento adecuado para salir de la infactibilidad.
Por otro lado, podrı́a considerarse extender este trabajo para artı́culos no clasificados (sin
track definido) y, mediante el uso de técnicas de clasificación, agrupar los artı́culos por tema
y complementarlos con el algoritmo ya propuesto. Además, podrı́a considerarse evaluar la
combinación de este trabajo con el de [SPV18] que propone la planificación ”macro“ de se-
siones en edificios y streams de forma de aumentar el nivel de automatización del proceso
de planificación de las conferencias EURO-K.
Por último, otra área de estudio más cercana serı́a el uso de modelos no-lineales para la re-
solución del problema, donde las últimas versiones de Gurobi han entregado mejorı́as en
tiempos de cómputo considerable en varios órdenes de magnitud. Este trabajo estudió pre-
liminarmente esos casos, pero se optó por no seguir esa lı́nea para mantener la consistencia
con los modelos lineales de la literatura.
BIBLIOGRAFÍA
[Sch99] A. Schaerf. ((A Survey of Automated Timetabling)). En: Artificial Intelligence Re-
view 13.2 (abr. de 1999), págs. 87-127. ISSN: 1573-7462. DOI: 10 . 1023 / A :
1006576209967.
[Sam04] Scott E. Sampson. ((Practical Implications of Preference-Based Conference Sche-
duling)). En: Production and Operations Management 13.3 (2004), págs. 205-215.
DOI: 10.1111/j.1937-5956.2004.tb00506.x.
[SMK04] J Schönberger, D.C Mattfeld y H Kopfer. ((Memetic Algorithm timetabling for
non-commercial sport leagues)). En: European Journal of Operational Research
153.1 (2004). Timetabling and Rostering, págs. 102-116. ISSN: 0377-2217. DOI:
https : / / doi . org / 10 . 1016 / S0377 - 2217(03 ) 00102 - 4. URL: https :
//www.sciencedirect.com/science/article/pii/S0377221703001024.
[GLV07] Joshua S. Gans, Andrew Leigh y Elena Varganova. ((Minding the shop: The case
of obstetrics conferences)). En: Social Science & Medicine 65.7 (2007), págs. 1458-1465.
ISSN: 0277-9536. DOI: https://doi.org/10.1016/j.socscimed.2007.05.
034.
[HHS07] F. Hutter, H. H. Hoos y T. Stützle. ((Automatic Algorithm Configuration based on
Local Search)). En: Proc. of the Twenty-Second Conference on Artifical Intelligen-
ce (AAAI ’07). 2007, págs. 1152-1157.
[Gré08] David Grémillet. ((Paradox of flying to meetings to protect the environment)).
En: Nature 455.7217 (oct. de 2008), págs. 1175-1175. DOI: 10.1038/4551175a.
[Hut+09] Frank Hutter y col. ((ParamILS: An Automatic Algorithm Configuration Frame-
work)). En: Journal of Artificial Intelligence Research 36 (oct. de 2009), págs. 267-306.
95
BIBLIOGRAFÍA 96
[Qu+09] Rong Qu y col. ((A survey of search methodologies and automated system de-
velopment for examination timetabling)). En: J. Scheduling 12 (feb. de 2009),
págs. 55-89. DOI: 10.1007/s10951-008-0077-5.
[LL10] Hsin-Yun Lee y Yu-Cheng Lin. ((A decision support model for scheduling exhibi-
tion projects in art museums)). En: Expert Systems with Applications 37.2 (2010),
págs. 919-925. ISSN: 0957-4174. DOI: https : / / doi . org / 10 . 1016 / j .
eswa.2009.03.003. URL: https://www.sciencedirect.com/science/
article/pii/S0957417409002504.
[Zha+13] Haoqi Zhang y col. ((Cobi: Communitysourcing Large-Scale Conference Sche-
duling)). En: CHI ’13 Extended Abstracts on Human Factors in Computing Sys-
tems. CHI EA ’13. Paris, France: Association for Computing Machinery, 2013,
págs. 3011-3014. ISBN: 9781450319522. DOI: 10.1145/2468356.2479597.
[Jan+15] Adam Janiak y col. ((A survey on scheduling problems with due windows)). En:
European Journal of Operational Research 242.2 (2015), págs. 347-357. ISSN:
0377-2217. DOI: https://doi.org/10.1016/j.ejor.2014.09.043.
[Gri+16] Carla F. Griggio y col. ((The UIST Video Browser: Creating Shareable Playlists of
Video Previews)). En: Proceedings of the 29th Annual Symposium on User In-
terface Software and Technology. UIST ’16 Adjunct. Tokyo, Japan: Association
for Computing Machinery, 2016, págs. 59-60. ISBN: 9781450345316. DOI: 10.
1145/2984751.2985703.
[Lau+16] Hoong Chuin Lau y col. ((PRESS: PeRsonalized Event Scheduling Recommender
System (Demonstration))). En: Proceedings of the 2016 International Conferen-
ce on Autonomous Agents & Multiagent Systems. AAMAS ’16. Singapore, Singa-
pore: International Foundation for Autonomous Agents y Multiagent Systems,
2016, págs. 1513-1515. ISBN: 9781450342391.
[Dos+17] Vishal Doshi y col. ((StickySchedule: An Interactive Multi-User Application for
Conference Scheduling on Large-Scale Shared Displays)). En: Proceedings of the
6th ACM International Symposium on Pervasive Displays. PerDis ’17. Lugano,
Switzerland: Association for Computing Machinery, 2017. ISBN: 9781450350457.
DOI: 10.1145/3078810.3078817.
[VMF17] Diego Vallejo-Huanga, Paulina Morillo y Cèsar Ferri. ((Semi-Supervised Cluste-
ring Algorithms for Grouping Scientific Articles)). En: Procedia Computer Science
108 (2017). International Conference on Computational Science, ICCS 2017, 12-
14 June 2017, Zurich, Switzerland, págs. 325-334. ISSN: 1877-0509. DOI: https:
//doi.org/10.1016/j.procs.2017.05.206.
[SPV18] Thomas Stidsen, David Pisinger y Daniele Vigo. ((Scheduling EURO-k conferen-
ces)). En: European Journal of Operational Research 270.3 (2018), págs. 1138-1147.
ISSN: 0377-2217. DOI: https://doi.org/10.1016/j.ejor.2017.10.015.
[Van+18] Bart Vangerven y col. ((Conference scheduling — A personalized approach)). En:
Omega 81 (2018), págs. 38-47. ISSN: 0305-0483. DOI: https://doi.org/10.
1016/j.omega.2017.09.007.
BIBLIOGRAFÍA 97
[CVC19] F. Castaño, N. Velasco y J. Carvajal. ((Content-Based Conference Scheduling Opti-

mization)). En: IEEE Latin America Transactions 17.04 (abr. de 2019), págs. 597-606.
ISSN: 1548-0992. DOI: 10.1109/TLA.2019.8891884.
[MMW20] Mike Morrison, Kelsey Merlo y Zach Woessner. ((How to Boost the Impact of
Scientific Conferences)). En: Cell 182.5 (2020), págs. 1067-1071. ISSN: 0092-8674.
DOI: https://doi.org/10.1016/j.cell.2020.07.029.
[Neu+20] Sabrina Neugebauer y col. ((How sustainable are sustainability conferences? –
Comprehensive Life Cycle Assessment of an international conference series in
Europe)). En: Journal of Cleaner Production 242 (2020), pág. 118516. ISSN: 0959-
6526. DOI: https://doi.org/10.1016/j.jclepro.2019.118516.
[BCS21] Teobaldo Bulhões, Rubens Correia y Anand Subramanian. ((Conference sche-
duling: A clustering-based approach)). En: European Journal of Operational Re-
search (2021). ISSN: 0377-2217. DOI: https://doi.org/10.1016/j.ejor.
2021.04.042. URL: https://www.sciencedirect.com/science/article/
pii/S0377221721003775.
[Zha+21] Wenyi Zhang y col. ((Optimization of single-line bus timetables considering time-
dependent travel times: A case study of Beijing, China)). En: Computers & Indus-
trial Engineering 158 (2021), pág. 107444. ISSN: 0360-8352. DOI: https://doi.
org/10.1016/j.cie.2021.107444. URL: https://www.sciencedirect.
com/science/article/pii/S036083522100348X.

3560902039074UTFSM

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

3560902039074UTFSM

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TECNICA FEDERICO SANTA MARIA

Peumo Repositorio Digital USM https://repositorio.usm.cl

ENFOQUE METAHEURÍSTICO PARA

RIQUELME MACÍAS, FABIÁN MARCELO GUILLERMO

“ENFOQUE METAHEURÍSTICO PARA LA PLANIFICACIÓN

FABIÁN MARCELO GUILLERMO

MEMORIA PARA OPTAR AL TÍTULO DE

Profesor Guı́a: Elizabeth Montero

Quisiera agradecer a mi familia; especialmente a mi papá Daniel Riquelme Celis y mi mamá

2 Deﬁnición del problema 12

2.1 Conferencia ilustrativa de 24 artı́culos, 3 tracks, 3 bloques horarios y 2 salones. 13

4.1 Programa construido mediante asignación secuencial izquierda-derecha arriba-

6.1 Visualización de FreeViz: Correlación de variables respecto al objetivo del

3.1 Restricciones duras comunes para el Examination Timetabling . . . . . . . . 32

5.1 Las 45 instancias seleccionadas. . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.10 Resultados heurı́sticos para 12 instancias determinadas como infactibles. 25

1 Construcción aleatoria de artı́culos en sesiones. . . . . . . . . . . . . . . . . . 43

9 Comportamiento general del generador de instancias . . . . . . . . . . . . . 59

ABP attender-based perspective. 4, 18, 32, 35, 37, 41, 91

B&B Branch & Bound. 31

CoSP Conference Scheduling Problem. 12, 30, 32, 54, 91

EMO Evolutionary Multiobjective Optimization. 14, 17

ILS Iterated Local Search. 64

PBP presenter-based perspective. 32, 33, 35, 38, 39, 41, 91

RWA Real World Applications. 16, 17

SA Simulated Annealing. 8, 31, 38, 45, 47, 49, 52, 83, 92

El problema a tratar en este documento consiste en la formulación, diseño y estudio de un

Las diﬁcultades y necesidades de este problema radican principalmente en la diversidad y

En este trabajo de memoria se propone un modelo matemático de programación lineal para

DEFINICIÓN DEL PROBLEMA

2.1. Problema de la Planiﬁcación de Conferencias basadas en

El CoSP corresponde a un problema de programación (Scheduling), para el cual se necesita

Figura 2.1: Conferencia ilustrativa de 24 artı́culos, 3 tracks, 3 bloques horarios y 2 salones.

2.2. The Genetic and Evolutionary Computation Conference

Monday Monday Monday Tuesday Tuesday Tuesday Wednesday

Sessions with best

Figura 2.2: Planiﬁcación de la GECCO 2019

junto de artı́culos sean planiﬁcados dentro de un programa en sesiones distribuidas espacio-

Figura 2.3: Diagrama de clases del problema (UML)

A continuación se presentan las principales componentes del problema.

Figura 2.4: Pequeño programa de 15 sesiones y 5 tracks

Una sesión es un conjunto de artı́culos de un mismo track. Históricamente dentro de las

Multiobjective Shape Design in a Ventilation System with a Preference-driven Surrogate-

A Hybrid Evolutionary Algorithm Framework for Optimisin...

A Novel Hybrid Scheme Using Genetic Algorithms...

Multiobjective Shape Design in a Ventilation System....

Figura 2.5: Detalles de la composición de una sesión

2.2.6. Mejores Artı́culos

Los mejores artı́culos corresponden a artı́culos nominados a participar por un reconocimien-

2.2.7. HUMIES, ECIP y HOP

2.4. Especiﬁcación del problema

A continuación se procederá a enumerar las especiﬁcaciones más importantes al momento

En resumen el problema se vuelve uno de asignar artı́culos en sesiones y sesiones en la

Se necesita optimizar la asistencia para los artı́culos nominados a “mejor artı́culo” a

Se necesita minimizar la cantidad de sesiones, lo que implica minimizar la cantidad de

Se necesita que dos artı́culos de un mismo expositor estén idealmente separados al

2.5. Solución actual

Actualmente hay 36 organizadores, 26 chairs y cerca de 90 encargados del comité de planiﬁ-

2.6. Modelo matemático

A lo largo de esta sección se presenta un modelo matemático que considera, en primera

2.6.1. Modelo simpliﬁcado

Para el modelo se necesita manejar la asignación de artı́culos a sesiones xas , la asignación de

xas ∈ (0, 1) = Artı́culo a se agenda en sesión s

σpsrb ∈ (0, 1) = La persona p se encuentra en la sesión s ubicada en (r,b) (2.3)