Certainement pas "mathématique". C'est une sorte d'heuristique algorithmique, un peu du même genre que "sin(60°) ~ e/π"
j'appelle ça mathématique moi.
C'est peut-être le fait que ce soit une approximation ou qu'elle se sert de la représentation binaire des nombres qui te donne l'impression que ça ne l'est pas ?
Posté par moi1392 .
En réponse au journal "beauté du code".
Évalué à 4.
Dernière modification le 29 septembre 2014 à 16:13.
Je ne sais pas ce que l'auteur de la dépêche avait en tête en parlant de beau code.
Mais moi, cela me fait plutôt penser à une architecture fonctionnelle, bien pensée et bien écrite pour ton logiciel.
Là tu présentes une astuce mathématique pour améliorer (ou pas, cette astuce est ancienne, elle a peut-être déjà été prise en compte dans les architecture/runtime récent) la performance de la fonction racine carrée.
C'est une belle astuce mathématique, mais cela n'a pas de sens pour moi, d'essayer de qualifier ce code de beau ou non.
À part peut-être pour le style comme le choix des noms de variables, l'indentation, …
[…] a été élu démocratiquement, ayant préalablement clairement exprimé son avis sur la question de la peine de mort. La preuve que les Français ne devaient pas y tenir tant que ça…
Je ne prononce pas sur le cas de la peine de mort en particulier, mais l'argument que je vois souvent de dire que X à été élu démocratiquement et que dans ses promesses électorales, il y avait la proposition Y, donc que tous les français sont d'accord avec Y, c'est quand même se moquer du monde.
Si j'ai 2 candidats qui se présentent, avec 10 propositions chacun, en supposant que leurs propositions soient sincères et qu'elles vont être mises en place (haha, la bonne blague…)
Si le promier a 5 propositions qui me conviennent et 5 que je trouve ultra mauvaises, le second a 8 propositions qui me conviennent et 2 que je trouve ultra mauvaises, venir argumenter que j'étais d'accord avec ces 2 propositions parce que j'ai voté pour le second candidat, c'est quand même bien se moquer de moi…
Posté par moi1392 .
En réponse à la dépêche Sortie de Plasma 5.0.
Évalué à 4.
Dernière modification le 23 juillet 2014 à 10:27.
Pour être encore plus précis, "KDE Applications" ne sera pas l'équivalent des ancien "KDE SC 4.x", les KDE SC étaient un compilation des kdelibs, du workspace et de certaines applications.
Maintenant, le rythme de sortie de kde frameworks, du workspace (plasma) et des application est désynchronisé, il n'y a plus de sortie commune de prévu.
Ou une idée complètement folle ! Assembler des bombes en forme de pas-batterie pour en mettre une ailleurs, c'est pas bien gros une batterie de téléphone, il doit y avoir moyen de trouver beaucoup de choses de cette taille à remplacer, surtout dans un ordinateur portable (le disque dur par exemple, et on le fait booter sur une clé usb placée à l'intérieur de la machine)
au pire, si c'est juste pour voler ton code pin (je pense qu'ils ont d'autres méthodes bien plus efficaces pour ça…), il te suffit de le changer en (par exemple) 0000 juste avant ton arrivée à l'aéroport, pour de remettre ton code original plus tard.
Ou alors, encore mieux, tu arrives avec ton téléphone déjà démarré et dévérouillé !! \o/
Le point intéressant est surtout qu'il n'y a pas besoin de feu si TOUTES les voitures sont automatiques.
Un feu est un outil de synchronisation des véhicules. S'ils se synchronisent autrement, cela deviens superflu.
C'est quoi le rapport avec le système d'exploitation ?
le problème dans la protections des données c'est :
1) que les gens s'en foutent, ils les donnent allègrement à facebook et google.
2) que les gens ne comprennent pas où sont leur données, c'est plus un problème d'éducation dans l'utilisation des services (web pour la plupart). Et donc ce sont les protocoles qu'il faudrait revoir.
d'ailleurs, je ne sais pas comment elle s'en sort, il me semblait (et après vérification, c'est bien le cas) que c'était implémenté avec un rb-tree.
Du coup ta réponse devrait être la bonne est l'accès au plus petit élément devrait être de complexité log(n)
c'est donc unse insertion triée ;) ce que tu décris, c'est une std::map (implémenté par un red/black tree au moins dans la lib c++ livrée avec gcc)
Surtout, le problème que je vois, c'est que les cases sont en plusieurs exemplaires dans la file. Comment tu gères ça ?
Un élément de ta file, c'est (case, altitude), si deux paires (case, altitude) sont identiques, l'insersion n'a rien à faire, sinon tu as un nouvel élément qui est différent.
Au moment de transformer une case de terrain en rivière, tu prends le premier élément de ta liste, et si c'est déjà de l'eau (parce qu'il avait été inserée et déjà converti avant), et bien tu le zappes juste.
Effectivement, je crois qu'il y a du flou. Parce qu'il parle de mettre une case potentiellement deux fois, ou de mettre à jour son potentiel. Dans les deux cas, je ne vois pas bien comment on fait.
je parlais bien de mettre une case avec son potentiel dans la liste. ET à ce moment là, si la même case se retrovuve avec un potentiel différent (car venant d'ailleurs), cela fait un élément different de la liste, donc pas de soucis.
enfin, pour le tri, tu ne le fait que sur le potentiel, donc cela ne devrait pas etre beaucoup plus lent (en fait, j'avais plutôt cru comprendre que c'est une insersion triée que tu fais et pas un tri global à chaque fois)
La complexité est ajoutée au moment d'ajouter un élément dans ta liste triée. Il faut pondérer son altitude absolue par un facteur "judicieusement" choisi.
Et ça, je conçois tout à fait que ça n'est pas trivial.
Mais une fois ce mécanisme en place, tu peux essayer plusieur facteurs de pondération et voir comment ils influent sur le résultat ! (cf, le second message de mes 2 posts successifs)
64 ko me parait très peu, est ce que tout ce qui est affiché est purement paramétrique et construit à partir d'équations ? Où y a-t-il des données qui ne sont pas dans l'exécutable et pas contabilisés ?
Quid des libs aussi ? parce que rien que libGL.so, ça fait déjà un joli paquet de Mo…
et tant qu'on y est, si cette solution marche, on pourrait même imaginer favoriser les lignes droites de la même façon, en ajoutant un petit aléa dans les altitudes des cases adjacentes.
Alea inférieur à la différence d'altitude minimale entre 2 cases, car cela reste le critère le plus important, mais qui aurait un légère chance d'être plus élevé si la rivière continue en ligne droite plutôt que de tourner !
Mais quand tu insères ta case dans ta file, tu sais d'où tu viens, non ? donc tu peux utiliser une altitude absolue "ajustée" pour le tri à ce moment là.
Et si tu retombes sur la même case en venant d'ailleurs, rien ne t'empêche de l'insérer une seconde fois avec une autre altitude ajustée !
C'est sans doute aussi un biais au niveau des données, parce qu'en allant en diagonale, tu as plus de chance d'avoir une différence d'altitude plus élevée qu'avec la case à côté.
Est ce que tu pondères la différence d'altitude avec la distance ? vu que tes tuiles sont carrées, on peut considérer qu'une case sur le coté est à une distance de 1 et qu'une case sur la diagonale à une distance de
Tout ce qui passe par la mémoire du processus !
Je ne connais pas assez l'architecture des serveurs web, mais est ce que, par exemple, apache, fait tounrer dans le même process, la compilation du php, leservicede page web et le protecole de communication, en particulier les algos de chiffrement ?
Tout ce qui est exécuté dans des processus séparés devrait à priori ne pas devoir être impacté, non ?
L'installation de ton paquet n'écrit pas forcément directement dans ton home, mais l'utilisation du logiciel installé y sauvegarde généralement ses préférences.
Et il arrive que le format change et devienne incompatible avec une ancienne version.
si tu arrive avec ton code imbitable généré par lex et que par magie tu arrive à le faire accepter
Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
"Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code"
Il n'aura rien ré-écrit du tout car ce "pathé de code imbitable" n'est pas écrit. Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
Inventer une soupe contextuelle et sortir ton lex/yacc en bloatant ton système de build est juste inacceptable.
Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format, et quand j'ai à analyser cela, je crée un analiser lexical avec lex que je couble avec un petit switch. Tu as remarqué que dans mon post original, je prenais soin de mentionner que je ne couplais en aucun cas ça avec du yacc/bison.
Encore une fois, si j'ai 3 mots clés que je lis 2 fois chacuns, je ne le fais pas. Quand cela commence à gonfler, c'est le tas de if/else avec des comparaisons de chaines qui deviens du bloat.
Le plus simple restant encore de ne pas écrire de grammaire soi-même et d'utiliser des parseurs que d'autres ont écrits.
Une fois encore, je n'écris pas de grammaire !! juste un automate à état finis généré par lex que je couple avec un switch en C
Après si c'est lex qui te donne des boutons, tu n'as qu'à l'écrire à la main ton automate, mais tu seras moins bon que lui et quand ce que tu auras à parser change, il faudra le réécrire, c'est pas terrible.
[^] # Re: Plutôt beauté du design
Posté par moi1392 . En réponse au journal "beauté du code". Évalué à 3.
j'appelle ça mathématique moi.
C'est peut-être le fait que ce soit une approximation ou qu'elle se sert de la représentation binaire des nombres qui te donne l'impression que ça ne l'est pas ?
[^] # Re: Plutôt beauté du design
Posté par moi1392 . En réponse au journal "beauté du code". Évalué à 4. Dernière modification le 29 septembre 2014 à 16:13.
Je ne sais pas ce que l'auteur de la dépêche avait en tête en parlant de beau code.
Mais moi, cela me fait plutôt penser à une architecture fonctionnelle, bien pensée et bien écrite pour ton logiciel.
Là tu présentes une astuce mathématique pour améliorer (ou pas, cette astuce est ancienne, elle a peut-être déjà été prise en compte dans les architecture/runtime récent) la performance de la fonction racine carrée.
C'est une belle astuce mathématique, mais cela n'a pas de sens pour moi, d'essayer de qualifier ce code de beau ou non.
À part peut-être pour le style comme le choix des noms de variables, l'indentation, …
[^] # Re: Séparateur de chiffre
Posté par moi1392 . En réponse au journal C++14. Évalué à 3.
reste à savoir si le séparateur de chiffres peut etre utilisé en début d'un nombre ou juste entre au moins 2 chiffres, sinon on pourrait écrire :
et ça, ça va être vraiment bizarre…
[^] # Re: Séparateur de chiffre
Posté par moi1392 . En réponse au journal C++14. Évalué à 4.
_ suivi d'un nombre peut aussi être un nom de variable.
[^] # Re: Droit des marques
Posté par moi1392 . En réponse au journal Le Parisien attaque un blog pour contrefaçon, ou comment se tirer une balle dans le pied. Évalué à 9. Dernière modification le 27 août 2014 à 00:52.
Je ne prononce pas sur le cas de la peine de mort en particulier, mais l'argument que je vois souvent de dire que X à été élu démocratiquement et que dans ses promesses électorales, il y avait la proposition Y, donc que tous les français sont d'accord avec Y, c'est quand même se moquer du monde.
Si j'ai 2 candidats qui se présentent, avec 10 propositions chacun, en supposant que leurs propositions soient sincères et qu'elles vont être mises en place (haha, la bonne blague…)
Si le promier a 5 propositions qui me conviennent et 5 que je trouve ultra mauvaises, le second a 8 propositions qui me conviennent et 2 que je trouve ultra mauvaises, venir argumenter que j'étais d'accord avec ces 2 propositions parce que j'ai voté pour le second candidat, c'est quand même bien se moquer de moi…
[^] # Re: Plasma 5 = KDE 5 ?
Posté par moi1392 . En réponse à la dépêche Sortie de Plasma 5.0. Évalué à 4. Dernière modification le 23 juillet 2014 à 10:27.
Pour être encore plus précis, "KDE Applications" ne sera pas l'équivalent des ancien "KDE SC 4.x", les KDE SC étaient un compilation des kdelibs, du workspace et de certaines applications.
Maintenant, le rythme de sortie de kde frameworks, du workspace (plasma) et des application est désynchronisé, il n'y a plus de sortie commune de prévu.
[^] # Re: Déverrouiller
Posté par moi1392 . En réponse au journal Portables, tablettes, smartphones déchargés interdits dans les avions. Évalué à 4.
Ou une idée complètement folle ! Assembler des bombes en forme de pas-batterie pour en mettre une ailleurs, c'est pas bien gros une batterie de téléphone, il doit y avoir moyen de trouver beaucoup de choses de cette taille à remplacer, surtout dans un ordinateur portable (le disque dur par exemple, et on le fait booter sur une clé usb placée à l'intérieur de la machine)
[^] # Re: Déverrouiller
Posté par moi1392 . En réponse au journal Portables, tablettes, smartphones déchargés interdits dans les avions. Évalué à 3.
au pire, si c'est juste pour voler ton code pin (je pense qu'ils ont d'autres méthodes bien plus efficaces pour ça…), il te suffit de le changer en (par exemple) 0000 juste avant ton arrivée à l'aéroport, pour de remettre ton code original plus tard.
Ou alors, encore mieux, tu arrives avec ton téléphone déjà démarré et dévérouillé !! \o/
[^] # Re: Ça me met en colère !
Posté par moi1392 . En réponse au journal Turing est battu. Évalué à 5.
Le point intéressant est surtout qu'il n'y a pas besoin de feu si TOUTES les voitures sont automatiques.
Un feu est un outil de synchronisation des véhicules. S'ils se synchronisent autrement, cela deviens superflu.
[^] # Re: un autre sujet d'étude
Posté par moi1392 . En réponse au journal [+]. Évalué à 2.
Cela porte un nom : http://fr.wikipedia.org/wiki/Biais_de_confirmation
[^] # Re: Et le nom du projet ?
Posté par moi1392 . En réponse au journal La novlangue fait son entrée dans Django. Évalué à 5.
et master/slave ça venait de l'informatique.
# "Il devra garantir la protection des données"
Posté par moi1392 . En réponse au journal Système d'exploitation "made in france" -- Cocorico. Évalué à 7. Dernière modification le 26 mai 2014 à 14:59.
C'est quoi le rapport avec le système d'exploitation ?
le problème dans la protections des données c'est :
1) que les gens s'en foutent, ils les donnent allègrement à facebook et google.
2) que les gens ne comprennent pas où sont leur données, c'est plus un problème d'éducation dans l'utilisation des services (web pour la plupart). Et donc ce sont les protocoles qu'il faudrait revoir.
[^] # Re: Rivière en diagonale, et taille des rivière?
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E11 : génération procédurale de carte (partie 2). Évalué à 2.
d'ailleurs, je ne sais pas comment elle s'en sort, il me semblait (et après vérification, c'est bien le cas) que c'était implémenté avec un rb-tree.
Du coup ta réponse devrait être la bonne est l'accès au plus petit élément devrait être de complexité log(n)
[^] # Re: Rivière en diagonale, et taille des rivière?
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E11 : génération procédurale de carte (partie 2). Évalué à 2.
tu m'as mis le doute, mais la doc n'est pas d'accord avec toi : http://www.cplusplus.com/reference/map/map/begin/
complexity : constant
[^] # Re: Rivière en diagonale, et taille des rivière?
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E11 : génération procédurale de carte (partie 2). Évalué à 2.
c'est donc unse insertion triée ;) ce que tu décris, c'est une std::map (implémenté par un red/black tree au moins dans la lib c++ livrée avec gcc)
Un élément de ta file, c'est (case, altitude), si deux paires (case, altitude) sont identiques, l'insersion n'a rien à faire, sinon tu as un nouvel élément qui est différent.
Au moment de transformer une case de terrain en rivière, tu prends le premier élément de ta liste, et si c'est déjà de l'eau (parce qu'il avait été inserée et déjà converti avant), et bien tu le zappes juste.
[^] # Re: Rivière en diagonale, et taille des rivière?
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E11 : génération procédurale de carte (partie 2). Évalué à 2.
je parlais bien de mettre une case avec son potentiel dans la liste. ET à ce moment là, si la même case se retrovuve avec un potentiel différent (car venant d'ailleurs), cela fait un élément different de la liste, donc pas de soucis.
enfin, pour le tri, tu ne le fait que sur le potentiel, donc cela ne devrait pas etre beaucoup plus lent (en fait, j'avais plutôt cru comprendre que c'est une insersion triée que tu fais et pas un tri global à chaque fois)
La complexité est ajoutée au moment d'ajouter un élément dans ta liste triée. Il faut pondérer son altitude absolue par un facteur "judicieusement" choisi.
Et ça, je conçois tout à fait que ça n'est pas trivial.
Mais une fois ce mécanisme en place, tu peux essayer plusieur facteurs de pondération et voir comment ils influent sur le résultat ! (cf, le second message de mes 2 posts successifs)
# 64 ko, data comprises où non ?
Posté par moi1392 . En réponse au journal The Timeless hacke ta machine et ton cerveau. Évalué à 3. Dernière modification le 30 avril 2014 à 13:46.
64 ko me parait très peu, est ce que tout ce qui est affiché est purement paramétrique et construit à partir d'équations ? Où y a-t-il des données qui ne sont pas dans l'exécutable et pas contabilisés ?
Quid des libs aussi ? parce que rien que libGL.so, ça fait déjà un joli paquet de Mo…
[^] # Re: Rivière en diagonale, et taille des rivière?
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E11 : génération procédurale de carte (partie 2). Évalué à 2.
et tant qu'on y est, si cette solution marche, on pourrait même imaginer favoriser les lignes droites de la même façon, en ajoutant un petit aléa dans les altitudes des cases adjacentes.
Alea inférieur à la différence d'altitude minimale entre 2 cases, car cela reste le critère le plus important, mais qui aurait un légère chance d'être plus élevé si la rivière continue en ligne droite plutôt que de tourner !
[^] # Re: Rivière en diagonale, et taille des rivière?
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E11 : génération procédurale de carte (partie 2). Évalué à 2.
Ça complique la chose en effet.
Mais quand tu insères ta case dans ta file, tu sais d'où tu viens, non ? donc tu peux utiliser une altitude absolue "ajustée" pour le tri à ce moment là.
Et si tu retombes sur la même case en venant d'ailleurs, rien ne t'empêche de l'insérer une seconde fois avec une autre altitude ajustée !
Ça te parait raisonnable ?
[^] # Re: Rivière en diagonale, et taille des rivière?
Posté par moi1392 . En réponse à la dépêche Je crée mon jeu vidéo E11 : génération procédurale de carte (partie 2). Évalué à 4.
Est ce que tu pondères la différence d'altitude avec la distance ? vu que tes tuiles sont carrées, on peut considérer qu'une case sur le coté est à une distance de 1 et qu'une case sur la diagonale à une distance de
[^] # Re: Et les algorithmes GOST ?
Posté par moi1392 . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 10.
Du coup suffit de chiffrer ses messages avec un algo nsa et de rechiffrer le résultat avec un algo kgb et on est tranquille \o/
[^] # Re: Week-end ?
Posté par moi1392 . En réponse au journal Week-end \o/. Évalué à 4.
Voila le vrai lien
[^] # Re: Logiciel plaçant son propre code source en mémoire
Posté par moi1392 . En réponse au journal Heartbleed : petit best of des journalistes. Évalué à 2.
Tout ce qui passe par la mémoire du processus !
Je ne connais pas assez l'architecture des serveurs web, mais est ce que, par exemple, apache, fait tounrer dans le même process, la compilation du php, leservicede page web et le protecole de communication, en particulier les algos de chiffrement ?
Tout ce qui est exécuté dans des processus séparés devrait à priori ne pas devoir être impacté, non ?
[^] # Re: Rollbacks
Posté par moi1392 . En réponse au journal APT : nouvelle version 1.0. Évalué à 3.
L'installation de ton paquet n'écrit pas forcément directement dans ton home, mais l'utilisation du logiciel installé y sauvegarde généralement ses préférences.
Et il arrive que le format change et devienne incompatible avec une ancienne version.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par moi1392 . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 1. Dernière modification le 05 avril 2014 à 12:21.
Je n'arrive pas avec du code imbitable généré par lex. J'arrive avec un fichier lex lisible qui est compilé pendant la phase de compilation.
"Bonjour, j'ai ré-écrit le gros pathé de code imbitable en une série de strcmp(), J'ai économisé 3 Kio de taille de binaire en x86, et en plus j'enlève 50 lignes de code"
Il n'aura rien ré-écrit du tout car ce "pathé de code imbitable" n'est pas écrit. Encore une fois, c'est un fichier lex simple, très lisible (pour peu que l'on conaisse la syntaxe, comme tout format de fichiers) et sincèrement très compliqué à battre, tant en terme de performance que de consomation mémoire (bon, peut-être pas en consomation, mais c'est pas la mort non plus)
Je n'ai rien inventé, les fichiers de configurations sont déjà là avec leur format, et quand j'ai à analyser cela, je crée un analiser lexical avec lex que je couble avec un petit switch. Tu as remarqué que dans mon post original, je prenais soin de mentionner que je ne couplais en aucun cas ça avec du yacc/bison.
Encore une fois, si j'ai 3 mots clés que je lis 2 fois chacuns, je ne le fais pas. Quand cela commence à gonfler, c'est le tas de if/else avec des comparaisons de chaines qui deviens du bloat.
Une fois encore, je n'écris pas de grammaire !! juste un automate à état finis généré par lex que je couple avec un switch en C
Après si c'est lex qui te donne des boutons, tu n'as qu'à l'écrire à la main ton automate, mais tu seras moins bon que lui et quand ce que tu auras à parser change, il faudra le réécrire, c'est pas terrible.