moi1392 a écrit 734 commentaires

ça peut paraître tentant de raisonner comme cela, mais il faut aussi voir que le marché américain leur rapporte bien plus, et qu'un procès la bas contre une firme américaine est très très biaisé.
Il n'y a qu'à voir le véto d'obama sur la petite victoire judiciaire de samsung contre apple récemment.

En gros, si t'es pas américain et que tu fais des sous, faut payer la taxe d'importation et ce qu'ils appellent "justice" est un moyen comme un autre de ne pas avoir de comptes à rendre à l'OMC.

Après, sur la validité des brevets, c'est une autre question qui est indépendante du point cité ci dessus.

Et donc tu utilises 2 outils et 2 langages pour faire quelques choses de très proche, avec tous les problèmes imaginables à l'interface.

oui.
C'est pas comme si on ne faisait pas déjà ça depuis toujours. flex, bison, moc en sont des exemple parmi d'autres !

J'ai déjà donné des exemples : inclure un binaire sans outils externe, pas de générateur de code externe, mais un générateur en library.

Mais ça, ça n'est pas un problème que tu as, mais une solution que tu proposes.

Et puis, c'est même pire que ça. Je parle de lire un fichier pour générer des API, et tu me parles "générateur de code"

C'est quoi la différence ? une API c'est du code. il existe déjà des tas d'outils qui transforment des graphes uml en code (api seulement)

tu imagines la différence de difficulté entre une bonne propagation de constante et un compilateur ?

Je pense oui, mais ça ne me dit toujours pas pourquoi tu as besoin de ces choses de façon constante dans ton language !
c++ fait des algos, et il le fait très bien, il sait déjà gérer une certaine forme de propagation de constantes, il en gère un peu plus maintenant, si tu veux un meta langage qui fasse autre chose, utilise un autre langage et voila !

oulala… Tu inclus un fichier binaire (jpg) dans un programme avec #include ? Tu réussi à parser un fichier xmi uml ou DTD pour créer des class à la volé avec #include ?

si ce sont des datas binaires, il existe des tas de d'outils qui te permettent de les ajouter dans ton programme et de les retrouver avec.
Si tu veux créer des classes à la volée à la compilation, ce dont tu as besoin c'est un outil de génération de code, pourquoi voudrais-tu une fonctionnalité du langague qui permettre de lire ce fichier à la compilation ? Je pense que c'est un faux problème, ou alors, il me manque des informations.

Quand sa forme se rapproche plus du métier ou du besoin que le code source. C'est la raison d'être des DSL : s'éloigner du code pour s'approcher du problème à résoudre ; cela facilite la relecture, les vérifications, les règles génériques, l'automatisation, etc…

ça ne m'avance pas, quel est ton problème à résoudre ? Une solution sert à résoudre un problème, quand on cherche une solution pour résoudre sa solution, c'est qu'il y a quelque chose qui dans la solution de base, en général, c'est qu'elle n'est pas bonne.

is_power_of_2(1) renvoie true ;)

"It can call only other constexpr functions"

ça parait logique.

Cela veut dire pas de lib standard, pas de lecture de fichier, pas d'io, etc…

la lib standard peu évoluer en proposant des constexpr !
Pour la lecture de fichiers, je ne vois pas le souci, un fichier c'est dynamique, si ce que tu veux c'est sont contenu statique au moment de la compilation, il y à la directive #include pour cela.
Pour les io, je ne sais pas, mais ça me parait louche, c'est typiquement un truc dynamique, dans quel cas on voudrait avoir un résultat statique d'une lecture d'un io ?

Je viens de vérifier, et effectivement, il n'a pas les autorisations pour commiter ! Ouf !

À mes yeux, dès qu'on passe dans le domaine de l'approximation, on sort des mathématiques

en mathématiques, on approche les fonctions trigonométriques par des polynômes (on approche tout par des polynome d'ailleurs)

On pourrait même discuter de l'aspect mathématique de certaines approximations numériques (séries de Taylor, etc), qui consistent à prendre un résultat mathématique (une série infinie) et à le tronquer pour l'implémenter dans un algorithme.

C'est donc bien une approche mathématique, c'est son implémentation numérique qui en réduit la précision, et quand on veut faire une approximation pour une valeur numérique en particulier, il faut bien, de toute façon, stopper le calcul à un moment donné.

Mais là, l'exemple dont on parle, c'est l'exploitation d'une coïncidence numérique fortuite pour accélérer un calcul.

Pourquoi une coïncidence ? les constantes n'ont pas été choisies au hasard

C'est certainement ingénieux et utile, on peut même trouver ça génial, mais "beau"?

Je n'ai jamais prétendu que ce code était beau, je le trouve même très moche, d'un point de vu des noms de variables et des commentaires par exemple. Je ne laisserai jamais passer ça sous cette forme dans ma boite ! Mais j'accepterai sans problèmes l'astuce mathématique si elle à un sens à l'endroit ou elle est utilisée. C'est juste un problème de forme pour moi.

Il est probablement fonctionnel, mais il n'est pas fait pour être regardé, encore moins admiré.

Il n'est surtout pas fait pour être commité !
- des noms de variables à une lettre qui n'ont aucun sens.
- une constante dans une variable (threehalf), les autres directement dans le code ???
- des commentaires (en très petite quantité) qui n'ont strictement aucune utilité pour comprendre le code…

Le type qui me propose ça dans ma boite, je lui interdit le droit de commit à lui et sa famille sur 42 générations…

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 ?

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, …

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 :

int _3 = _3;

et ça, ça va être vraiment bizarre…

_ suivi d'un nombre peut aussi être un nom de variable.

int _3 = 3;

[…] 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…

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 là que la science rejoint la foi : on ne veut croire qu'à ce qu'on croit.

Cela porte un nom : http://fr.wikipedia.org/wiki/Biais_de_confirmation

et master/slave ça venait de l'informatique.

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)

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

ça permet d'insérer en O(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 !