-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Oops j'ai upload le .pdf à la place du .tex
- Loading branch information
Showing
1 changed file
with
65 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,65 @@ | ||
\documentclass{article} | ||
|
||
\usepackage[utf8]{inputenc} | ||
|
||
\title{Compte rendu de la réunion du 6 Février} | ||
\date{} | ||
|
||
\begin{document} | ||
|
||
\maketitle | ||
|
||
\section*{Algorithme de parcours} | ||
\begin{itemize} | ||
\item Flyod-Warshall temporel | ||
\item Paramètres : Le graphe temporel et une matrice initialisée à +${\infty}$ avec 0 | ||
sur la diagonale | ||
\item Complexité : Temps - ${O(n^3 * t)}$ Mémoire - ${O(n^2 * t)}$ avec n le nombre de liens | ||
\item Principe : 3 boucles impliquées pour calculer les distances de tout le monde à tout le monde, et mettre à jour les distances minimales si trouvées. | ||
\item Spécificités temporelles : 4ème boucle pour le temps, et si on dépasse T${_{max}}$ (Par exemple traverser un lien de poids 4 au temps 98/100), alors mettre la valeur à +${\infty}$.\newline De plus on compare à (dist[i,j][t+1] + 1) pour chaque temps t. | ||
\item Pourquoi celui-ci ? Algorithme facile à implémenter et adapter et est celui | ||
déjà utilisé partout pour les graphes non-temporels. | ||
\item Si trop coûteux, on approximera plusieurs pas de temps en un seul. | ||
\item Autres algorithmes à creuser si possible : Johnson, Dijkstra | ||
\end{itemize} | ||
|
||
\newpage | ||
|
||
\section*{La mesure demandée} | ||
\begin{itemize} | ||
\item Paramètres : T${_{max}}$, calculé avec le diamètre de notre graphe. Intervalle ${\delta}$, qui sera notre fréquence de mise à jour des attaques des temps 0 à T${_{max}}$. | ||
\item Si division coûteuse, on peut trouver d’autres formules que l'efficacité évaluer la robustesse du graphe tant que notre valeur reste cohérente et interprétable. | ||
\item Pour pouvoir la calculée, nous sommes parti sur une implémentation de Time-varying graph. Mais il reste à régler le problème des pas de temps intermédiaires : | ||
\begin{itemize} | ||
\item Si nous faisant des pas de temps de ${2x}$, comment faire si nous avons un lien qui coûte ${3x}$ ou ${1x}$? | ||
\item Cela implique une décorrélation entre les temps de l’évolution du graphe et les poids de celui-ci. | ||
\item Pour l’instant : on ne prend pas en compte les changements de rue pendant qu’on la traverse. A réfléchir pour mieux résoudre le problème, comme sous-diviser nos pas de temps par exemple. | ||
\end{itemize} | ||
\end{itemize} | ||
|
||
\section*{Attaques} | ||
\begin{itemize} | ||
\item Budget par nombre de voies (Coût pour bloquer une rue relative à son nombre de voies). | ||
\item A faire : mêmes attaques mais sans ce coup par nombre de voies d’une rue. | ||
\item Faire attention pour l’attaque se déplaçant à ne pas avoir deux bloque-liens superposés. | ||
\item Pour les attaques statiques, on réimplémente des Graph Equivalent Stream (à voir pour optimiser les calculs spécialement pour ça) | ||
\item A creuser : Les attaques en coupe de graphe (Séparer le graphe en 2 composantes connexes ou plus) (cf. L’algorithme d’Alexis)\newline Avec un algorithme propre ou avec les fonctions de networkx (Avec l’option strongly connected pour les graphes orientés) | ||
\end{itemize} | ||
|
||
\newpage | ||
|
||
\section*{Données des villes} | ||
\begin{itemize} | ||
\item Pour les données manquantes sur OSMnx : On a choisi 30km/h pour la vitesse par défaut et un nombre de voies à 1.\newline Il faut extrapoler et donc choisir des données par défaut cohérentes. | ||
\item Pour calculer le poids des liens, tester si ${distance}$ ou ${\frac{distance}{vitesse}}$ est le plus pertinent. | ||
\item Note : quand il n’y a pas d’intérêt évident de choisir quelque chose lors d’une démarche scientifique, il faut tenter les 2 approches et voir laquelle est la plus pertinente. | ||
\end{itemize} | ||
|
||
\section*{Autres} | ||
\begin{itemize} | ||
\item Pour tester nos algorithmes : Prendre des villes ”typiques” pour avoir le cas le plus général possible. | ||
\item S’il nous reste du temps après, on peut aussi travailler sur des graphes de routes maritimes et calculer les impacts de grèves de ports ou d’accidents de bateau pour la circulation. | ||
\item Pour optimiser les exécutions en parallèle sur les serveurs du lip6, exécution par stratégies et par pas de temps sur la même ville pour pouvoir partager son graphe en mémoire et éventuellement d’autres données | ||
\end{itemize} | ||
|
||
\end{document} |