Generazione dello Shortest Path Graph ed applicazione dei metodi di riduzione

Marco Cella Marco Pighin

Universit` degli studi di Trieste a Anno Accademico 2010-2011

Sommario Questa relazione presenta e descrive la realizzazione di una applicazione in linguaggio Java che genera lo shortest path graph multicommodity, applica le riduzioni per archi e per percorsi allo shortest path graph, come descritto in (Bouhtou et al., 2007), e crea i le di input per diverse formulazioni del problema Network Pricing Problem (NPP).

Introduzione

Il Network Pricing Problem (NPP) presenta alcune formulazioni esatte per archi (Labb et al., 1998), (Bouhtou e et al., 2007) e per percorsi (Bouhtou et al., 2007), inoltre sono state studiate formulazioni euristiche (Roch et al., 2005), (Brotcorne et al., 2000), (Brotcorne et al., 2001). Tutte queste formulazioni devono acquisire la struttura dello shortest-path graph model (SPGM) al quale devono essere applicate le regole di riduzione per archi e per percorsi, come viene spiegato nellarticolo (Bouhtou et al., 2007) al capitolo 4. Le ipotesi di lavoro impongono: grafo ridotto applicato al caso multicommodity, generazione di tutti i dati nelle formattazioni richieste per le varie formulazioni. Riguardo la prima fase del progetto, cio` la generazione dello shortest-path graph model (SPGM), abbiamo e seguito una realizzazione dierente da quella proposta da (Bouhtou et al., 2007) al capitolo 3; in particolare non andiamo a creare un grafo orientato generico (di dimensione opportuna) e successivamente ridotto tramite lapplicazione dellalgoritmo di Dijkstra; abbiamo invece scelto di generare subito il grafo ridotto, conoscendo le regole che specicano il numero e la posizione degli archi allinterno del grafo ridotto (capitolo 3). Questa soluzione, pur non attenendosi in modo completo alla teoria, non perde in generalit` anzi, nel caso fosse necessario, a permette un controllo diretto sui percorsi creati e sulla distribuzione dei costi ssi negli archi; il problema della distribuzione dei costi ssi non ` da sottovalutare perch` incide nellapplicazione delle proposizioni relative le e e riduzioni per archi e per percorsi, nonch` nellesecuzione stessa delle formulazioni. e Per completezza ` utile ricordare che la riduzione di un grafo orientato generico in un grafo ridotto per la singoe la commodity avviene applicando lalgoritmo di Dijkstra al grafo generico, quindi calcolando i percorsi a costo minimo dalla sorgente alla coda di ogni arco con taria e dalla testa di ogni arco con taria alla destinazione; ognuno di questi percorsi a costo minimo sar` quindi sostituito da un arco con costo sso pari al costo del a percorso a costo minimo associato. Nel caso multicommodity, ogni commodity (relativa ad un nodo sorgente ed un nodo destinazione) dovr` applicare la riduzione tramite Dijkstra a partire dal grafo generico. a

Limiti del software e miglioramenti

Lapplicazione relativa il progetto ` stata sviluppata con il linguaggio di programmazione Java e testata su JRE e 6. Tutti i punti che costituiscono il progetto sono stati accorpati in un unico sorgente in quanto le varie fasi di esecuzione dellapplicazione sono sequenziali, inoltre la struttura delle classi ausiliarie risulta contenuta. Come scelta di progetto, la memorizzazione e gestione dello shortest path graph avviene per percorsi; ovviamente questa scelta ha portato a denire strutture dati appropriate e relative scelte risolutive. Questa soluzione non ` sembrata eccessiva inizialmente per le capacit` di calcolo della macchina server su cui lapplicazione deve e a essere eseguita. Nella progettazione dellapplicazione tuttavia, si sono incontrate diverse dicolt` e necessari a adeguamenti di progetto; di seguito sono trattati i limiti riscontrati nella applicazione; il problema che maggiormente limita lapplicazione riguarda loccupazione della memoria; per evitare questo ostacolo sarebbe necessaria una formulazione per archi per lintero progetto. Durante la fase di test della prima versione del programma abbiamo riscontrato alcuni limiti quali: 1

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

indici per le strutture dati di tipo int (32 bit) uso ridondante della memoria ram/heap Il primo punto in particolare pone un limite alla dimensione delle strutture dati utilizzate, soprattutto nella memorizzazione del totale dei percorsi; un indice di tipo int risulta insuciente nel caso di generazione di gra di dimensioni medie e grandi; in modo indicativo con un grafo ridotto avente un numero di archi con taria superiore a 10, un indice di 32 bit non permette di indicizzare tutti i percorsi. Per risolvere questo problema si sono dovuti introdurre: indici per le strutture dati di tipo long (64 bit) paginazione delle strutture dati Nel linguaggio Java lindicizzazione degli array e delle Collections avviene mediante indici di tipo int; quindi per risolvere il problema degli indici a 32 bit si ` dovuto introdurre il concetto di paginazione; le strutture dati e array permettono di implementare la paginazione senza dover riprogettare il codice e di conseguenza ` stata e applicata una estensione alla prima versione del programma. La seconda versione del programma presenta un uso corretto e completo della paginazione sulle strutture dati interessate dal problema; inoltre ` stato realizzato un primo miglioramento nelle prestazioni computazionali, e relativo singole procedure che necessitano scorrere gli indici di tutti i percorsi. Nel caso in cui lindicizzazione a 64 bit risulti ancora insucente, sar` necessario sostituire gli indici long con la a classe BigInteger, oppure la classe BigDecimal, che permettono di superare il limite dei 64 bit. In realt` questa a eventualit` non si presenta nella esecuzione del programma sul server, a causa dei limiti tecnici del server ed i a limiti di progetto della applicazione. Riguardo loccupazione della memoria ram da parte del programma, un primo vincolo cui ci siamo attenuti riguarda la realizzazione e la gestione di tutte le strutture dati nella ram; questa scelta, che porta notevoli vantaggi computazionali, purtroppo porta forti limitazioni nella scalabilit` del problema. La limitazione viene a posta in evidenza dalla JVM che, nel caso di un numero di archi con taria superiore a 12, visualizza sul terminale il seguente messaggio di errore: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space Questo problema ` legato a limitazioni della dimensione della ram nel server; il problema non ` stato risolto e e e le soluzioni possono essere diverse: uso di una partizione di swap swap su le gestita dal sistema operativo swap su le gestita dalla JVM attraverso serializzazione dei dati Lultima delle soluzioni proposte prevede luso di un le, gestito dallapplicazione, per realizzare uno swap sico delle strutture dati non utilizzate. A parte i problemi realizzativi di una tale soluzione, risulta molto pesante dal punto di vista computazionale in quanto le strutture dati pi` estese sono usate frequentemente. u Fatto presente che il codice del programma pu` essere migliorato sia per quanto riguarda il numero e la dimeno sione delle strutture dati, che nelle prestazioni di calcolo, il programma risulta corretto ed il suo comportamento predicibile e testabile ad ogni passo in quanto applica la teoria come presentata nellarticolo (Bouhtou et al., 2007), adattandosi al pi` alle strutture dati create. u

Regole di creazione dello Shortest-Path Graph

Come gi` introdotto, in questo progetto andiamo a creare il grafo ridotto quindi gli archi ed i percorsi, non a ottenuto applicando lalgoritmo di Dijkstra ad un generico grafo orientato. La disposizione dei nodi, il numero e la collocazione degli archi nel grafo ridotto seguono regole ben denite, elencate di seguito: per ogni commodity sono deniti in modo univoco un nodo di origine e un nodo di destinazione i nodi sorgente sono nodi di coda per archi a costo sso i nodi destinazione sono nodi di testa per archi a costo sso nei nodi sorgente non possono entrare archi, mentre nei nodi di destinazione non posoono partire archi

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

il numero di nodi intermedi ` dato da 2 t, con t il numero di archi con taria e ogni arco con taria ha deve avere un nodo di partenza ed un nodo di arrivo, scelti tra i nodi intermedi ogni nodo intemedio pu` essere nodo di coda di un solo arco con taria o il nodo di testa di un arco con taria non pu` essere nodo di coda per un altro arco con taria o il nodo di coda di un arco con taria non pu` essere nodo di partenza per archi a costo sso o il nodo di testa di una arco con taria pu` essere un nodo di partenza per archi a costo sso o i nodi sorgente possono essere collegati solo con i nodi di coda degli archi con taria i nodi destinazione possono essere collegati solo con i nodi di testa degli archi con taria per ogni commodity, il nodo sorgente ed il nodo destinazione sono collegati da un arco a costo sso chiamato toll free path.

Figura 1: SPGM generico con 3 archi con taria ed 1 commodity La Figura 1 mostra un grafo ridotto per 1 commodity, quindi con 1 nodo sorgente ed 1 nodo destinazione, con 3 archi con taria rappresentati con archi tratteggiati e con tutti i possibili archi a costo sso. Si pu` altres` vericare quanto segue: o Nel grafo ridotto non possono esistere due archi a costo sso consecutivi Quando nel generico grafo orientato compaiono due archi con taria consecutivi, questi possono sempre essere separati da un arco a costo sso nullo Riguardo il primo punto: se nel grafo ridotto fossero presenti archi a costo sso consecutivi, questi potrebbero sempre essere sostituiti da un unico arco a costo sso con nodo di partenza il nodo di coda del primo arco a costo sso della sequenza e come nodo di arrivo il nodo di testa dellultimo arco a costo sso della sequenza. Questa aermazione risulta corretta qualsiasi sia la sequenza degli archi a costo sso considerata. Riguardo il secondo punto: da un punto di vista generale, in un generico grafo orientato possono comparire due archi con taria consecutivi; per attenersi tuttavia al modello di grafo ridotto presentato dobbiamo imporre che non possano esistere archi con taria in sequenza. Questa assunzione non limita la generalit` del problema, in a quanto si pu` sempre aggiungere (nel grafo generico) un nodo ed un arco a costo sso nullo per adeguarsi al o modello presentato.

Passi di elaborazione e Strutture dati

Premessa: tutte le strutture dati descritte non faranno riferimento alla soluzione con paginazione (seconda versione del programma), in relazione ad una migliore comprensione dellalgoritmo. Il programma in esecuzione si aspetta in input i seguenti dati: numero di archi con taria t 3

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

numero di commodities c Non sono necessari ulteriori dati di partenza, in particolare il numero totale di nodi del grafo ridotto ` deducibile e dai dati forniti. Una prima struttura dati, che verr` usata solo in fase di creazione dei le di input per le formulazioni, ` lara e ray int occorrenze[c], in cui si assegnano in modo casuale il numero di clienti associati ad ogni singola commodity. Il programma esegue quindi i seguenti passi di elaborazione in sequenza: Stabilire gli indici dei nodi relativi le commodities (nodi sorgente, nodi destinazione) e dei nodi intermedi Creazione di tutti gli archi del grafo ridotto ed i costi ssi (regole di creazione, capitolo 3) Ogni singola commodity deve quindi: Generare tutti i percorsi per la data commodity, relativi lo shortest-path graph Applicare le riduzioni allo shortest-path graph (per archi e per percorsi) Il primo passo di elaborazione deve assegnare ad ogni nodo del grafo ridotto un indice univoco; non ` stata e usata una assegnazione arbitraria, la struttura delle assegnazioni ` descritta in Tabella 1. e 1 Nodi Sorgente c c+1 Nodi Destinazione 2c 2c+1 Nodi Intermedi 2c+2t Tabella 1: Indice dei nodi del grafo ridotto Questa formulazione delle assegnazioni ha permesso di creare e gestire diverse strutture dati, descritte nel seguito, mediante luso degli indici dei nodi; relativamente la fase di creazione degli archi ` particolarmente e comodo riuscire a riconoscere gli archi con taria in base il nodo di coda ed il nodo di testa, i cui indici sono stati assegnati rispettivamente con i valori: indice del nodo di coda dellarco con taria i : 2c + 2i + 1 indice del nodo di testa dellarco con taria i : 2c + 2i Il secondo passo di elaborazione prevede la generazione di tutti gli archi del grafo ridotto, in accordo con le regole di creazione riportate nel capitolo 3, e lassegnazione del costo per ogni arco a costo sso. Innanzi tutto ` necessaria una precisazione: le varie formulazioni del problema Network Pricing Problem (NPP), e cui si ` fatto riferimento precedentemente, si distinguono in formulazioni che prevedono o meno il costo sso per e gli archi con taria. In questo progetto abbiamo previsto la propriet` costo sso anche per gli archi con taria, a a vantaggio sia della realizzazione che della formulazione; in fase di creazione dei le di input per le diverse formulazioni si potr` scegliere se usare o meno questa propriet`. a a La struttura scelta per contenere le propriet` di tutti gli archi generati per il grafo ridotto ` un array di istanze a e della classe Arco, i cui attributi sono elencati in Tabella 2. Come per gli indici dei nodi, anche gli indici degli archi presentano una particolare struttura che permette loro di essere facilmente reperibili; questa ` specicata in Tabella 3. e Il numero totale degli archi per il grafo ridotto sar` quindi (2c + t)t + c. a Con archi intermedi si intendono tutti gli archi a costo sso uscenti dai nodi di testa degli archi con taria. Ancora una volta specichiamo che deve esistere un unico toll free path per ciascuna commodity. Per una corretta esecuzione delle successive fasi di riduzione dello shortest-path graph per archi e per percorsi, ` necessario imporre inizialmente costo sso nullo per ogni arco con taria; solo al termine delle fasi di riduzione e 4

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

tipo int int int boolean boolean boolean int

attributo partenza arrivo costo taria sorgente destinazione lunghezza

descrizione indice del nodo di partenza indice del nodo di arrivo costo sso dellarco ag che indica se ` un arco a taria e ag che indica se larco ` uscente da una sorgente e ag che indica se larco ` entrante in una destinazione e lunghezza dellarco con taria Tabella 2: Attributi della classe Arco

per ogni arco con taria

Arco con taria Archi dalle sorgenti

i(2c + t) 1 + i(2c + t) c + i(2c + t) c + 1 + i(2c + t)

Archi alle destinazioni 2c + i(2c + t) 2c + 1 + i(2c + t) Archi intermedi 2c + t + i(2c + t) ... t(2c + t) Toll free path t(2c + t) + c 1

Tabella 3: Indice degli archi nel grafo ridotto sar` possibile assegnare il costo sso agli archi con taria, questo per non creare discrepanze nellesecuzione a delle tecniche di riduzione per le diverse formulazioni. La scelta del costo di ogni arco a costo sso non pu` essere completamente aleatoria, infatti una distribuzione o non opportuna potrebbe causare una drastica se non totale riduzione del numero di percorsi attivi durante lapplicazione delle regole di riduzione dello shortest path graph. Alcune regole indicative da seguire per assegnare il costo agli archi a costo sso sono le seguenti: il costo del toll free path deve essere almeno superiore la media dei costi dei percorsi pesata sulla lunghezza dei percorsi il costo degli archi uscenti dalle sorgenti ed il costo degli archi entranti nelle destinazioni deve essere maggiore del costo degli archi a costo sso intermedi i costi degli archi non devono essere raggruppati attorno ad una media Prima di passare alla fase di generazione dei percorsi per ogni commodity, si deve introdurre una ulteriore struttura dati a livello globale: la struttura ArrayList<proprietaPercorso> proprieta, che contiene la lista di tutti i percorsi per ogni commodity che hanno superato le fasi di riduzione e che chiameremo per semplicit` percorsi a attivi globali. Ogni elemento di questa lista ` una istanza della classe proprietaPercorso, i cui attributi sono e descritti in Tabella 4.

tipo int Arco int int

attributo archiLenght archi[ ] costo commodity

descrizione numero di archi del percorso array degli archi che compongono il percorso costo sso del percorso commodity associata al percorso

Tabella 4: Attributi della classe proprietaPercorso

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

Questa struttura dati ` necessaria infatti permetter` di ottenere la lista degli archi attivi, richiesta nella formue a lazione per archi, e permetter` di adattare le soluzioni ottenute alle diverse formulazioni. a Nel terzo passo di elaborazione ogni commodity deve costruire tutti i possibili percorsi sul grafo ridotto ottenuto in precedenza; la soluzione proposta prevede una struttura dati array Arco percorsi[ ][ ] che mantiene la sequenza dei percorsi creati per la singola commodity; inoltre ` stata inserita una struttura dati array int percorsiNodi[ e ][ ] che tiene traccia dei percorsi per indice dei nodi. Questa seconda struttura dati pu` in eetti risultare o rindondante ed in eetti il suo uso ` limitato allo svolgimento di alcune proposizioni riguardanti le riduzioni sul e grafo ridotto. Lalgoritmo per la creazione dei percorsi relativi una singola commodity viene riportato di seguito; questo algoritmo si relaziona con una struttura dati array int archiTariaContatore[t] che memorizza lindice del nodo di coda degli archi con taria selezionati ed implementa una sorta di contatore per i percorsi in base agli archi con taria attraversati; i percorsi infatti si distinguono principalmente in base al numero e lordinamento allinterno del percorso degli archi con taria scelti.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 indice = 0 Finch indicePercorso < totalePercorsi : Se indice == t allora decrementa(indice) incrementa ArchiTariffaContatore [indice] Se indice > 0 allora: Ripeti : Se larco selezionato gi presente nellarray allora incrementa lindice dellarco con tariffa Finch larco selezionato presente nellarray e non stato raggiunto lultimo arco con tariffa. Se larco selezionato ha indice > dellindice dellultimo arco con tariffa Allora azzera ArchiTariffaContatore[indice]; decrementa(indice) Inserisci il percorso: Matrice dei percorsi per archi, Matrice dei percorsi per nodi incrementa(indicePercorso) incrementa(indice)

Lalgoritmo di creazione dei percorsi presentato deve rispettare in sequenza i seguenti vincoli per la creazione di ogni percorso: il numero di archi con taria nel percorso linsieme degli archi con taria distinti del percorso lordine degli archi con taria allinterno del percorso Sono utili alcune considerazioni riguardo il pseudocodice appena introdotto. Il parametro totalePercorsi si riferisce al numero totale di tutti i possibili percorsi per una singola commodity; questo valore viene calcolato mediante una particolare procedura che calcola il numero dei percorsi che attraversano y archi con taria per y = 1..t ed aggiorna il valore totalePercorsi ad ogni ciclo. Riportiamo il codice Java relativo il calcolo di totalePercorsi :
1 2 3 4 5 6 7 8 9 int prodotto = 1; int totale_percorsi = 0; for (int y = 1; y <= t; y++) { prodotto = 1; for (int w = 0; w < y; w++) { prodotto = prodotto * (t - w); } totale_percorsi += prodotto; }

La variabile indice introdotta nel pseudocodice ` un indice intero che permette di selezionare una data posizione e dellarray ArchiTariaContatore e si comporta come indicatore della posizione corrente del contatore degli archi con taria. Nel momento di andare a creare un nuovo percorso, il contatore sugli archi con taria permette di tenere traccia del percorso precedente: si dovr` dunque vericare la possibilit` di inserire un ulteriore arco con taria rispetto a a 6

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

il percorso precedente (e che larco con taria non sia gi` presente nel percorso), in caso contrario dovr` essere a a selezionato un diverso arco con taria nella posizione corrente (indice) dellarray; inoltre, nel caso in cui sia stato raggiunto lultimo arco con taria nella posizione corrente del contatore, al successivo passo si dovr` elia minare lultimo arco con taria del percorso e la variabile indice dovr` puntare allarco con taria precedente a del percorso. Lesecuzione di questo algoritmo ` veloce dal punto di vista computazionale e leggero nelle strutture dati usate, e infatti tutte le operazioni vengono svolte su un semplice array e non sono presenti cicli annidati. Bisogna fare presente che solamente per la prima commodity ` necessario costruire tutti i percorsi attravere so questo algoritmo; tutte le commodity successive dovranno solamente aggiornare il nodo sorgente per larco iniziale ed il nodo di destinazione per larco nale di ogni percorso creato. Questo ` possibile perch` larray e e percorsi non verr` modicato nelle successive fasi di riduzione, invece verr` utilizzata una seconda struttura di a a supporto. La struttura dati in questione ` ArrayList<Int> percorsiAttivi, il cui compito ` tenere traccia degli indici dei e e percorsi attivi per la specica commodity; ogni qualvolta dovranno essere eliminati percorsi associati alla commodity, sar` quindi necessario eliminare lindice del percorso dalla struttura percorsiAttivi. a Prima di passare alla successiva fase di elaborazione riguardante le tecniche di riduzione, ` possibile applicare e una prima scelta sui percorsi attivi per la commodity, andando ad esempio a popolare la struttura percorsiAttivi con gli indici dei percorsi presi con una data probabilit` di inserimento. a La successiva fase di elaborazione prevede lapplicazione delle proposizioni relative le riduzioni per archi e per percorsi come descritte nellarticolo (Bouhtou et al., 2007) al capitolo 4; le proposizioni ed i relativi pseudocodici vengono presentati nel capitolo 5. Lultima fase di elaborazione prevede la generazione dei le di input per le diverse formulazioni; si ` scelto di e dare la possibilit` ai vari gruppi di usufruire di formattazioni dei le di testo o le dati personalizzate, infatti a lalgoritmo mette a disposizione tutte le strutture dati necessarie per estrapolare i dati occorrenti per tutte le formulazioni.

Regole di riduzione dello Shortest-Path Graph

Vengono ora presentate le regole di riduzione per archi e per percorsi come descritte nellarticolo (Bouhtou et al., 2007) al capitolo 4 e, per ognuna di esse, la soluzione adottata in questo progetto in pseudocodice. Si introducono due concetti: uij lij costo dello shortest path dal nodo i al nodo j usando solo archi a costo sso costo dello shortest path dal nodo i al nodo j usando possibilmente archi a taria, quando le tarie sono poste a zero

Una prima osservazione riguarda le caratteristiche dellimplementazione della riduzione per archi: per attenersi alla formulazione ed alle strutture dati scelte, nella applicazione delle proposizioni relative la riduzione per archi verranno eliminati percorsi piuttosto che archi; la validit` della soluzione adottata rimane comunque vericata a infatti eliminare un arco implica eliminare tutti i percorsi che passano per quel dato arco.

5.1

Riduzione per archi

Proposizione 1 Se ljt = ujt allora ogni percorso ottimo da s a t che usa il nodo j pu` usare larco (j, t). o Tutti gli altri archi che partono dal nodo j possono essere eliminati. Esempio (Figura 2) Qualsiasi percorso ottimo da 1 a 3 che usa il nodo 6, passa per larco (6,3). Secondo la proposizione possiamo eliminare tutti gli archi uscenti dal nodo 6 a parte appunto (6,3). Quindi per la nostra formulazione signica

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

Figura 2: esempio proposizione 1 che possiamo eliminare tutti i percorsi che passano per il nodo 6 e non utilizzano (6,3). Pseudocodice
1 2 3 4 5 6 7 8 9 Per ogni arco finale (destinazione == true) consideriamo il suo nodo inziale j Per ogni percorso Se attraversa j Allora: calcoliamo la somma dei costi fissi fino alla destinazione tieni traccia del percorso analizzato Calcola minimo tra le somme cos ottenute (l_jt). Se costo arco finale diretto u_jt < l_jt Allora elimina tutti i percorsi di cui si tenuto traccia

Proposizione 2 Se lsi = usi allora ogni percorso ottimo da s a t che usa il nodo i pu` usare larco (s, i). o Tutti gli altri archi che entrano nel nodo i possono essere eliminati. Esempio (Figura 3)

Figura 3: esempio proposizione 2 Qualsiasi percorso ottimo da 1 a 3 che usa il nodo 5, passa per larco (1,5). Tutti gli altri archi che entrano nel nodo 5 possono essere eliminati. Si possono quindi eliminare tutti i percorsi che passano per il nodo 5 e non usano larco (1,5). Pseudocodice
1 2 3 4 5 6 7 8 9 Per ogni arco iniziale (sorgente == true) consideriamo il suo nodo finale i Per ogni percorso Se attraversa i Allora: calcoliamo la somma dei costi fissi dalla sorgente fino a i tieni traccia del percorso analizzato Calcola minimo tra le somme cos ottenute (l_si). Se costo arco iniziale diretto (u_si) < l_jt Allora elimina tutti i percorsi di cui si tenuto traccia

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

Proposizione 3 Consideriamo due archi con taria (i1 , j1 ) e (i2 , j2 ). Se uj1 t uj1 i2 + lj2 t allora possiamo eliminare larco (j1 , i2 ). Esempio (Figura 4)

Figura 4: esempio proposizione 3 Con lj2 t calcolato come il costo del percorso (7,8) (8,9) (9,10) (10,3), possiamo dunque eliminare larco (6,7) e tutti i percorsi passanti per gli archi (5,6), (6,7), (7,8) attraversati in questordine. Pseudocodice
1 Per ogni arco finale (destinazione == true, u_j1t) 2 seleziona larco con tariffa con arrivo nel nodo j1 (i1,j1) 3 Per ogni arco con tariffa 4 Se diverso da (i1,j1) 5 Allora seleziona arco con tariffa (i2,j2) 6 Per ogni percorso 7 Se attraversa larco con tariffa (i2,j2) passando per larco (j1,i2) Allora: 8 calcola la somma dei costi fissi da j2 fino a t 9 tieni traccia del percorso 10 calcola il minimo tra le somme ottenute (l_j2t) 11 Se l_j2t + u_j1i2 > u_j1t 12 Allora elimina tutti i percorsi di cui si tenuto traccia

Proposizione 4 Consideriamo due archi con taria (i1 , j1 ) e (i2 , j2 ). Se usi1 uj2 i1 + lsi2 allora possiamo eliminare larco (j2 , i1 ). Esempio (Figura 5)

Figura 5: esempio proposizione 4 Con lsi2 calcolato come il costo del percorso formato dallunico arco (1,7), possiamo dunque eliminare lSarco (8,5) e quindi anche tutti i percorsi che attraversano gli archi (7,8), (8,5), (5,6) in questordine. Pseudocodice
1 2 3 4 Per ogni arco iniziale (sorgente == true, u_si1) seleziona larco con tariffa con partenza nel nodo i1 (i1,j1) Per ogni arco con tariffa Se diverso da (i1,j1)

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

5 6 7 8 9 10 11 12

Allora seleziona arco con tariffa (i2,j2) Per ogni percorso Se attraversa larco con tariffa (i1,j1) passando per larco (j2,i1) Allora: calcola la somma dei costi fissi da s fino a i2 tieni traccia del percorso calcola il minimo tra le somme ottenute (l_si2) Se l_si2 + u_j2,i1 > u_si1 Allora elimina tutti i percorsi di cui si tenuto traccia

Proposizione 5 Se ust lsi1 + lj1 t allora possiamo eliminare larco con taria (i1 , j1 ). Esempio (Figura 6)

Figura 6: esempio proposizione 5 Con lsi1 calcolato come il costo del percorso (1,9) (9,10) (10,5) e lj1 t calcolato come il costo del percorso formato dallunico arco (6,3). Larco con taria (5,6) pu` quindi essere eliminato. Allo stesso tempo si possono o eliminare tutti i percorsi che passano per larco (5,6). Pseudocodice
1 2 3 4 5 6 7 8 Per ogni arco con tariffa (i1,j1) Per ogni percorso Se attraversa (i1,j1) Allora: calcola la somma di tutti i costi fissi da s a t tieni traccia del percorso calcola il minimo tra le somme ottenute (l_si1 + l_j1t) Se l_si1 + l_j1t > u_st Allora elimina tutti i percorsi di cui si tenuto traccia

Proposizione 6 Consideriamo due archi con taria (i1 , j1 ) e (i2 , j2 ). Se ust lsi1 +uj1 i2 +lj2 t allora possiamo eliminare larco (j1 , i2 ). Esempio (Figura 7)

Figura 7: esempio proposizione 6 Con lsi1 calcolato come costo del percorso (1,9) (9,10) (10,5) e calcolato lj2 t come il costo del percorso formato dal solo arco (10,3), larco (6,7) pu` quindi essere eliminato. Allo stesso tempo si possono eliminare o tutti i percorsi che utilizzano gli archi (5,6), (6,7), (7,8) in questordine. Pseudocodice 10

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

1 Per ogni arco con tariffa (i1,j1) 2 Per ogni arco con tariffa 3 Se larco con tariffa diverso da (i1,j1) Allora: 4 seleziona larco con tariffa corrente (i2,j2) 5 Per ogni percorso 6 Se attraversa (i2,j2) passando per (j1,i2) Allora: 7 calcola la somma (Sx) di tutti i costi fissi da s a i1 8 calcola la somma (Dx) di tutti i costi fissi da j2 a t 9 tieni traccia del percorso 10 calcola il minimo tra le somme ottenute (Sx) (l_si1) 11 calcola il minimo tra le somme ottenute (Dx) (l_j2t) 12 Se l_si1 + l_j2t + u_j1i2 > u_st 13 Allora elimina tutti i percorsi di cui si tenuto traccia

5.2

Riduzione per percorsi

Denizione Se possiamo sostituire in tutte le soluzioni ammissibili il percorso q con il percorso p senza violare i vincoli e senza diminuire il valore della funzione obiettivo, allora il percorso p domina il percorso q. Siano: Tp cp linsieme degli archi con taria del percorso p il costo totale degli archi a costo sso del percorso p

Proposizione 7 Consideriamo i percorsi p e q. se Tp Tq e cq cp allora il percorso p domina il percorso q per ogni valore delle tarie. Esempio (Figura 8)

Figura 8: esempio proposizione 7 Il percorso p domina il percorso q per ogni valore della taria sullarco (7,8), perci` possiamo eliminare il pero corso q. Pseudocodice
1 2 3 4 5 6 7 Per ogni percorso (p) salviamo i suoi archi con tariffa T_p Per ogni percorso (q) Se diverso da p Se T_p contenuto in T_q Se somma costi fissi percorso q(c_q) > somma costi fissi percorso p(c_p) Allora elimina percorso q

11

Tecniche e Modelli di ottimizzazione

a.a. 2010-2011

Marco Cella, Marco Pighin

Conclusioni

Lo scopo del progetto ` quello di fornire la struttura dello shortest path graph a cui sono state applicate le regole e di riduzione (capitolo 5), e creare una formattazione dei le di input pi` consona per le diverse formulazioni u studiate nel problema del Network Pricing Problem (NPP). La fase pi` delicata del problema risiede nello studio u dei limiti e luso di strumenti opportuni per conseguire i risultati voluti; in questa relazione sono esposte le scelte che riguardano le strutture dati ed i passi di computazione, i limiti computazionali dellapplicazione sviluppata ed alcune possibili soluzioni per lo sviluppo futuro del progetto. Lapplicazione progettata restituisce correttamente i le di input per le diverse formulazioni, per piccole istanze del problema cio` con un numero limitato di archi con taria; per istanze maggiori del problema ` necessario e e usare una formulazione dierente per la generazione dello shortest path graph, in particolare una formulazione per archi; infatti il numero dei percorsi ha una crescita del tipo n n! e non ` possibile per il server tenere in e memoria ram tutte le strutture dati necessarie per eseguire lalgoritmo (capitolo 2).

Riferimenti bibliograci
M. Bouhtou, S. van Hoesel, A.F. van der Kraaij, and J.L. Lutton. Tari Optimization in Networks. INFORMS Journal on Computing, 19(3): 458-469, 2007. M. Labb, P. Marcotte, and G. Savard. A Bilevel Model of Taxation and Its Application to Optimal Highway e Pricing. Management Science, 44(12): 1608-1622, 1998. S. Roch, G. Savard, and P. Marcotte. An Approximation Algorithm for Stackelberg Network Pricing. Networks, 46: 57-67, 2005. L. Brotcorne, M. Labb`, P. Marcotte, and G. Savard. A Bilevel Model and Solution Algorithm for a Freight e Tari-Setting Problem. Transportation Science, 34(3): 1-14, 2000. L. Brotcorne, M. Labb`, P. Marcotte, and G. Savard. A Bilevel Model for Toll Optimization on a Multicommodity e Transportation Network. Transportation Science, 35: 1-14, 2001.

12