4ème défi C & C++ : Balade dans le métro parisien

Version imprimable

Voir 40 message(s) de cette discussion en une page

15/05/2009, 07h40
Climoo

Humm... Et si jamais on utilise quand même des wchar_t dans le programme, qu'est ce qu'on risque?:aie: Une simple pénalité ou alors le projet ne devient plus recevable?
15/05/2009, 07h54
Vincent Rogier

Citation:

Envoyé par Climoo

.
Pas de wchar_t ?
J'y connais pas grand chose aux normes alors (pour pas dire rien du tout)... Mince... J'ai aucune idée comment faire sans ça !

Ben dans le fichier, y'a plusieurs accents etc. Je croyais que les accents c'était pas ANSI. non?

les caractères accentués sont des caractères ANSI mais non ASCII.
Ce que j'ai fait remarqué, c'est que comme le référentiel de données (le fichier Unicode UTF16) est un référentiel Unicode, le programme ne peut présupposer que le contenu est uniquement des caractères représentables en ANSI (un simple packing des buffer lus aurait alors suffit à récupérer les valeurs dans des chaines ANSI) mais doit gérer le fait que, puisque c'est de l'unicode, des caractères non ANSI peuvent si trouver... Sinon, pourquoi imposer un fichier UTF16 et il aurait mieux valut fournir alors un fichier ANSI ou UFT8.
C'est pour ca que je dis qu'il y a une incohérence dans les régles du défi.Il vaudrait mieux que les régles spécifiques à ce défi précisent que le code C peut être du C99. Sinon ca n'a pas de sens au vu des autres régles imposées (E/S, référentiel,...)

Citation:

Envoyé par Climoo

Humm... Et si jamais on utilise quand même des wchar_t dans le programme, qu'est ce qu'on risque?:aie: Une simple pénalité ou alors le projet ne devient plus recevable?

Je n'en sais rien. Il faut demander aux organisateurs du défi.
Je n'ai fait que lire les régles du défi et relevé, ce qui à mon sens, est une incohérence.

Attendons le feedback des organisateurs...
15/05/2009, 11h18
ram-0000

Citation:

Envoyé par Vincent Rogier

les caractères accentués sont des caractères ANSI mais non ASCII.
Ce que j'ai fait remarqué, c'est que comme le référentiel de données (le fichier Unicode UTF16) est un référentiel Unicode, le programme ne peut présupposer que le contenu est uniquement des caractères représentables en ANSI (un simple packing des buffer lus aurait alors suffit à récupérer les valeurs dans des chaines ANSI) mais doit gérer le fait que, puisque c'est de l'unicode, des caractères non ANSI peuvent si trouver... Sinon, pourquoi imposer un fichier UTF16 et il aurait mieux valut fournir alors un fichier ANSI ou UFT8.
C'est pour ca que je dis qu'il y a une incohérence dans les régles du défi.Il vaudrait mieux que les régles spécifiques à ce défi précisent que le code C peut être du C99. Sinon ca n'a pas de sens au vu des autres régles imposées (E/S, référentiel,...)

Dans ma tête, lors de la spécification de ce défi, il était clair que le type wchar_t devait être autorisé pour pouvoir gérer correctement un fichier Unicode.

Je ne savais pas que ce type faisait partir de la norme C99 (d'ailleurs, je ne connais pas bien les différentes normes :oops:).

Donc oui, les fonctions wcin, wcout, wprintf et autre wgets sont autorisées de même que le type wchar_t pour ce défi.
15/05/2009, 11h47
Vincent Rogier

L'introduction des caractères larges date d'un draft d'une révision en 95 et officialisé par le C99.

Donc faudrait mettre à jour les règles du défi pour autoriser du C99. C'est tout !

Par contre, reste toute de même l'incohérence de noms de stations en arguments (qui sont toujours des char *) alors que le référentiel est en unicode... pas très logique...

Par contre, petite précision pour ceux qui veulent faire un code portable : les fonctions wide de la famille printf se compportent différent sous Windows et les autres systemes : sous windows une %s sera une chaine de charactère larges alors que sous les autres %s est une chaine de charactères et %ls une chaine de caractères larges....
merci Microsoft et bonjour les #ifdef....
15/05/2009, 12h21
ram-0000

Citation:

Envoyé par Vincent Rogier

Donc faudrait mettre à jour les règles du défi pour autoriser du C99. C'est tout !

C'est noté !!

Citation:

Envoyé par Vincent Rogier

Par contre, reste toute de même l'incohérence de noms de stations en arguments (qui sont toujours des char *) alors que le référentiel est en unicode... pas très logique...

Oui mais dans les règles toujours, on trouve "champs elysees" = "Champs-Elysées" donc cela ne devrait pas poser trop de problèmes.

Citation:

Envoyé par Les règles du défi

Il y a une petite contrainte supplémentaire, lors de la saisie des noms des stations des points de départ et d'arrivée. Le programme doit être insensible aux différences majuscules/minuscules, aux accents et autres signes de ponctuation. C'est à dire que si l'utilisateur saisi "champs elysees, le programme doit comprendre qu'il parle en fait de la station "Champs-Elysées". Par contre "Châtelet" est différent de "Châtelet-Les Halles",
15/05/2009, 12h22
ram-0000

Citation:

Envoyé par jfouche

Peut on utiliser les bibliothèques à compiler de boost ?

Clairement : Oui

Bien sûr la documentation du projet doit indiquer quelle version de boost il utilise ainsi que le nom de la ou des librairies boost avec lesquelles se link le projet.

Mais cela , je n'ai pas besoin de te le rappeler car tout le monde allait y penser :P
15/05/2009, 12h26
Vincent Rogier

Citation:

Envoyé par ram-0000

C'est noté !!

Oui mais dans les règles toujours, on trouve "champs elysees" = "Champs-Elysées" donc cela ne devrait pas poser trop de problèmes.

peut être mais c'est pas cohérent !

Car tu présupposes que le contenu du fichier unicode ne contient que des caractères représentables en ANSI. Dans ce cas, pourquoi fournir un fichier unicode ?

C'est une assomption que le programme ne doit pas faire car il ne connait pas le contenu du fichier à l'avance (en terme d'étendue de caractère).
La lecture du BOM indique au programme que c'est de l'UTF16, c'est tout.
Donc le programme doit s'attendre à n'importe quelle chaine de caractère Unicode (du klington, pourquoi pas..)...
Donc problème de cohérence avec la nature du référentiel (UTF16) et les limitations des arguments du programme (ANSI) !
17/05/2009, 11h06
Luc Hermitte

Comme je le perçois, il va falloir convertir les fichiers d'entrée (soyez d'ailleurs plus précis que Unicode car cela ne veut pas dire grand chose au fond, et que le BOM n'est pas toujours présent dans tous les fichiers UTF-x), ainsi que les arguments du programme (qui seront dans l'encoding de la $LANG à priori) vers de l'UTF-32/16 en interne du programme.

Ce qui va poser d'autre difficultés car le type wchar_t et ses types dérivés (comme wstring) ne sont pas correctement supportés avec les GCC sous windows.

En fait, en C++ les difficultés sont très techniques car boost fournit déjà l'algo de recherche du chemin, et des code_cvt facet pour l'UTF-8. Reste à s'occuper du BOM et des autres UTF-16/32, tordre le cou à wchar_t pour être portable mingw/cygwin, et enfin modéliser correctement son graphe.
A la limite, on peut mettre en place de quoi accepter "chant" pour "champs", bref une reconnaissance phonétique/SMS.
17/05/2009, 11h44
Invité

Citation:

Envoyé par ram-0000

Une autre remarque, votre programme doit être le plus indépendant possible du contenu du fichier et ne doit rien supposer ou interpréter. Ce n'est peut être pas ce fichier qui sera utilisé lors de l'analyse de vos projets par les membres du jury.

Il va bien falloir, pourtant, faire quelques hypothèses sur la nature des réseaux que l'on peut rencontrer... Peut on tabler sur les éléments suivants (qui me semblent découler du format du fichier choisi) ?

1- les lignes sont parcourues dans les deux sens, et dans le même ordre à l'aller et au retour
2- il n'y a pas de lignes circulaires, ni de fourches (ou s'il y en a, comment les noterait on dans le fichier)
3- en revanche, toutes les stations ne sont pas forcément connectées, il appartient au programme de le préciser à l'utilisateur
4- comme les correspondances sont définies par les noms des stations, on ne peut avoir une correspondance entre deux stations de la même ligne (exemple réel : havre caumartin, opera)

Peut on faire l'hypothèse suivante (qui me parait saine, mais ne va pas de soi compte tenu du format de fichier en entrée)?

Une ligne ne peut se croiser elle même (c'est à dire qu'on n'a jamais besoin de changer pour prendre la même ligne)

Francois
17/05/2009, 15h45
ram-0000

Citation:

Envoyé par fcharton

1- les lignes sont parcourues dans les deux sens, et dans le même ordre à l'aller et au retour

Oui, enfin le retour se parcours dans l'ordre inverse tout de même.

Citation:

Envoyé par fcharton

2- il n'y a pas de lignes circulaires, ni de fourches (ou s'il y en a, comment les noterait on dans le fichier)

Oui

Citation:

Envoyé par Les règles du défi

certaines lignes de métro ont été modifiées et simplifiées afin de supprimer les petites particularités locales. Ainsi par exemple sur la ligne 13, le double terminus Gabriel Péri/Asnières-Gennevilliers et Saint-Denis-Université ont été supprimés pour ne laisser qu'un seul terminus Saint-Denis-Université. Ou encore sur la ligne 10, la boucle du côté de Boulogne Pont de Saint-Cloud a été supprimée,

Citation:

Envoyé par fcharton

3- en revanche, toutes les stations ne sont pas forcément connectées, il appartient au programme de le préciser à l'utilisateur

Je ne comprends pas

Citation:

Envoyé par fcharton

4- comme les correspondances sont définies par les noms des stations, on ne peut avoir une correspondance entre deux stations de la même ligne (exemple réel : havre caumartin, opera)

Si on reprend cet exemple, "havre caumartin, opera", c'est ce que j'appelle une correspondance piétonne et elle ne peut être retenue par le programme comme une correspondance réelle car les noms des 2 stations sont différents. Les correspondances entre 2 lignes doivent être détectées par le programme par le fait que les noms des stations sont identiques (aux accents et signes prêts)

Citation:

Envoyé par Les règles du défi

les correspondances "piétonnes" (comme celle entre Pereire sur la ligne 3 et Pereire-Levallois sur le RER C) entre stations sont ignorées

Citation:

Envoyé par fcharton

Une ligne ne peut se croiser elle même (c'est à dire qu'on n'a jamais besoin de changer pour prendre la même ligne)

Oui, une ligne ne peut se croiser, il n'y a pas de boucle sur la même ligne

Il se peut que malgré toute l'attention que j'ai apportés au fichier de définition des stations, il y ait un problème dedans (nul n'est parfait :?). Dans ce cas, ne pas hésiter à me le faire savoir par un petit MP ou à le signaler dans ce post.
18/05/2009, 00h06
Nogane

Bonsoir,
J'aurais quelques petites questions.

Lorsqu'on passe par une "station intermédiaire" (option -i), doit-on compter le temps de correspondance entre 2 lignes du métro(option -c), dans chacun des cas suivants:
- Lorsqu'on change de ligne? (D'après les règles, oui)
- Lorsqu'on reste sur la même ligne? (D'après les règles, non, mais cela ne parait pourtant pas absurde)
- Lorsqu'on fait demi-tour, sur la même ligne? (La, rien dans les règle, mais il me semblerait logique que oui)
18/05/2009, 00h28
ram-0000

Citation:

Envoyé par Nogane

Lorsqu'on passe par une "station intermédiaire" (option -i), doit-on compter le temps de correspondance entre 2 lignes du métro(option -c), dans chacun des cas suivants:
- Lorsqu'on change de ligne? (D'après les règles, oui)

Je confirme, oui

Citation:

Envoyé par Nogane

- Lorsqu'on reste sur la même ligne? (D'après les règles, non, mais cela ne parait pourtant pas absurde)

Tiens, je n'avais pas prévu ce cas là. Une station intermédiaire compte pour une correspondance même si l'on ne doit pas changer ni de ligne ni de sens. On peut penser que c'est le temps nécessaire pour sortir de la station, faire sa course et revenir dans la station.

Citation:

Envoyé par Nogane

- Lorsqu'on fait demi-tour, sur la même ligne? (La, rien dans les règle, mais il me semblerait logique que oui)

Un demi tour = une correspondance (il faut bien changer de quai)

Dès que possible je modifierai les règles du défi pour les compléter avec ces points.
20/05/2009, 16h38
Exousia

Bonjour,

Citation:

Envoyé par ram-0000

Dans ma tête, lors de la spécification de ce défi, il était clair que le type wchar_t devait être autorisé pour pouvoir gérer correctement un fichier Unicode.

Je ne savais pas que ce type faisait partir de la norme C99 (d'ailleurs, je ne connais pas bien les différentes normes :oops:).

Donc oui, les fonctions wcin, wcout, wprintf et autre wgets sont autorisées de même que le type wchar_t pour ce défi.

Il est donc confirmé que ce n'est pas grave si le programme n'est pas compilable sous MinGW qui est incomplet à ce niveau (du moins à ma connaissance) ? Car la discussion porte tout de même à confusion en obligeant le code à être portable.

Merci 8-)

Youpi

J'ai un truc qui marche (qui prend le métro plutôt ;)). Avec quelques tests, j'ai remarqué que quelques correspondances manquent cruellement :
De la défense à la porte de clichy, j'obtiens :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
metro -f ../ListeStationsUnicode.txt -c 300 -d 60 -x "esplanade de la defense" -y "porte de clichy"
Trajet de esplanade de la defense vers porte de clichy
Temps : 2040 secondes
Prendre la ligne [Ligne 1] en direction de la defense
Sortir a la station la defense
Prendre la ligne [RER A] en direction de nation
Sortir a la station charles de gaulle etoile
Prendre la ligne [Ligne 1] en direction de chateau de vincennes
Sortir a la station champs elysees clemenceau
Prendre la ligne [Ligne 13] en direction de chatillon montrouge
Sortir a la station invalides
Prendre la ligne [RER C] en direction de porte de clichy
Sortir a la station porte de clichy

Bref, loin de la réalité... J'aime bien le début : ligne 1, RER A, ligne 1 :mouarf:

EDIT : avec des valeurs plus proche de la réalité (et sans inverser -c et -d), j'obtiens bien mieux :

Code:

1
2
3
4
5
6
7
8
9
C:\_Perso\projets\test\developpez\metro\bin>metro -f ../ListeStationsUnicode.txt -c 600 -d 60 -x "esplanade de la defense" -y "porte de clichy"
Trajet de esplanade de la defense vers porte de clichy
Temps : 1680 secondes
Prendre la ligne [Ligne 1] en direction de chateau de vincennes
Sortir a la station champs elysees clemenceau
Prendre la ligne [Ligne 13] en direction de chatillon montrouge
Sortir a la station invalides
Prendre la ligne [RER C] en direction de porte de clichy
Sortir a la station porte de clichy

Il ne me reste plus qu'à implémenter les stations intermédiaires.
--
Jérémie

hé ca y'est, moi aussi j'ai un truc qui marche...
En revanche, je trouve pas comme jfouche au niveau du temps :aie:. Cela me donne
Code:

1 2 3 4 5 6 7 $ bmetro -d 60 -c 600 -x "esplanade de la defense" -y "porte de clichy" Ligne 1 |dir : Château de Vincennes |arret Champs-Élysées-Clemenceau Ligne 13 |dir : Châtillon-Montrouge |arret Invalides RER C |dir : Porte de Clichy |arret Porte de Clichy Temps total : 2280
Il y'a deux changements, donc il reste 1080 secondes passées vraiment dans le métro. Divisé par 60, le temps mis pour une portion de trajet, cela fait 18. Et quand j'essaie de refaire le trajet depuis le fichier des stations, je compte bien 18 intervalles. Y'aurait pas un problème par hasard...

27/05/2009, 20h01
koala01

Citation:

Envoyé par Exousia

Bonjour,

Il est donc confirmé que ce n'est pas grave si le programme n'est pas compilable sous MinGW qui est incomplet à ce niveau (du moins à ma connaissance) ? Car la discussion porte tout de même à confusion en obligeant le code à être portable.

Merci 8-)

Sauf erreur, il "suffit" de rajouter iconv (ou libiconv qui est la bibliothèque qui fournit l'implémentation de iconv) pour que MinGW fournisse le support correct des locales, et c'est une bibliothèque classiquement rajoutée ;)

Citation:
Envoyé par Climoo
hé ca y'est, moi aussi j'ai un truc qui marche...
En revanche, je trouve pas comme jfouche au niveau du temps :aie:. Cela me donne
Code:

1 2 3 4 5 6 7 $ bmetro -d 60 -c 600 -x "esplanade de la defense" -y "porte de clichy" Ligne 1 |dir : Château de Vincennes |arret Champs-Élysées-Clemenceau Ligne 13 |dir : Châtillon-Montrouge |arret Invalides RER C |dir : Porte de Clichy |arret Porte de Clichy Temps total : 2280
(Sur le ton d'un prof de math...)
Mr Climoo, vous parlez trop :aie:

Apres correction, je trouve comme toi :ccool:

Un autre exemple :

Citation:

metro -f ListeStationsUnicode.txt -d 60 -c 600 -x "esplanade de la defense" -y "porte de clichy" -i "raspail" -i "jules joffrin" -i "porte d'ivry" -o
Trajet de esplanade de la defense vers porte de clichy
Etapes : raspail, jules joffrin, porte d'ivry
Recherche optimisee

00:00:00 : Prendre la ligne [Ligne 1] direction chateau de vincennes
Sortir a la station concorde
00:19:00 : Prendre la ligne [Ligne 12] direction porte de la chapelle
Sortir a la station jules joffrin
00:28:00 : Arrivee a l'etape jules joffrin
00:38:00 : Prendre la ligne [Ligne 12] direction mairie d'issy
Sortir a la station montparnasse bienvenue
01:04:00 : Prendre la ligne [Ligne 4] direction porte d'orleans
Sortir a la station raspail
01:06:00 : Arrivee a l'etape raspail
01:16:00 : Prendre la ligne [Ligne 6] direction nation
Sortir a la station place d'italie
01:31:00 : Prendre la ligne [Ligne 7] direction mairie d'ivry
Sortir a la station porte d'ivry
01:36:00 : Arrivee a l'etape porte d'ivry
01:46:00 : Prendre la ligne [Tramway T3] direction pont du garigliano
Sortir a la station cite universitaire
02:01:00 : Prendre la ligne [RER B] direction gare du nord
Sortir a la station saint michel notre dame
02:15:00 : Prendre la ligne [RER C] direction porte de clichy
Sortir a la station porte de clichy
02:26:00 : Arrivee

Bon courage :mouarf:
--
Jérémie

01/06/2009, 18h20
ram-0000
Suites aux nombreuses remarques reçues et suite à une discussion en interne, une petite modification a été apportée au défi. Le format du fichier décrivant les différentes lignes de métro est maintenant soit au format Unicode soit au format UTF-8.

Les 2 formats de fichiers sont disponibles sur la page du défi :
- Fichier Unicode
- Fichier UTF-8
Le challenger est libre de choisir le format de son choix, il n'y a pas de bonus ni de malus en fonction de ce choix. Toutefois, il conviendra d'indiquer dans la documentation du projet le type de format supporté.

Autre point important : la date de fin de défi a été repoussée au dimanche 14 juin 2009 (chouette, une semaine de plus pour peaufiner la documentation et les tests)
01/06/2009, 20h29
Nogane

14 juin 2009 n'était-elle pas la date prévu depuis le début?
01/06/2009, 20h49
ram-0000

Citation:

Envoyé par Nogane

14 juin 2009 n'était-elle pas la date prévu depuis le début?

Si si, énorme confusion de ma part :oops: :oops:

Initialement ce défi était prévu du 3 mai au 7 juin mais comme la correction du défi précédent a pris plus de temps que prévu, ce défi a été repoussé du 9 mai au 14 juin mais cela était resté dans ma tête avec une date de fin au 7 juin.

Voir 40 message(s) de cette discussion en une page