Génération et résolution de labyrinthes II - Historique des versions

Theodet : Changement d'URL GitHub

2021-11-19T10:40:38Z

Changement d'URL GitHub

← Version précédente		Version du 19 novembre 2021 à 10:40
Ligne 294 :		Ligne 294 :
	== Code source ==		== Code source ==

	Le code source est disponible sur Github à [https://github.com/~~Rominos111~~/Labyrinthe_VISI201 cette adresse]. N'hésitez pas à jeter un œil aux autres projets en cours 😉		Le code source est disponible sur Github à [https://github.com/RomainTHD/Labyrinthe_VISI201 cette adresse]. N'hésitez pas à jeter un œil aux autres projets en cours 😉

	Il suffit d'avoir installé Python 3 et Tkinter.		Il suffit d'avoir installé Python 3 et Tkinter.

	== Sources ==		== Sources et liens utiles ==

	Génération		Génération

Theodet le 9 avril 2021 à 20:23

2021-04-09T20:23:27Z

Voir les modifications

Theodet le 22 mai 2019 à 17:33

2019-05-22T17:33:02Z

← Version précédente		Version du 22 mai 2019 à 17:33
Ligne 1 :		Ligne 1 :
	__FORCETOC__[[Fichier:labyrinthe_photo.png\|vignette\|300px\|Exemple de labyrinthe généré et résolu. En rouge foncé, l'entrée. En vert, la sortie. En bleu, le chemin entre le départ et l'arrivée. En rouge clair, les cellules visitées lors de la résolution.\|alt="Labyrinthe"]]		__FORCETOC__[[Fichier:labyrinthe_photo.png\|vignette\|300px\|Exemple de labyrinthe généré et résolu. En rouge foncé, l'entrée. En vert, la sortie. En bleu, le chemin entre le départ et l'arrivée. En rouge clair, les cellules visitées lors de la résolution.\|alt="Labyrinthe"]]

	On ~~veut~~ générer des labyrinthes aussi grands et complexes que possible~~, avec des murs dans une grille carré~~. ~~Comment~~ ~~faire~~ ~~pour~~ ~~qu'il~~ y ~~ait toujours~~ un chemin de l'entrée à la sortie ~~? Comment faire pour qu'il n'y ait qu'un chemin ? Et~~ comment trouver la sortie ~~quand~~ on ~~est perdu dans le~~ labyrinthe ?		L'objectif de ce projet est de générer des labyrinthes aussi grands et complexes que possible. Nous allons voir comment toujours avoir un chemin entre l'entrée et la sortie, et comment trouver la sortie une fois notre labyrinthe généré.

	== Représentation ==		== Représentation ==

Theodet le 22 mai 2019 à 17:30

2019-05-22T17:30:06Z

Voir les modifications

Theodet : /* Résolution */

2019-05-22T12:40:53Z

Résolution

← Version précédente		Version du 22 mai 2019 à 12:40
Ligne 258 :		Ligne 258 :




			On remarquera que des deux algorithmes, celui du mur droit explorera toutes les cellules situées en dessous du chemin optimal. Il sera donc plus efficace lorsque le chemin de solution est vers le bas de la grille.

	== Code source ==		== Code source ==

Theodet le 20 mai 2019 à 06:51

2019-05-20T06:51:31Z

← Version précédente		Version du 20 mai 2019 à 06:51
Ligne 1 :		Ligne 1 :
	__FORCETOC__[[Fichier:labyrinthe_photo.png\|vignette\|300px\|Labyrinthe généré avec Kruskal et résolu avec le parcours en profondeur. En ~~route~~ foncé, l'entrée. En vert, la sortie. En bleu, le chemin. En rouge clair, les cellules visitées lors de la résolution.\|alt="Labyrinthe"]]		__FORCETOC__[[Fichier:labyrinthe_photo.png\|vignette\|300px\|Labyrinthe généré avec Kruskal et résolu avec le parcours en profondeur. En rouge foncé, l'entrée. En vert, la sortie. En bleu, le chemin. En rouge clair, les cellules visitées lors de la résolution.\|alt="Labyrinthe"]]

	On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Et comment trouver la sortie quand on est perdu dans le labyrinthe ?		On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Et comment trouver la sortie quand on est perdu dans le labyrinthe ?

Theodet le 20 mai 2019 à 06:47

2019-05-20T06:47:19Z

← Version précédente		Version du 20 mai 2019 à 06:47
Ligne 2 :		Ligne 2 :

	On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Et comment trouver la sortie quand on est perdu dans le labyrinthe ?		On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Et comment trouver la sortie quand on est perdu dans le labyrinthe ?


	== Représentation ==		== Représentation ==

Rakotoanosy le 19 mai 2019 à 23:49

2019-05-19T23:49:36Z

← Version précédente		Version du 19 mai 2019 à 23:49
Ligne 1 :		Ligne 1 :
			__FORCETOC__[[Fichier:labyrinthe_photo.png\|vignette\|300px\|Labyrinthe généré avec Kruskal et résolu avec le parcours en profondeur. En route foncé, l'entrée. En vert, la sortie. En bleu, le chemin. En rouge clair, les cellules visitées lors de la résolution.\|alt="Labyrinthe"]]
	__FORCETOC__ L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
	Autonomie énergétique souvent limitée
	Faible puissance des processeurs et taille réduite de la mémoire
	Disponibilité « aléatoire » de l’accès aux réseaux de communication

			On veut générer des labyrinthes aussi grands et complexes que possible, avec des murs dans une grille carré. Comment faire pour qu'il y ait toujours un chemin de l'entrée à la sortie ? Comment faire pour qu'il n'y ait qu'un chemin ? Et comment trouver la sortie quand on est perdu dans le labyrinthe ?
	De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

Rakotoanosy : Annulation des modifications 11819 de Rakotoanosy (discussion)

2019-05-19T23:48:27Z

Annulation des modifications 11819 de Rakotoanosy (discussion)

← Version précédente		Version du 19 mai 2019 à 23:48
Ligne 1 :		Ligne 1 :
	~~__FORCETOC__L’avènement~~ de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :		__FORCETOC__ L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
		⚫	Autonomie énergétique souvent limitée
	<ul>
		⚫	Faible puissance des processeurs et taille réduite de la mémoire
⚫	~~<li>~~Autonomie énergétique souvent limitée~~</li>~~
		⚫	Disponibilité « aléatoire » de l’accès aux réseaux de communication
⚫	~~<li>~~Faible puissance des processeurs et taille réduite de la mémoire~~</li>~~

⚫	~~<li>~~Disponibilité « aléatoire » de l’accès aux réseaux de communication~~</li>~~
	</ul>
	De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?		De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?

Rakotoanosy le 19 mai 2019 à 23:47

2019-05-19T23:47:40Z

← Version précédente		Version du 19 mai 2019 à 23:47
Ligne 1 :		Ligne 1 :
	~~__FORCETOC__ L’avènement~~ de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :		__FORCETOC__L’avènement de l’Internet des Objets (IoT) depuis une dizaine d’années a fait apparaitre des problématiques propres aux protocoles de communications liées à ces objets. En effet, l’échange de données dans ce contexte nécessite de tenir compte (au moins) des paramètres suivant :
			<ul>
	Autonomie énergétique souvent limitée		<li>Autonomie énergétique souvent limitée</li>
	Faible puissance des processeurs et taille réduite de la mémoire		<li>Faible puissance des processeurs et taille réduite de la mémoire</li>
	Disponibilité « aléatoire » de l’accès aux réseaux de communication		<li>Disponibilité « aléatoire » de l’accès aux réseaux de communication</li>

			</ul>
	De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?		De nombreux protocoles cohabitent et la littérature du domaine foisonne d’exemples autour des réseaux dédiées (LORA, Sigfox, etc.) et des protocoles applicatifs (OPC-UA, MQTT, CoaP, XMPP) mais force est de constater que dans la réalité, ces solutions ne répondent pas toujours aux besoins des concepteurs qui leurs préfèrent encore le protocole HTTP. Celui-ci offre l’avantage d’implémenter un protocole applicatif (REST) en même temps qu’un protocole de transport de haut niveau (TCP/IP) permettant de passer les pare-feu. Cependant, la version actuel d’HTTP ne répond pas vraiment aux critères énoncés précédemment. Depuis quelques années émerge donc l’idée d’enrichir HTTP pour créer un protocole hybride qui mêlerait les avantages de REST avec ceux proposés par les mécanismes de type Publish/Subscribe (MQTT, AMQP, JMS, etc.). En attendant cette éventuelle évolution, peut-on envisager de mettre en place un mécanisme de type Pub/Sub avec le protocole Websocket au-dessus d’HTTP ?