Reprise du message précédent :

tu testes les 2 puis un coup de moindres carrés pour comparer
 
normalement, c'est l'ordre du système physique sous-jacent qui te donne l'ordre du polynôme, et la tendance à l'infini.

 
et comment on fait un curve fit ?

ouais mais la distribution est pas geniale là, normalement c'est comme ça que je fais mais là ça rentre pas bien
 il me faudrait la vaseline des stats en fait

on a vapeur, grand envaselineur de stats. Sinon, des laborantins qui boivent moins, ça devrait réduire un peu la variance ....

ajustement de parametres, donc en general ça finit en regression lineaire ou en interpolation polynomiale

Et alors ça apporte quoi de mettre dans un magazine ce que tout le monde sait déjà , on va changer quoi, on va le ragoter au diner a sa femme, ses amis, ses collègues :" c'est honteux ", mais personne n'ira le gueuler dans une manif !

Donc bon c'est bien d' avertir pour la XXXieme fois l'opinion publique, mais ça sert à rien si il n'y pas de mouvement derrière.

Donc ce magazine finira aux toilettes, dans les salles d'attente des docteurs, ou aux apprentis plombiers pour cacher le carrelage quand ils souderont

Edit: je ne pourrai pas être fonctionnaire je ne passerai pas l'ecrit

Stiffler c'est toi ?

pace que c'est aussi bloqué

le 2

 
U link pdf nao plz kk thx.
 

Tu fais un algo. génétique, tu laisser tourner une nuit et il te trouvera une solution sans que tu comprennes pourquoi

C'est une bonne façon de faire, ça. Si tu merges N>2 branches d'un coup et qu'il y en a une qui casse tout, tu es obligé de tout recommencer et tu ne sais pas qui est le fautif.
Là, tu peux aisément vérifier chacun des merges, l'un après l'autre.
Le nombre d'étapes de commit intermédiaires, ce n'est pas un pb, il faut commiter souvent. Tu peux commiter 18 fois par jour, c'est pas un pb. Par contre, l'outil doit te permettre de ne visualiser que les étapes importantes. Clearcase est bien de ce coté-là (c'est une des rares choses que j'apprécie vraiment dans cet outil). On peut même décider qu'une branche est morte et qu'il n'est plus nécessaire de la visualiser, ce qui simplifie les arbres et leur lecture.

ah tiens en parlant de merger des branches, si quelqu'un a un algo simple pour regrouper 2 arbres en un seul en déclarant quels noeuds de chaque arbre sont en fait les mêmes éléments ça m'intéresse.

Pb intéressant. Si tu n'as pas de la littérature sur le sujet, tu peux p-ê commencer avec un algo bourrin. Les arbres sont rarement énormes.

Francisque, un autre verre !

Yup, Masklinn a bien expliqué l'affaire et maintenant je comprends l'intérêt.
(par contre, impossible de verrouiller une branche, ou la marquer ou quoi que ce soit dans synergy, en tout cas j'ai pas trouvé si ça existe )

Là ça peut être énorme à terme.
Je suis à la limite de décider que la solution intelligente c'est tout garder comme ça, et de stocker en plus les noeuds identiques...

Un algo un peu moins bourrin serait de parcourir l'un des arbres (le plus petit ?), et de créer un hashmap avec en clef un hash de l'identifiant du noeud, et en valeur sa position dans l'arbre en terme de parcours (pour un arbre binaire,  ce serait un truc du genre g-d-d-g-d-g).
Sinon, ta solution peut aussi être la bonne (celle de ne pas merger), si le stockage n'est pas un pb.

a chaque nœud il y a une signature calculée a partir de la valeur du nœud et de chacun de ses fils ( donc , a la louche c'est du o(n) avec n qui est le nombre de neoud total )

tu garde dans un hashmap/bdd  les différentes valeurs
ensuite tu compare, par exemple avec une requete SQL bien sale et tu regroupe les plus grands en premier

 
Oué, en fait je pense pouvoir me débrouiller relativement facilement avec un algo naïf - mais le problème ça va être les perfs - c'est que derrière tous mes noeuds sont dans une base de données, avec une structure de ce genre :
 

 
...et donc déjà récupérer les 2 arbres complets et les merger c'est lourd, alors faire les updates qui vont bien derrière, au-secours...

...et c'est sans parler de l'épineux problème de l'id_noeud qui est clé étrangère dans d'autres tables, ni de celui des autres données de la table pour lesquelles il faudra bien choisir lesquelles on conserve.

(...puis j'ai des cas rigolos où un noeud peut avoir 3 ou 4 fils - voire plus si affinités - via une autre table, mais bon on va pas trop compliquer le pb hein.)

Ah ouais. Déjà, faire une structure d'arbre avec des tables en base de données, bonjour le truc bien lent. Tu vas faire une sous-requête à chaque noeud. Peut-être que je me trompe (et dans ce cas, je veux bien les arguments), mais intuitivement, s'il y a un truc que je ne ferais pas dans une database, c'est bien une structure d'arbre.

euh, dépend du sgbd ça.

Ben avec SQL, tu fais comment ?

...et pour les opérations normales j'ai besoin pour un noeud que de ses parents et ses enfants - parce-qu'en fait c'est pas un arbre du tout mon histoire, peut y avoir plusieurs noeuds avant et plusieurs après.

par ex. avec oracle tu as connect by/start with, pour ça.

(je sens que je m'embarque dans un truc pas possible si je permets ça dans mon appli, en fait...on va garder pour plus tard.)

bonne résolution

Oué mais ça fait chier, ç'aurait été classieux comme feature.
'fin de toute manière c'est prévu pour mysql ce truc, déjà, alors on va éviter les conneries.

Je connaissais pas, mais n'empêche, je lis ceci:

http://www.adp-gmbh.ch/ora/sql/connect_by.html

Ca revient bien comme je le disais à faire une sous-requête à chaque noeud, donc c'est forcément lent.

Avec des nested set ça pootre : http://dev.mysql.com/tech-resource [...] -data.html

 
Bah comment tu veux que ça marche autrement?
C'est supporté par le sgbd directement, c'est donc un peu comme une procédure stockée générique pour ce genre de pb, quoi...bien plus rapide que si tu devais générer et exécuter les requêtes dans ton langage client.

 
1680 x 1050

u = fiasco

oué, alors ça c'est bien gentil quand t'as une structure d'arbre bien définie avec une racine unique, aussi, hein...

1920 x 1200  

Sans doute que c'est un peu plus rapide, mais pour de gros arbres ça restera à mon avis infiniment plus lent que si tu codes et gardes la structure d'arbre en Java (ou en C/C++, ou n'importe quel langage qui supporte proprement la récursivité) et que tu finis par une requête triviale by ID pour récupérer les données du noeud.
Ceci étant, j'ai assez peu d'expérience avec les BD.

Euh oui, sauf que mon problème ce serait par exemple que j'ai juste les ids de 2 noeuds qui sont les mêmes, et que je veux merger à-partir de là. Le connect by/start with te permet de récupérer tout ton arbre en une seule requête, au lieu de te faire chier à boucler toi-même pour tout récupérer...

rien ne t'empeche d'ajouter un signature a chaque noeud , ca t epermettra de reconnaitre facilement les identiques et les different.

apres, il va falloir que tu jongles avec els règles pour merger deux noeuds différents