Curriculum and Labs for Engineering Education
Bonjour à tous,
Pour le mois d'Avril, reprenons notre série de petits défis LabVIEW afin de trouver des nouvelles astuces de programmation.
Ce mois-ci un Livre de programmation LabVIEW de chez DUNOD à gagner.
Il suffit d’envoyer votre code LabVIEW nommé de votre «Pseudo_ch32.vi » à emmanuel.roset@ni.com avant le 30 Avril.
Postez au minimum un "code envoyé" afin que je vérifie les envois dans la boite mail.
Un tirage au sort par loto sera effectué sur les bonnes réponses.
Voici le challenge :
Considérons une simple série qui additionne tous les inverses de i de 1 à N:
On retire de cette série toutes les fractions qui contiennent un moins un chiffre 9 au dénominateur (par exemple 1/9 et 1/396).
La série résultante s'appelle T.
L'entrée du problème est la valeur de n et vous devez répondre en donnant T(n)
Type de retour
Un nombre à virgule (double flottant)
Entrée du problème
Un nombre entre 1 et 10000
Vous pouvez vous aider du code de départ joint pour votre réponse.
N'hésitez pas à poser des questions sur la communauté
Bonne chance à tous
Emmanuel
Ah mince il était préparé en LabVIEW 2010 et j'ai pas mis le bon.. merci d'avoir posé la question, c'est fait
(il est un peu vide par contre 
)
Un tirage au sort par loto sera effectué sur les bonnes réponses"
Quels sont les critères qui définissent "une bonne réponse" ?
Simplement le fait d'implémenter un code qui réalise la fonction demandée ?
Si seul le résultat en sortie définit une "bonne réponse" ...
... je suppose que tout le monde présentera une "bonne réponse".
N'y a t-il pas d'autres critères de sélection ? Par exemple le code "le plus rapide" ?
En réponse à Ouadji, en effet différentes valeurs sont appliquées en entrée pour voir si les résultats sont corrects. Normalement il ne devrai y avoir que des bonnes réponses (pas toujours) puis un tirage au sort est effectué. Cela permet à tout le monde d'avoir une chance car sinon c'est toujours un peu les mêmes qui gagnent car ils sont très fort !
Cependant je réfléchis à un défi dans le défi (juste pour le fun) avec le code le plus rapide car un code a été envoyé en option avec une telle optimisation et des astuces supplémentaires.
Merci emmanuel pour cette réponse.
une question subsidiaire :
Je suppose qu'il est interdit d'utiliser un quelconque Tableau de constantes ?
Je ne parle pas d'un Tableau contenant directement T(N) bien entendu
Mais quel que soit le Tableau de constantes qui serait utilisé ... je suppose que c'est "non" (?)
Ce que je pourrais parfaitement comprendre !
PS: "un défi dans le défi" (option "vitesse") ... pourquoi pas !
Concernant la "vérification des résultats" en appliquant en entrée différentes valeurs ...
attention au fait de comparer des DBLs entre eux.
Comparer les différents résultats (des différents participants) de façon "brute" est illusoire.
Avec un DBL, 2 résultats peuvent être différents et parfaitement corrects tous les deux.
Tous les résultats T(N) peuvent "varier" d'une valeur =< à (N x "machine Epsilon")
Mais tu sais parfaitement cela, toutes mes excuses d'en faire le rappel (inutilement).
Bonne journée emmanuel.
Pour le tableau de constantes, c'est possible si par exemple il s'agit d'un tableau d'entiers qui sert aux calculs, mais biensur par un tableau qui remplace directement les divisions en doubles .
Oui les résultats en doubles font des arrondis aussi je suis tolérant et je prend en compare à au moins 6 chiffres après la virgule. De plus je regarde l'agorithme qui normalement est assez simple.
Pour ceux qui veulent voici une option si cela les intéresse pour essayer d'optimiser encore le code.
Cela ne joue pas sur le prix à gagner mais juste pour le fun.
Je propose de trouver des astuces pour aller le plus vite possible sur un calcul d'une valeur de n > à 9000.
Voici un code de test qui permet de supprimer les tampons mémoire entre chaque appel pour valider les temps.
Je pense l'utiliser.
ok pour le Tableau de constantes "possible".
Pour la suite de ton post ...
oupsss ... 
pas trop d'accord concernant ton code de Benchmark (toutes mes excuses)
Pourquoi ?
Le noeud de Méthode "Run VI" est beaucoup trop lent !
regarde ... j'ai testé avec un VI ne contenant aucun code (un VI vide) ...
Ton Benchmark me donne une moyenne de 780 micro sec !
De mon côté, j'ai 2 codes à proposer
Le 1er (avec n=9000) tourne en 78 micro sec, et le 2eme (tjs avec n=9000) tourne en 19 micro sec.
Donc ta méthode de mesure avec "Run VI" fausse complètement les mesures.
Il faut mettre le code "directement dedans" .. au minimum via un appel de sous-VI.
Là, j'arrive à mesurer des temps corrects.
Ta méthode avec "Run VI" est pratique et élégante ...
mais ce noeud est beaucoup trop lent pour mesurer des temps d'exécution courts.
je te propose ceci, qu'en penses-tu ?
C'est toi le Patron, c'est toi qui décide évidemment !
C'est toi le Boss emmanuel, c'est à toi de décier.
Mais avec la méthode du "open - run/wait until done - close" ... quand je vois que j'ai 780µs de moyenne pour le benchmark d'un vi ne contenant aucun code, cela me porte à la prudence. (sans plus) Je vais te transmettre mon code. Merci pour ces petits challenges bien amusants, c'est très chouette.
J'ai ajouté quelques participants qui ont été un peu bloqués par les rouages des serveurs. Merci pour les messages.
Le tirage est ce soir
Bonjour ! résultats du tirage au sort de Mercredi. C'est la boule 2 qui a désigné le chanceux
| annee_numero_de_tirage | jour_de_tirage | date_de_tirage | date_de_forclusion | boule_1 | boule_2 |
2016 | MERCREDI | 18/05/2016 | 18/07/2016 | 22 | 1 |
Donc le gagnant pour le livre LabVIEW du mois d'avril est Lulu44
Bravo ! 
