arnaudus a écrit 5317 commentaires

Ton nombre de points n'est aucunement un indice de ta dangerosité.

Je pense que tu n'as absolument aucune idée de ce que peut bien être une indication statistique. Tu parles de toi, toi, toi, mais les statistiques ne sont pas faites sur toi. Si je fais des statistiques sur ma gueule, je peux t'affirmer avec autant de prétention que tu le fais que tout le monde est hétéro (d'ailleurs, tout le monde est un homme), tout le monde est brun, et tout le monde a des lunettes. Par contre, personne ne gagne jamais au loto, et tous les fonctionnaires glandent sur Linuxfr. Et qu'il n'y a aucune corrélation entre la taille de la teub et la stature. C'est passionnant, comme statistiques, hein?

Une personne un peu distraite peut se retrouver à repasser son permis à coup de un point enlevé (flash à 56 km/h corrigés à 52 dans une zone limitée à 50).

Ta personne un peu distraite roule simplement à 60 au lieu de 50, soit 20% trop vite. Calcule combien ça ferait de gagner 20% de plus ou de moins, tu verras que ça n'est pas une marge acceptable.

D'ailleurs, je ne vois pas la différence entre rouler 12 fois à 60 devant un radar et rouler 12 fois à 60 devant une école.

Et puis, merde, quand on parle du code de la route, on parle de consignes de sécurité à appliquer parce que c'est la loi. C'est comme attacher sa ceinture en avion, passer la visite médicale du travail tous les ans, ou remplir sa déclaration d'impots. Ça fait partie des règles de vie en société, on peut très bien penser qu'une limitation est trop basse (j'en connais), que d'autres sont trop hautes (j'en connais également, mais celles-là, on n'en parle jamais), et alors? Tu vas commencer à remettre tout en cause? Si à la cantine les entrées valent 1,20€, tu ne vas pas demander à payer les carottes râpeés 1€ seulement, parce que les asperges sont aussi à 1,20€ et qu'elles ont plus de valeur. Le code de la route est un truc à prendre dans son entier, il n'y a pas des milliards de petits cas particuliers, il y a un jeu de règles simples qui sont raisonnables la plupart du temps, et il est beaucoup plus reposant de les appliquer tout le temps plutot que de passer ton temps à te demander s'il ne serait pas possible de rouler à 55 entre le rond-point et le virage qui suit.

"en douce" n'est probablement pas le bon mot. Disons qu'il existe un schéma acceptable et éthique, qui consiste à placer systématiquement les logiciels scientifiques sous une licence permissive (accès aux sources, pour des questions de vérifiabilité, et autorisation au moins pour l'utilisation non-commerciale, pour des raisons de reproductibilité). La plupart des scientifiques sont passés d'une pratique un peu archaïque (envoi des sources sans aucune information de licence) à une pratique un peu plus formelle (mise sous licence libre). Cependant, à ma connaissance, l'employeur est officiellement contacté seulement dans le cas de très gros logiciels, dont le financement est spécifique (l'argent a été obtenu dans le but de développer le logiciel). Pour les petits outils, la procédure est totalement inadaptée, et personne ne veut prendre le risque de voir une requête rejetée au bout de 12 mois parce que les gens qui siègent dans ces services sont incompétents. En général, l'outil est mis à disposition au moment de la publication des résultats.

Ceci dit, il existe également un autre cas de transfert de propriété intellectuelle qui n'est pas effectué dans les règles, c'est lors de la publication dans une revue qui demande à remplir un formulaire de transfert de copyright. Les auteurs signent le papier et transfèrent leurs droits à la revue, alors que techniquement cette transmission n'a aucune valeur juridique, puisque les droits appartiennent à l'employeur.

Mon sentiment, c'est que les instituts de recherche se couvrent par des clauses que personne ne respectent, et qui sont éthiquement inacceptables—ne pas publier le code et ne pas permettre la vérification des résultats n'est éthiquement pas concevable. Par conséquent, les chercheurs ont donc tendance à privilégier la simplicité et la pratique éthique de leur boulot, au nez et à la barbe de leur administration, en partant du principe que ces règles absurdes ne les concernent pas vraiment et sont destinées à gérer les cas un peu limite quand des partenariats industriels ou des histoires de gros sous entrent en jeu.

Perso, je développe des applications libres "en douce". Le développement est une activité secondaire pour moi, les softs, scripts et paquets restent des outils de support à mon activité scientifique (par exemple, des outils d'analyse de données, des logiciels de simulation implémentant des modèles très spécifiques, etc). La politique de mon employeur (le plus gros EPST de France, pour ne pas le nommer) est hyper prudente (genre, "All your bases are belong to us, mais faites ce que vous voulez, on s'en branle, sauf que le jour où on s'y intéressera on pourra vous emmerder). Du coup, je mets mes softs sous GPL, ce qui de toutes manières est très sain pour l'activité scientifique—le passage par le service "valorisation" officiel serait de toutes manières beaucoup trop long et nuirait à la publication des résultats.

Tu considère l'ensemble de la vie comme un développement unique ?

Bah c'est un soft unique, avec des millions de forks et de projets qui disparaissent. Mais c'est le même logiciel depuis le début.

Cependant, le modèle du bazar a, à mon avis, permis quelques réussites

Je pense qu'on peut aller beaucoup plus loin que ça. Le modèle bazar est le seul modèle de développement qui a jamais démontré qu'il était possible de mettre en place, d'améliorer, et de complexifier un système sans aucune régression bloquante pendant 3 milliards d'années. À côté de ça, quelles sont les réussites d'un système cathédrale? Oui, bon, OK, les cathédrales. Les constitutions démocratiques les plus anciennes ont à peine plus de 2 siècles, et de toutes manières on voit bien que les systèmes juridiques se développent selon le modèle du bazar. Il semble que le fonctionnement de type cathédral soit limité à des projets de taille réduite, et surtout au développement limité dans le temps (une cathédrale est finie, on n'y touche plus). Dès qu'il faut maintenir l'objet, le faire évoluer, le complexifier, le rendre robuste à un environnement imprévisible, le développement cathédrale ne peut tout simplement plus tenir la route—et plus on s'approche du point de rupture, plus il faut d'énergie pour continuer à faire progresser le bouzin.

Même si quelque chose est breveté rien ne t'empêche de le réaliser pour toi-même !

Je crois que non. À ma connaissance, la seule exception au brevet est le cas où tu as inventé le procédé indépendamment du brevet.

Eh mon code de 2 lignes fonctionne, lui :-) Par contre, je ne vois pas l'intérêt de fournir 5 tests qui ne font pas le tour des possibilités. Ça veut dire qu'un algo faux peut avoir tous les points?

En tout cas, ça confirme bien mon idée de départ, le problème est bien de trouver la solution mathématique à l'exercice, pas de l'implémenter.

Bah, je vois bien l'idée générale, parler de la possibilité de s'autohéberger, mais ça part juste dans tous les sens : dailymotion, github, les «recommandations pour les tags», etc : de ton point de vue, il y a peut-être une logique, mais il me manque des informations pour la capter. Si c'est le bordel dans ta tête, ça serait utile de l'organiser un peu pour communiquer avec les autres, parce que personnellement, ça a été relativement pénible pour moi d'essayer de comprendre par quel chemin logique tu passais entre les points. Est-ce que par exemple tu peux imaginer la souffrance intellectuelle que peut provoquer une phrase comme «même un WAMP permet de le faire fonctionner hein, qui paie pour le W plutôt qu'un L ? qui paie pour le L et le reste installé ?». Visiblement non, ou alors tu es sadique.

J'aime bien la réaction du gars à qui on explique que son truc n'est pas clair. « Mais si c'est clair! ». Bah non, si les leceurs disent que ça n'est pas clair, c'est que ça n'est pas clair. Perso, je n'ai pas compris non plus de quoi tu voulais parler, et le rapport entre la choucroute du début et le cassoulet de la fin.

Tu veux dire, Ubuntu/Debian/GNU/Linux?

c'est pas très élégant exécuter pleins de fonctions à la suite sur la séquence quand la parcourir une fois suffit

Ah, je pense que c'est un problème de culture et de définition de l'«élégance» :-) Classiquement, quand on utilise un langage de haut niveau, on est moins exigeant sur la performance brute. Je n'ai pas de culture algorithmique, et à mes yeux, quelque chose comme "amplitude <- max(x) - min(x)" est beaucoup plus élégant qu'une boucle qui ne fait qu'une passe : quelque part, on touche presque au langage naturel.

L'autre truc, c'est que quand on a un langage non compilé, on ne peut que deviner la manière dont les opérations sont optimisées, mais en faisant les tests, on peut avoir des surprises :

x <- rnorm(10000000)
> system.time(max(x)-min(x))
   user  system elapsed 
  0.128   0.000   0.132
> system.time(diff(range(x)))
   user  system elapsed 
  0.160   0.044   0.212

Visiblement, dans ce cas, il vaut mieux faire deux passes qu'une seule (je ne sais pas pourquoi, ça vient peut-être de l'implémentation en C des fonctions correspondantes).

c'est joli d'écrire ça en 4 lignes mais il y a plus efficace

Certes, on peut écrire ça en assembleur aussi… Je ne suis pas certain que les consignes étaient spécialement claires. Apparemment, la lisibilité était évaluée sur des critères peu convainquants, et je n'ai pas lu de remarques sur le contexte. Typiquement, le code le plus efficace devra tenir compte des contraintes (exécuter rarement sur des gros jeux de données, exécuter des milliers de fois sur des vecteurs de taille 10, etc) qui peuvent rendre toute tentative d'optimisation a priori totalement contre-productive.

si R est assez bon pour ne pas exécuter les 2 min(s)

Ça me parait très peu probable. R est un langage de script, il exécute les instructions les unes après les autres. Par contre, je ne suis pas convaincu que le stockage du contenu des min et des max soit plus rapide que le double appel à la fonction : c'est complètement empirique.

Je m'auto-réponds encore une fois (rien que pour le plaisir de voir les geekscottes), il y a beaucoup plus simple (mais en O(n²))! . Je ne sais pas si la lisibilité et la concision étaient privilégiées sur l'efficacité.

s <- scan("stdin")[-1]
cat(min(sapply(1:length(s), FUN=function(x) { min(s[x:length(s)]-s[x])})))

Tu as raison, mais mon code a passé les 5 tests proposés sur le site, je n'ai pas cherché plus loin. Du coup, mon argument "c'est trop simple" tombe à l'eau, non? :-) Bon, ce n'est pas si compliqué que ça, il faut appliquer la recherche entre le début et le dernier minimum, et entre le premier maximum et la fin, et prendre la plus grande différence.

s <- scan("stdin")[-1]
lastmin <- min(s)-max(s[1:rev(which(s==min(s)))[1]])
firstmax <- min(s[which(s==max(s))[1]:length(s)])-max(s)
cat(min(lastmin, firstmax),"\n")

Si c'est tout à fait possible (peut-être 4 lignes), mais j'ai eu la flemme :-)

Tiens, pour jouer, voici la solution du 2 en R :

s <- scan("stdin")[-1]
m <- which(s==min(s))
cat(min(s)-max(s[1:m[length(m)]]),"\n")

Encore une fois, il n'y a même pas d'algorithme : on a une entrée, un calcul hyper simple, et une sortie. La seule difficulté de l'exercice, c'est la modélisation du problème, et éventuellement savoir coder min() et max() si le langage n'offre pas des fonctions aussi simples.

Bref, je confirme que les problèmes sont bien trop ennuyeux à mon goût.

Ça n'engage que moi, mais je trouve que les exercices ne sont pas assez intéressants pour ce type de concours. Leur difficulté principale reste la modélisation du problème et la découverte d'une solution mathématique. Le code, au final, contiendra surtout des entrées sorties, et deux lignes pour l'algorithme.

L'autre problème, c'est que le peu d'algorithmique présente est purement scolaire : trier, prendre le maximum, le minimum, la médiane, etc. Quelqu'un qui a bien révisé peut coder ça sans réfléchir, mais ça n'a vraiment aucun intérêt, puisque dans la vraie vie, on a tout intérêt à utiliser des bibliothèques optimisées et débugguées pour ça. Je pense qu'en 2012, on doit réfléchir autrement sur ce qu'est un programmeur efficace : quelqu'un qui sait utiliser les bons design patterns, les bons outils, les bonnes briques logicielles existantes, etc. Il existe d'excellents exercices d'algorithmique : concevoir une intelligence artificielle pour un jeu, par exemple. Des trucs où il faut être inventif et précis, avoir une bonne intuition sur les contraintes à l'utilisation (identifier tôt les bottlenecks potentiels), etc.

En gros, j'ai l'impression de pouvoir résoudre ces problèmes en 3 lignes avec un langage de haut niveau. Sérieux, en R, la réponse au problème 3 est

m <- matrix(scan("")[-1], ncol=2, byrow=TRUE)
print( diff(range(m[,1])) + sum(abs(m[,2]-median(m[,2]))) )

Il n'y a rien à coder une fois la solution mathématique trouvée.

Franchement, je pense que c'est complètement parano : le nombre de permissions doit être limité, justement pour que l'utilisateur puisse comprendre à quoi l'application a accès. "Accès réseau", "Connaitre l'État du téléphone" semblent être des permissions compréhensibles pour tout le monde. Comment veux-tu expliquer en deux lignes "Cette application peut savoir si le téléphone est actif, mais ne peut pas connaitre le numéro appelé, à moins qu'il soit référencé dans le carnet d'adresse"? Une granularité fine dépend au final des besoins des développeurs ; s'il faut une permission pour chaque accès matériel (accéder à la mémoire, accéder au micro, accéder aux hauts-parleurs, accéder à l'écran tactile…), l'utilisateur devra accorder des douzaines de permissions : non seulement ça donnera encore plus l'impression que les applis sont extrêmement intrusives, mais ça diminuera encore plus le sentiment de méfiance : puisque toutes les applis demandent 50 permissions, on valide, on ne lit même plus. La seule alternative à la multiplication de ces permissions serait un score d'intrusivité, ou quelque chose comme ça. "Vie privée: 5 étoiles, Risques pour le système: 3 étoiles, Intrusivité par rapport à l'utilisation du téléphone : 2 étoiles", etc.

La demande de droits abusive est certainement une pratique contestable, mais histoire de balancer un peu les choses, j'ai entendu pas mal de developpeurs d'applis se plaindre de la mauvaise granularité des droits, ce qui explique en partie les droits ahurissants demandés. Par exemple, pour empêcher la mise en veille, pour avoir le droit de se connecter à un serveur de high-scores, ou pour pouvoir accéder à l'accéléromètre, il faut demander tout un tas de droits dont on n'a pas besoin (accès illimité au réseau, GPS, identité du téléphone, etc). L'exemple le plus frappant à ma connaissance était un développeur accusé de demander abusivement le pouvoir d'appeler les numéros qu'il voulait, alors que sa motivation était de pouvoir sauvegarder un truc en cas d'appel téléphonique, pour éviter que l'appli ne tourne pendant l'appel. Donc voila, oui, mais il ne faut pas tomber dans les accusations trop faciles.

C'est très pertinent. Je me souviens du fameux troll CMJN, gna gna gna Gimp ne sait pas le prendre en compte, ça fait amateur, etc. L'implémentation de la quadrichromie dans Gimp n'a absolument rien changé au marché, maintenant c'est les images 16 bits, et si ça n'était pas ça, ça serait encore autre chose. Chacun est libre d'utiliser le logiciel qu'il souhaite, mais il n'est pas nécessaire de se sentir obligé de justifier son choix par des fausses raisons. Évidemment, un logiciel libre comme Gimp ne peut pas être à la pointe sur tous les fronts, mais Gimp implémente 98% des fonctions disponibles dans Photoshop. C'est un peu ridicule de passer son temps à prétendre qu'on a à tout prix besoin de ces 2% de fonctionnalités que personne ne comprend vraiment, et que personne dans l'équipe de Gimp (pourtant pas des quiches en traitement d'image) n'a trouvé bon d'implémenter. Bref, à mon avis, c'est un faux argument pour justifier un choix non-rationnel.

Personnellement, ce que je trouve beaucoup plus critiquable dans Gimp, c'est l'ergonomie et le manque d'intuition. J'accepte très facilement de lire un manuel pour une interface en ligne de commande, mais une interface graphique doit être construite pour pouvoir être utilisée intuitivement (y compris en respectant les us et coutumes arbitraires, comme l'ordre des menus, etc). Je n'utilise Gimp que très sporadiquement, et à chaque fois, j'ai l'impression que le logiciel ne fait pas ce que j'attends de lui, c'est très agaçant. Après, je n'ai jamais touché à photoshop de ma vie, donc je ne peux pas comparer.

Je ne vois pas pourquoi on ne devrai pas l'utiliser. Si on commence à ne plus utiliser tous les outils qui sont des fois mal utilisés, on va vite se retrouver avec une langue dénuée de toutes subtilités.

Une subtilité, c'est quand on peut exprimer une idée particulière d'une manière précise. Ici, il n'y a rien de subtil, il y a juste une série de termes dont la signification est totalement confuse du fait d'une multitude de faux amis avec l'anglais. Si on admet qu'une langue se définit par l'usage, alors "trillon" veut dire plusieurs choses en français, sans que le contexte ne permette de trancher. Je dirais, au contraire, que c'est une absence de subtilité.

En français de France, par exemple, «un portable» peut désigner soit un téléphone portable, soit un ordinateur portable. Qui ne s'est jamais engagé dans un quiproquo à cause de cette confusion? Ce vocabulaire foireux est simplement lié à l'évolution de la langue, on y peut rien, mais ce n'est en rien une subtilité. Au contraire, utiliser «mobile» pour un téléphone et «portable» pour un ordinateur introduit une subtilité bienvenue.

en revanche, "ambigü" n'est toujours pas correct

Ah oui, pardon, je croyais que ça avait été harmonisé. Ambigu, ambigus, ambigüe, ambigüité.

Dommage que les trémas n'aient pas été utilisés pour remplacer les affreux circonflexes sur piqûre, par exemple, qui devient piqure avec la nouvelle orthographe, mais qui aurait bien pu s'orthographier "piqüre" à mon avis…

Tout à fait.

Système européen, 10⁹ = 1 milliard, 10¹² = 1 billion, 10¹⁵ = 1 billiard, 10¹⁸ = 1 trillon.

Système anglo-saxon: 10⁹ = 1 billion, 10¹² = 1 trillon, 10¹⁵ = 1 quadrillon, 10¹⁸ = 1 quintillon.

Conclusion : ne JAMAIS utiliser en français un système aussi débile et ambigü.

Sérieux, il faut arrêter avec ces horreurs que sont les "billions" et les "trillons". Ces dénominations sont super-ambigües et désignent des nombres qui n'ont rien à voir en fonction des conventions en vigueur dans les pays.

Je pense que tu as recopié ce "trillon" sur un site anglo-saxon, il doit donc faire référence à mille milliards (10¹²). Or, en français, un trillon, c'est un milliard de milliard, donc 10¹⁸. Dans tous les cas, c'est ambigü, même quand c'est bien utilisé, et même les traducteurs professionnels se vautrent tellement souvent que quand on lit "un trillon", il y a à peu près une chance sur deux pour que ça soit l'un ou l'autre. Je pense que le plus sage est de ne jamais utiliser un terme aussi ambigü.

NdM : cf. page Wikipédia Échelles longue et courte.

Bah, surtout qu'à ma connaissance, le moteur de rendu HTML n'est pas codé en javascript… Peut-être que ça vient du fait que ça a dû être une extension à l'origine?