Curriculum and Labs for Engineering Education

cancel
Showing results for 
Search instead for 
Did you mean: 

Challenge mathématiques #6 : Écrire la date et l’heure complètes en temps réel et en chiffres romains

Bonjour,

Pour ce mois d’août, pas de pression, juste du fun ! L’idée serait de ne pas passer trop de temps à parvenir à une solution mais que cela émoustille un peu les neurones quand même…

Je vous propose d’afficher simplement l’heure et la date du PC en chiffres romains sur la face-avant. Cela avec l’heure en temps réel secondes comprises.

Par exemple :

Le 31/07/2013 à 14:26:29 donnerait

XXXI/VII/MMXIII   

XIV:XXVI:XXIX

Pour départager les résultats, le vainqueur sera celui dont l’utilisation en mémoire du VI est la plus petite dans l’outil Profil >> performances et mémoire (tous les VIs lancés à la même heure).

Le gagnant aura une certification de son choix offerte.

Comme toujours, pas de DLL encapsulées, juste des VIs de la bibliothèque. Retour du code dans un fichier ZIP avec votre pseudo dans le Main

Pour que tous partent sur la même base d’affichage, je fournis la face-avant.

Je serais en congés jusqu’au 26 août et je ne pourrais pas toujours répondre d’ici là, mais vous pouvez m’envoyer vos codes (emmanuel.roset@ni.com), j’ai hâte de voir les solutions

Bon courage !

Emmanuel

Précision au 02/08/2013

Il est possible de s'arrêter à l'année 2059 dans l'affichage de la date en temps réel sur la face-avant.

La date peut être amenée à bouger en fonction de la source temporelle jusqu'à la date de 2059

Comme il n'y a pas de saisie manuelle du temps sur la face-avant, la synchronisation provient forcément du PC, d'un service serveur de temps ou autre...

Précision règles au 12/08/2013

Il n'est pas utile de mettre une boucle While et un bouton stop autour de votre code car il sera lancé par un noeud de méthode dans un programme bench et lu avec l'outil de profil et performances

Pour les codes que j'ai déjà reçus pas de soucis, je retirerai la boucle While pour le test.

En ce qui concerne le passage par zéro de l'heure, il faudrait ajouter un caractère 0 plutôt que de laisser vide le caractère afin que tous les programmes soient identiques.

En effet suite à un premier bench cela ce joue à 100 octets près pour les premiers et avec des méthodes complètement différentes ! et chaque caractère et choix de fonction compte

Précision au 13/08/2013

Aujourd'hui vous êtes 7 à optimiser vos codes pour descendre en dessous des 5k voir ...

Cependant comme précisé dans un post du 13/08, le découpage en Sous-VI ne rapportera pas en espérant libérer l'utilisation mémoire du Main à presque zéro...car la règle est que je vais additionner l'utilisation mémoire du main et des Sous-VI au total.

Donc cela peut rapporter un peu avec des Sous-VI réutilisés, mais pas tant que cela, voir faire pire. Cela ne concerne presque personne mais c'est juste au cas où.

Je confirme déjà par rapport aux codes reçus, qu'un seul VI est largement plus rentable dans ce cas.

je suis très impressionné par les choix de codage et vous serez surement intéressé de regarder les solutions des autres au final.

Résulats au 02/09/2013

Le temps est venu de dévoiler les résultats du challenge du mois d’août.

Une lutte acharnée c’est déroulée pendant l’été. Ce petit challenge romain finalement a été réalisé rapidement,en tout cas dans un premier temps.

Puis certains sont revenus sur leur programme et m’ont envoyé de nouvelles versions optimisées pour qu’il utilise le moins de mémoire possible.

Chaque jour les valeurs descendaient et un nouveau vainqueur possible se présentait. Quelque 14 personnes ont proposés des codes régulièrement.

Arrive le mois de septembre. Vérification de la conformité des codes... Puis pour départager les résultats, j’ai effectué des lancements successifs de tous les codes ensemble pour avoir une tendance.

Puis uniquement sur les 3 premiers pour éviter tous problèmes de chargement et avoir exactement la même heure affichée.

Je félicite donc Mathieu_R qui se détache vraiment avec un résultat autour des 2450 octets et a ainsi gagné une certification de son choix.

Je remercie vivement tous les participants qui ont activement contribués à réaliser des codes toujours plus optimisés à l’octet prêt.

Je vous invite à regarder les méthodes et solutions de chacun qui recèlent pas mal d’astuces.

Résultats totaux :

Résultats de challenge.png

Vérification sur les quatre finalistes :

Résultats 4 finalistes.png


A bientôt pour de nouvelles aventures !

Emmanuel

Mise à jour au 18/09

Juste pour rappel, j'ai ajouté en lien tous les programmes des participants nommé : Tous les programmes et bench version LV 2010.zip

cela permet de voir les astuces utilisées par chacun. Ainsi que celui de sébastienM

Comments
Nico_EMC
Member
Member
on

Bonjour Emmanuel

Y-aura-t'il un changement d'année ?

Sans coder forcément en dur, est-ce qu'on peut se limiter à 2000-2059 ? (histoire de ne convertir que des chiffres entre 0 et 59 )

Nico

emmanuel-fr
Member
Member
on

Bien vu, j'attendais la question . Alors oui en effet on peut s'arrêter à 59. Tous les chiffres affichés sont pour la plupart en base 60, sauf la date. Donc, calculs ou constantes seraient plus facile a coder en se limitant à 59. j'ajoute cette précision dans l'énoncé. Je laisse un peu de liberté sur les règles pour justement trouver des solutions sympas.

Pour l'acquisition du temps réel, l'heure/date à partir du PC ou serveur de temps semble la plus simple comme il n'y a pas de saisie manuelle dans l'énoncé de la face avant (indicateurs). Et donc pourra bouger naturellement, mais restera dans la plage de quelques années.

emmanuel-fr
Member
Member
on

Suite a une remarque d'un participant, petite précision. Il n'y a pas de zéro dans les chiffres romains donc pour afficher minuit et plus soit 0h00 je propose plutôt que de laisser des espaces vides de placer un caractère O à la place. Cela ne devrait pas se produire très souvent car il n'est pas utile de mettre un zéro avant un autre chiffre, par exemple 1h05 s'écrira I:V et tous les autres sont des entiers non nuls jusqu'à 59...

soft001
Member
Member
on

Peut on utiliser un code m file avec l'outil mathscript ?

emmanuel-fr
Member
Member
on

Oui, mathscript autorisé. il s'agit en fait d'une compilation en VI LabVIEW (mais difficile d'optimiser par le script ensuite)

emmanuel-fr
Member
Member
on

Bonjour, n'hésitez pas à poster vos questions sur la communauté plutôt que de les demander par des Emails ! ce sera plus vivant et profite à tout le monde. (mais j'aime bien les Email aussi). Je sais que la concurrence est rude et les espions...

Aussi je vais répondre a vos interrogations :

- Est il possible d'utiliser des sous-VI ? Oui

- Comment sera faite plus précisément le test avec l'outil profil>> performance et mémoire ?

Le critère de sélection est le total d'utilisation en mémoire à partir de la colonne Octets min. Si il y a des Sous-VI alors ils seront additionnés

Normalement le découpage en Sous-vi n'augmente pas l'utilisation de la mémoire, cependant dans notre cas précis pour l'horloge, je conseille de tout faire en un seul VI, c'est plus facile à optimiser et évite les duplications et recopies.

Eviter aussi les variables locales ou globales, soignez les types et l'utilisation des tableaux

De très bon conseils sont ici :http://zone.ni.com/reference/fr-XX/help/371361J-0114/lvconcepts/vi_memory_usage/

Image profil.png

- Pouvons nous envoyer d'autres versions de nos codes plus optimisés ?

Déjà merci de vos emails et de vos codes pas mal optimisés et si vous voulez en envoyer d'autres c'est sans problème, indiquez à la fin la version V1,V2.. mais évitez la V100 quand même ...

Emmanuel

Mathieu_R.
Active Participant
Active Participant
on

Première version transmise, ça se ballade pour moi en dessous de 5ko... Et vous?

GiulianoFranchetto
Member
Member
on

Bonjour tout le monde ! V2 envoyée, elle tourne autour de 4,15 ko. Premier challenge pour moi, je trouve ces challenges vraiment intéressants.

Giuliano Franchetto
Student at the l'Ecole Nationale Supérieure des Mines de Saint-Etienne, cycle ISMIN (FRANCE)
Mathieu_R.
Active Participant
Active Participant
on

Haha,  v2 en dessous de 4ko!

@Nico_EMC : en ce qui me concerne, le fait de limiter la plage à 0-59 ne m'apporte aucun gain de mémoire...

GiulianoFranchetto
Member
Member
on

v3 envoyée, elle tourne autour de 2,74 ko

Giuliano Franchetto
Student at the l'Ecole Nationale Supérieure des Mines de Saint-Etienne, cycle ISMIN (FRANCE)
emmanuel-fr
Member
Member
on

Impressionnant ! Pas de sous-VI et peu de fonctions mais astucieusement exploitées, je regarde ça de plus près...

Mathieu_R.
Active Participant
Active Participant
on
emmanuel-fr
Member
Member
on

Je suis désolé Mathieu_R, avec les sous-VI cela fait un peu plus de 5k. mais l'horloge reste tout a fait juste et déjà très optimisée.

soft001
Member
Member
on

Peut-on savoir le meilleur record SVP ?

Herlag
Member
Member
on

Quel est le format d'entrée des date et heure à afficher en chiffres romains ? Il n'y a pas d'indications dans le fichier "Main_Mon_pseudo_Chiffres romains.vi"...

Herlag
Member
Member
on

En soi, le fait de limiter à la plage 0-59 ne me fait pas gagner d'utilisation mémoire... quoique un peu quand même en trichant avec la suppression de la plage qui nécessiterait l'affichage de "C" (100) et "D" (500) dans la date [le code n'est donc pas valable pour n'importe quelle date, mais puisque cette tricherie est autoriée ]

Au final, en utilisant comme entrée le VI donnant les date et heure courantes sous forme de cluster (mais est-ce la bonne entrée, rien n'étant indiqué dans l'énoncé ?), ma version 2 tourne juste en dessous de 4500 octets...

Mathieu_R.
Active Participant
Active Participant
on
Herlag
Member
Member
on

Avec la lecture du temps réel en chaîne de date & heure plutôt que sous forme de cluster, et en peaufinant, j'arrive à une version 3 tournant tout juste sous les 4 ko ( ~ 4070 octets). Mais pour descendre sous les 3 ko, je donne ma langue au chat

Herlag
Member
Member
on

Le problème avec ces challenges, c'est que quand on commence à y réfléchir, on ne peut plus s'arrêter

Version 4 autour de 3900 octets... Maintenant, faut juste que j'arrive à décrocher

Mathieu_R.
Active Participant
Active Participant
on

Même addiction J'ai beau avoir envoyé une v4 taillée au chausse pied pour l'utilisation mémoire, j'ai du mal à ne pas replonger, essayer d'immaginer quelque chose de différent, qui ferait mieux... Emmanuel, quelle est la date butoir pour ce challenge? Le 26/08?

GiulianoFranchetto
Member
Member
on

Quelqu'un a t il une idée de quand fini le challenge?

edit : ARF, 1 min trop tard !

Giuliano Franchetto
Student at the l'Ecole Nationale Supérieure des Mines de Saint-Etienne, cycle ISMIN (FRANCE)
Herlag
Member
Member
on

Par curiosité, vous descendez à combien ?

J'ai encore essayé divers trucs (addiction, quand tu nous tiens...), mais je n'arrive pas à mieux qu'autour de 3900 octets.

Mathieu_R.
Active Participant
Active Participant
on

CM#6perf_v5.png

....mais c'est pas forcément une bonne idée de s'en inquiéter pour qui souhaite décrocher du sujet (moi le premier ^^).

Herlag
Member
Member
on

D'une part, faut que je décroche faute de temps. D'autre part, le programme doit être basé sur une tout autre méthode que celle que j'utilise et avec laquelle je ne vois vraiment pas comment gagner encore plus d'1ko d'utilisation de la mémoire !

Je redonne donc ma langue au chat en attendant de voir les autres idées de code...

emmanuel-fr
Member
Member
on

On arrête le challenge à la fin du mois pile, donc le  XXXI/VIII/MMXIII  à  XXIII:LIX:LIX   !!!

Désolé, je n'étais pas en ligne pendant quelques jours (vacances oblige !) et j'ai recu pas mal de programmes et mises à jour à analyser. De plus je planche sur le mois de septembre qui je l'espère sera "spécial" avec des signaux codés.

Moi aussi je deviens un peu dingue des chiffres romains à force de vérifier les codes et j'en vois partout, mais je m'amuse aussi a regarder vos différentes solutions qui seront bientôt dévoilées. Je pense que les astuces peuvent reservir un jour à tout le monde finalement...

Au fait, chaque jour le maillot de vainqueur change, donc je peux rien dire sur le minimum, mais ca tourne <3000

Pas d'inquétude sur la taille min/max dans profil mémoire les VIs sont lancés à la même seconde (mais aléatoire donc)

GiulianoFranchetto
Member
Member
on

v4 envoyée. 2.54 ko en moyenne.

edit : ooooooooh, une nouvelle page rien pour moi! 

Giuliano Franchetto
Student at the l'Ecole Nationale Supérieure des Mines de Saint-Etienne, cycle ISMIN (FRANCE)
adcpc
Member
Member
on

Est-ce que la modification des propriétés du VI est autoriséee (désactiver le debugging, etc) ?

smi38
Member
Member
on

Je dirais oui, sinon ça relève de l'impossible de descendre aussi bas que les résultats postés précédemment.

Herlag
Member
Member
on

Ca change pas mal de choses : juste en supprimant l'option d'activation de la mise au point, ma version 4 passe d'environ 3900 octets à environ 2750 !

Pourquoi pas, mais ça fausse un peu les comparaisons. Ne vaudrait-il pas mieux partir d'un copier-coller des diagrammes pour exécuter les différentes propositions dans des conditions semblables ?

Bon, au cas où, j'envoie une version 5 en supprimant juste le debugging de la 4

smi38
Member
Member
on

Je dirais plutôt que désactiver cette option faisait partie des combines à trouver pour faire chuter la mémoire.

Je dis bien faisait, parceque maintenant, bon, hin, vous m'aurez compris

adcpc
Member
Member
on

Merci pour les résultats.

Concernant le résultat de GiulianoFranchetto, tu peux encore gagner quelques dizaines d'octets (et prendre la deuxième place) et ajoutant un "request deallocation" dans tes boucles.

Herlag
Member
Member
on

Félicitation au gagnant et aux finalistes !

Mais serait-il possible d'avoir les codes en version autre que 2012 ?

Avec ma version LabVIEW 2011, je ne peux voir que... mon propre code

Merci d'avance,

HL

Mathieu_R.
Active Participant
Active Participant
on

*** DISCLAIMER ***

Le code que j'ai proposé ne réponds (absolument) pas aux Guidelines de programmation LabVIEW. Je pense en particulier au fait d'empiler N fonctions incrémenter plutôt que d'utiliser une addition avec une constante, pas très lisible (bien que documenté). Je n'ai pas osé faire un Ctrl+U, mais je pense que ce serait catastrophique... Mais que ne ferait-on pas pour gagner quelques octets...

emmanuel-fr
Member
Member
on

Certes cela ne répond pas à la charte "d'un code propre", mais cela répond au cahier des charges et toutes les astuces sont bonnes à prendre.

emmanuel-fr
Member
Member
on

J'ai ajouté tous les codes en version LabVIEW 2010

GiulianoFranchetto
Member
Member
on

Felicitations au gagnant

vivement le prochain, et merci pour le conseil adcpc!

Giuliano Franchetto
Student at the l'Ecole Nationale Supérieure des Mines de Saint-Etienne, cycle ISMIN (FRANCE)
Mathieu_R.
Active Participant
Active Participant
on

J'ai découvert à l'occasion de ce challenge que chaqueterminal sur le connecteur d'un VI impacte la charge mémoire (16 octets/ terminal semble-t-il). Je crois que seul GiulianoFranchetto et moi avons joué sur ce levier. En utilisant le connecteur le plus simple - à un seul terminal, tu serais passé devant.

smi38
Member
Member
on

Euh Monsieur Roset, pourriez-vous vérifier votre dossier Spam svp ?

Vous n'avez pas utilisé la dernière version que je vous ais transmise samedi (donc dans les temps)

Et normalement comme çà je finis deuxième !

Arg !

smi38
Member
Member
on

Ce que j'ai remarqué c'est qu'il faut à tout prix éviter les tableaux de chaines, et faire des constantes chaines les plus courtes possibles. J'ai donc surtout travaillé sur ce point. (le résultat est dans ma dernière version, hum hum hum )

Et avec l'astuce du connecteur, j'aurais été à 2283o (gloups)

Et vous ?

En tout cas bravo Monsieur Reyrolle, et bonjour à Jean-Louis !

emmanuel-fr
Member
Member
on

Après moultes vérifications, je n'ai rien dans la boite mail pour le 31. Spam compris. Je suis désolé. Pour éviter cela dans les prochains challenge, sachez que j'envoie un mail en retour au minimum avec la phrase "Bien reçu" comme accusé de réception.

En attendant, envoyez moi la version de samedi, je mettrai à jour le tableau d'honneur !

emmanuel-fr
Member
Member
on

J'ai mis à jour le tableau avec le programme dont la date et l'heure à été vérifiée, SebastienM est bien 2 ème à 3 octets près Derrière Mathieu_R dans l'utilisation min mémoire, ce qui avait été défini comme règle de test. A noter qu'il utilise moins de blocs. En tout cas félicitations à tous les participants car cela a nécessité pas mal d'efforts d'optimisation. Je crois que c'est bénéfique car toutes les astuces pourront sûrement êtres réutilisées dans les développements futurs. Je pense que l'on renouvellera ce type de challenge mémoire un jour et vous aurez de l'avance, mais cette fois avec des programmes qui manipulent de plus gros volumes de données.

Herlag
Member
Member
on

Est-il possible d'avoir la version finale du code de Sebastien, celle qui arrive en 2nde position (et de préférence, pas en LV2012) ? Merci d'avance, HL

emmanuel-fr
Member
Member
on

Oui, pas de soucis, j'ai ajouté un ZIP du programme de Sébastien et j'ai ajouté une version LV 2010 avec la 2012

Herlag
Member
Member
on

Merci.

smi38
Member
Member
on

Merci Emmanuel pour la patience ^^

J'utilise une boite gmail, mais je n'ai pas de problèmes habituellement.

J'utilise moins de blocs, mais l'occupation de la mémoire est légèrement supérieure à celle de Mathieu : cela est dû au fait que je n'ai pas trouvé (encore bravo), l'astuce du connecteur de VI unique.

Comme je disais plus haut, je serais à 2283 octets (et toujours 6 blocs) si je l'avais trouvé... les boules

Mais bon, c'était sympa à triturer.

A plus,

Sébastien

Contributors