forum Ancestrologie
Ancestrologie - Développement => Développement => Discussion démarrée par: DDdeBerdeux le 11 Décembre 2005 à 18:09:40
-
C'est bientôt Noël, alors je vous ai fait un petit cadeau, le passage de la base en version b4.009. Evidemment, pas de confusion, il ne s'agit encore que d'une version en test. Donc prenez bien les précautions d'usage en particulier pour sauvegarder vos données avant d'exécuter le fichier maj_b357_b4009.exe. Et si çà marche correctement, j'espère que celà contribuera à une prochaine version, officialisée par Philippe CM.
L'exécutable de mise à jour est à télécharger maj_b357_b4009.exe (http://andre.langlet.free.fr/ancestro/maj_b357_b4009.exe)
Le fichier FAMILLEVIDE4009.zip (http://andre.langlet.free.fr/ancestro/FAMILLEVIDE4009.zip) contient la base vide et le fichier modificationsBDD.txt expliquant toutes les modifications effectuées depuis la version b3.57.
Pour éviter les confusions, je souhaiterai que les liens vers les fichiers téléchargeables restent sur ce forum, afin que les personnes qui téléchargent ne puissent pas le faire sans avoir la possibilité de lire ces avertissements.
Les modifications effectuées depuis la b4.004 téléchargeable sur le site ancestrologie.org sont les suivantes:
Modifications PROC_INCOHERENCES pour ajouter les controles évènements individuels absents dans T_ASSOCIATIONS, et des évènements familiaux sans union, unions avec conjoint à 0 ou null.
Ajout à la table REF_RELA_TEMOINS de 2 colonnes pour mémoriser les tag-témoins anciens et nouveaux, et d'une procédure PROC_REF_TEMOINS(A ou N) pour choisir les tag-témoins à utiliser avant et après l'importation d'un gedcom
Modification de la table de référence des évènements pour remplacer TITR non gedcom et non récupéré par ancestrologie, par TITL. Mise à jour de la table EVENEMENTS_IND en conséquence.
Ajout dans la procédure de mise à jour des fichiers REF_EVENEMENTS2.txt, REF_DEPARTEMENTS2.txt et REF_RELA_TEMOINS2.txt mis à jour suite aux modifications sur les tables de références. Noms avec indice 2 pour ne pas écraser des tables de références éventuellement modifiées par les utilisateurs.
Pour correction des statistiques sur le dossier ("Informations") modification des procédures PROC_COMPTAGE et PROC_COMPTE_VILLES.
Correction de PROC_ETAT_AGE_PREM_UNION_BASE et des états age_premiere_union.rtm et age_premiere_union_orange.rtm pour le fonctionnement de ces états.
Corrections pour présentation (étiquettes de colonnes se chevauchant) des états de dénombrement de descendance.
Modifications pour introduire les calculs de consanguinité et de parenté
Création d'une table temporaire TQ_CONSANG,
Création d'une procédure récursive PROC_CONSANG de calcul de la parenté entre 2 individus ou de consanguinité d'un individu selon le mode utilisé, selon la formule de Malecot,
Modifications de PROC_ETAT_DENOMB_ASCEND et des états de dénombrement d'ascendance pour faire apparaître la consanguinité
Création d'une procédure PROC_PARENTE utilisable depuis le BOA pour calculer la parenté entre 2 individus.
Le petit cadeau de Noël c'est le calcul du coefficient de consanguinité d'un individu et le calcul du coefficient de parenté entre deux individus (enfin, si je ne me suis pas planté dans les calculs et je compte sur vous pour me le dire).
Ce calcul fait suite à un petit défi de Lya qui m'a donné un lien vers le site http://baudetdupoitou.online.fr/annexes/annexe2.htm expliquant la formule de Malécot. Si la formule est bonne pour des ânes, elle doit l'être aussi pour nous :lol:
Le coefficient de consanguinité est affiché sur l'état de dénombrement d'ascendance au niveau de la génération 1 en dernière colonne à droite.
Pour obtenir le coefficient de parenté entre 2 individus il faut exécuter la requête SELECT * FROM PROC_PARENTE( CLE_INDIVIDU1 , CLE_INDIVIDU2 )dans le BOA (ou un autre requêteur) en attendant qu'un jour Philippe CM nous fasse une interface plus conviviale depuis le menu Individu par exemple (c'est une suggestion).
Un point IMPORTANT à noter par les testeurs: les modifications pour corriger les statistiques de villes par pays du dossier atteintes depuis le petit bouton "Détail" de la fenêtre "Mes généalogies" / "Informations", ont mis en évidence une anomalie de verrouillage de table temporaire, que Philippe a bien identifiée et corrigée pour la prochaine version du logiciel (v394 ou plus). En attendant qu'il la mette en ligne, si vous avez touché à ce petit bouton "Détail", il est préférable de quitter Ancestrologie avant d'y revenir. Sans celà vous ne pourriez pas revoir les "Informations" et il y a peut-être d'autres fonctions que j'ignore qui ne fonctionneront pas.
Autre point à retenir: avant de s'exécuter la procédure de mise à jour présente des messages, qu'il est important de lire au moins une fois. Au cours de son exécution, un "jounal" modifbase.log est enregistré dans le répertoire d'ancestrologie. Il y figure des renseignements divers sur la mise jour et son déroulement. Les messages d'erreurs du type "trigger ou procédure existe déjà", "table non trouvée" ...(en anglais malheureusement) ne sont pas graves et sont souvent provoqués parce que la base a déjà été mise à jour au moins partiellement. Il n'y a pas d'inconvénient, bien que celà soit inutile, à exécuter plusieurs fois la mise à jour sur la même base.
Si vous avez plusieurs bases, il est nécessaire d'appliquer la procédure de mise à jour pour chacune d'elles.
Si certains ont personnalisés des états modifiés au cours de cette procédure (voir ci-dessus, mais çà m'étonnerait vu qu'ils ne fonctionnaient pas ou mal), il est préférable qu'ils en sauvegardent les fichiers ou les renomment, pour éviter qu'ils soient écrasés.
Le fichier famillevide.bdd est surtout destiné à ceux qui préfèrent utiliser une base par généalogie plutôt que des dossiers, pour des raison de sécurité et de rapidité. J'en suis. Il ne contient que les tables de références, et est ainsi prêt à recevoir votre premier dossier.
S'il y a diverses questions qui se posent sur cette version, il est préférable de ne pas les dispercer, et de toutes les mettres sur ce fil.
J'essayerai de mettre dans ce message les principales réponses comme celle-ci expliquant les raisons possibles de messages d'erreurs pendant l'exécution de la procédure de mise à jour, et leurs remèdes:
maj_b357_b4009.exe est un fichier exécutable qui est à télécharger en cliquant sur le lien du message, sur le bureau de windows par exemple. Ensuite en double cliquant sur le fichier téléchargé, il s'exécute et met à jour la base en cours dans Ancestrologie (que l'on aura pris soin de quitter auparavant, FireBird embedded mono-utilisateur oblige).
Pendant la mise à jour on peut voir apparaitre une fenêtre en ligne de commande. Certains peuvent y voir apparaître un message d'erreur signalant l'absence du fichier gds32.dll. Ce message est normal et sans conséquence pour ceux qui utilisent FireBird v1.5x en version serveur. C'est parce que l'exécutable de mise à jour a besoin de fbclient.dll. Donc pour ceux qui utilise FB embedded, le gds32.dll qui se trouve dans le répertoire d'Ancestrologie est renommé provisoirement fbclient.dll. S'il ne le trouve pas, le message d'erreur est émis dans la fenêtre en mode commande, mais c'est normalement sans conséquence, puisque l'absence de ce gds32 signifie que c'est alors une version serveur qui est utilisée. FB serveur en v1.5x place fbclient.dll et gds32.dll dans le répertoire system32 situé dans le path, donc la procédure de maj le trouvera toute seule.
Le seul problème peut-être pour ceux qui utiliseraient encore la première version serveur de FB v1.0 ou Interbase serveur. Ces versions n'installaient que gds32.dll dans system32. Le remède: faire une copie de gds32.dll dans le même répertoire et la renommer fbclient.dll. Ou supprimer ce serveur et le remplacer par FB v1.53 librement téléchargeable sur internet, comme là http://www.ancestrologie.org/forum/index.php?topic=4776.0&postdays=0&postorder=asc&start=4
Bon Noël :wink:
André
Mise à jour des fichiers le 12/12/2005 à 22h00. Description des modifications http://www.ancestrologie.org/forum/index.php?topic=5123.0&postdays=0&postorder=asc&start=16
Télécharger et exécuter la nouvelle version du fichier maj_b357_b4009.exe pour mettre à jour la base.
-
Installation réussie
Je ne sais si cela se revele depuis cette version mais le tri n'a plus l'air de fonctionner de façon automatique :oops:
-
Ne pas tenir compte de mon message précédent, cela fonctionne a condition de se conformer a la saisie des dates :wink:
-
Je n'ai pas eu de problèmes d'installation.
J'ai apprécié l'amélioration des informations et des statistiques.
Seule remarque:
Pour un dossier mon sosa a des implexes et sa consanguinité n'est pas nulle (OK)
Pour un autre dossier le sosa a un implexe de 0,51 % à la dixième génération et une consanguinité nulle (je m'attendais à une consanguinité non nulle mais c'est peut-être dû à un arrondi si elle est inférieure à 0,0099 ?)
Cela dit Merci André pour ton travail. Salutations normandes à un autre armoricain
-
Pour un dossier mon sosa a des implexes et sa consanguinité n'est pas nulle (OK)
Pour un autre dossier le sosa a un implexe de 0,51 % à la dixième génération et une consanguinité nulle (je m'attendais à une consanguinité non nulle mais c'est peut-être dû à un arrondi si elle est inférieure à 0,0099 ?)
La grosse différence entre un calcul d'implexe et un calcul de consanguinité, c'est que ce dernier donne une importance plus grande aux ancêtres communs proches, qu'aux lointains, ce qui semble logique. Dans les essais que je peux faire sur ma généalogie, s'il n'y a pas d'implexe dans les 5 premières générations, la consanguinité doit être si faible (<0,00005 dans l'absolu) que c'est 0 qui s'affiche.
Mais j'avoue que je n'ai pas le courage de refaire les calculs à la main pour vérifier. Alors s'il y a des fanatiques de l'arithmétique qui ont ce courage...
Ou bien comparer avec le résultat que donnent certains sites. On m'a dit que généanet faisait ce calcul. Encore faut-il avoir mis sa généalogie sur généanet pour comparer avec ce que donne Ancestro! Et j'ignore la méthode utilisée par généanet. Je me méfie toujours, on trouve tellement de bêtises sur internet! Je ne sais plus si je l'ai dit ici, mais j'ai même vu certain trouver un nombre d'ancêtres théorique impair!
A+
André
-
Je ne sais plus si je l'ai dit ici, mais j'ai même vu certain trouver un nombre d'ancêtres théorique impair!
Oui tu l'avais déjà dit :roll:
Je suis d'accord avec ton commentaire et ton travail me satisfait entierement
-
Oui tu l'avais déjà dit :roll:
Je dois commencer à radoter :oops:
Bonne nuit
André
-
Beau travail, André, tu peux te reposer un peu sur tes lauriers, en attendant les fêtes. Dans le dénombrement ascendance, je vois l'ensemble de mes générations alors que précedemment je n'en voyait que trente. Juste une suggestion, que j'avais placé sur le forum du même nom. Serait-il possible d'utiliser l'état dénombrement d'ascendance sans qu'il se référe systématiquement à l'individu de la fiche, à l'instar d'autres états, avoir une boîte de dialogue avec affichage du répertoire, ou autre.
Je m'aperçois, que je te dis, que tu peux te reposer, et à la du message je t'incite à réfléchir. :lol:
A+
-
Bonjour André,
Les résultats du test sont les suivants:
-Configuration XP Home sp2
-Ancestrologie départ: v391 b4.005
-Base de 9000 individus env. répartis sur 15 dossiers dont un de 6000 individus env.
-Ancestrlogie arrivée: v391 b4.009
La màj de la base s'est déroulée sans problème.
Constats:
1. Mes Généalogies/Informations: Les infos géographiques semblent être crédibles.
2. L'activation du bouton détail est bien bloquant. Retour à une situation normale avec le redémarrage d'Ancestrologie.
3.Documents/Statistiques/Patronymes: RAS
4.Documents/Statistiques/Prénoms: RAS, seul le premier prénom a la première lettre en majuscule, ce n'est pas génant pour moi et c'était déjà ainsi avec l'ancienne structure de base.
5.Documents/Statistiques/Age à la première union: La tableau est maintenant renseigné avec pour les hommes et les femmes (nombre et age moyen). Dans la version initiale seule la colonne Hommes (nombre) était renseigné. L'affichage des informations commence en 1900, il y a cependant de nombreuses unions renseignées avant cette date.
6.Documents/Statistique/Longévité: RAS,
7.Documents/Statistiques/Nombre d'enfants par union: RAS,
8.Documents/Statistiques/Recensement: RAS,
9.Documents/Statistiques/Dénombrement ascendance: La colonne consanguinité apparaît bien. Avec les données de ma base: implexe 0 et consanguinité 0, ce qui semble être correct.
10.Documents/Statistiques/Dénombrement descendance: RAS,
11.Documents/Statistiques/Graphique par Pays ou Départements: Il n'y a plus la litanies de tous les départements et les naissances ou décès par département ou pays semblent être crédibles. Dans mon cas, le département du Nord apparaît deux fois avec le même nombre aussi bien pour les naissances que pour les décès par département, c'est nouveau par rapport à la structure de base initiale. Près de 3000 naissances et 1400 décès pour le Nord où se tient l'essentiel de ma généalogie (le gros dossier). Les listes des naissances et décès par départements comportent une première ligne sans indication de département mais avec un nombre, même chose pour la dernière ligne. Les listes par pays ont aussi une dernière ligne sans nom de pays. Enfin et ce n'est pas grave, ces listes par départements gagneraient à être établies par pays puis départements. Ce n'est pas une demande.
En conclusion, vu d'ici seuls les points 5 et 11 méritent une explication et éventuellement une retouche sauf si l'anomalie provient de mes données.
Depuis le passage de b3.57 à b4.00x j'ai remarqué qu'il fallait un peu plus de temps pour un changement de fiche et notamment à l'occasion du retour répertoire vers fiche.
Merci André pour ce bon travail.
-
J'approuve ta suggestion. J'y ai ajouté un petit commentaire pour la généraliser, avec un petit bémol pour rappeler la priorité aux corrections de bugs.
Je viens de faire un petit test pour vérifier que le calcul de parenté n'était pas totalement faux, par la requête SELECT * FROM PROC_PARENTE(14,307). J'ai obtenu un coefficient de parenté de 0,287 ce qui est normal puisque 14 et 307 son frére et soeur (parenté 0,25) et qu'en plus leurs parents doivent être cousins.
A+
André
-
Chez moi en ce qui concerne le bouton detail du point 2 ne bloque pas ancestrologie :wink:
-
Bonjour,
Le passage par Mes Généalogies/Informations permet de lire le ....informations. L'activation du bouton détail fait apparaître un graphique.
Après la fermeture de cette fenêtre puis de la fenêtre informations il n'est plus possible de relire les informations sans avoir redémarré Ancestrologie.
-
Re Bonjour,
Ma précédente réponse était pour Roger, mais le message de Christian est venu s'immiscer entre les deux.
Merci pour tes essais.
Pour le point 5, j'ai trouvé la raison du problème. Je ne faisais la sélection que sur le dossier 1, et je ne m'en suis pas aperçu en testant parce que je n'utilise qu'un dossier par base. Je corrige çà, ensuite je vais modifier le fichier de mise à jour en mettant un petit PS: en bas de mon premier message. Quand ce sera fait il suffira de réexécuter le fichier de maj.
Pour le point 11, je pensais le problème règlé pour le département du Nord. L'origine de ce pb, c'est que dans la table de référence REF_DEPARTEMENTS "Nord" apparaît 2 fois, la 2ième étant pour le département du Nord de la Nouvelle Calédonie. Lors de la procédure de mise à jour je passe donc la requêteUPDATE REF_DEPARTEMENTS SET RDP_LIBELLE = 'Nouvelle Calédonie du Nord' WHERE RDP_CODE = 9881;
UPDATE REF_DEPARTEMENTS SET RDP_LIBELLE = 'Nouvelle Calédonie du Sud' WHERE RDP_CODE = 9882;pour corriger çà. Est-ce que par hasard tu n'aurais pas une table différente où les RDP_CODE ne seraient pas les mêmes? Essaies de visualiser le contenu de la table avec la requêteSELECT * FROM REF_DEPARTEMENTS where RDP_LIBELLE='Nord'dans le BOA, pour voir si tu as encore 2 départements du Nord. Et si tu y trouves le 9881, repasse la première requête. Cà voudrait dire que cette première requête ne s'est pas exécuter lors de la maj.
Pour les lignes sans nom, il y a 2 cas: si le pays est laissé sur NULL, il apparaît une ligne en fin de liste
si le pays est un caractère espace ou une chaîne vide, il paraît en fin.
J'attend ta conclusion sur le pb de département pour passer un correctif.
Merci et bon appétit
André
-
Re bonjour,
La requète de recherche de libellé retourne effectivement:
1;59;Nord;31;1;59 et
2;9881;Nord;988;98000
La mise en oeuvre via BOA de la première requète destinée à revenir à "Nouvelle Calédonie du Nord" retourne l'erreur:
Violation d'accès à l'adresse 0D66B088 dans le module 'DLL_BOA.dll'. Ecriture de l'adresse 00000000. J'ai quitté BOA en validant les modifications.
Dans Documents/Graphiques...... j'ai bien perdu le Nord...... de la Nouvelle Calédonie. Il n'y a plus qu'un seul Nord.
La table REF_DEPARTEMENTS est toujours avec la ligne 9881;Nord;988;98000.
Pour info, je travaillais effectivement sur le dossier n°2, j'utilise BOA v1.7
Merci pour cette intervention rapide.
-
Philippe CM vient de mettre en ligne une version v395 du logiciel.
Elle corrige:
Le blocage de la table provisoire qui touchait l'affichage des informations du pays dont je vous parlais précédemment.
Un message "MP_TABLE doit avoir une valeur" qui apparaissait dans la fenêtre "La Médiathèque" (menu configuration / bibliothèque multimédia) quand on double cliquait sur une image réduite.
Et surtout, le problème des témoins qui ne s'affichaient pas ou plutot qui étaient enregistrés avec un mauvais code_fiche.
Pour Christian, je suppose que c'est dans la table de référence en mode texte REF_DEPARTEMENTS.txt dans le répertoire \tables de references que tu as trouvé la ligne 9881;Nord;988;98000? Par contre tu devrais trouver dans le même répertoire un fichier REF_DEPARTEMENTS2.txt où cette ligne est corrigée. Je n'ai pas donné exactement les mêmes noms aux fichiers de référence que je modifie (comme pour les évènements et les témoins), parce que certains utilisateurs ont "personnalisés" ces fichiers. Si çà n'est pas ton cas, tu peux supprimer l'ancien et enlever le 2 du nom du nouveau. Si non, il faut corriger manuellement l'ancien fichier .txt, en suivant bien le modèle donné dans le nouveau (mais il n'y a que le fichier des témoins qui a 2 colonnes de plus). Mais ces fichiers ne sont utilisés que pour recharger les tables de référence.
Je regarde quand même pourquoi la table REF_DEPARTEMENTS n'a pas été mise à jour chez toi.
A+
André
-
André,
Affirmatif, la ligne 9881;Nord;988;98000 provient bien du fichier texte REF_DEPARTEMENTS.
Je ne l'avais pas cité, mais lors de la mise à jour de la base il y a bien eu création des trois fichiers indexés 2 dans le répertoire des tables de références.
Pour ta gouverne mais c'est avec moins de conséquence pour moi, la ligne 9882 n'a pas été rebaptisé Nouvelle Calédonie du Sud dans le fichier REF_DEPARTEMENTS non indexé.
En tous cas, tout à l'heure, le repassage de la requète pour modifier le libellé 'Nord' a bien été suivi d'effet au niveau de la base et l'affichage de la liste des lieux fait bien apparaître Nouvelle Calédonie du Nord et Nouvelle Calédonie du Sud.
-
Bonsoir,
Cà y est j'ai modifié les fichiers maj_b357_b4009.exe et FAMILLEVIDE4009.zip en ligne (je ne fais pas de changement de version pendant cette phase de test), pour tenir compte de vos remarques jusqu'à présent.
Correction de l'erreur de dossier dans la procédure PROC_ETAT_AGE_PREMIERE_UNION utilisée par l'état des âge à la première union.
Correction des procédures PROC_COMPTAGE et PROC_COMPTE_VILLES pour ignorer les différences d'écriture en majuscules/minuscules, espaces avant ou après les noms, chaîne vide ou NULL dans les statistiques du dossier affichées dans la fenêtre "informations" et détail.
Corrections identiques pour la procédure PROC_STATISTIQUES, sauf la distinction chaîne vide ou NULL impossible à mettre en oeuvre simplement. Regroupement des départements par pays. Cette procédure est utilisée par les états statistiques par pays et départements, ainsi que par le module statistiques complémentaires. A noter que les modifications de cette procédure induisent une très nette augmentation de son temps d'exécution.
A+
André
PS: re modif à 22h00 de PROC_STATISTIQUES trop lent: uniquement tri primaire par pays conservé.
-
A noter que les modifications de cette procédure induisent une très nette augmentation de son temps d'exécution.
Au point qu'on se demande si tout se passe bien :!:
Petit problème en ce qui me concerne :
Pour les Naissances par dépt, la fenêtre affiche 10 lignes de 4 colonnes soit 40 départements
Pour les décès par dépt, la fenêtre affiche 10 lignes de 5 colonnes.
Mes ancêtres ayant beaucoup migré dans les départements français et les provinces belges, je n'ai pas mon compte
La manche (50) est en 40ème position, c'est dire que je n'ai pas beaucoup de trous dans la liste.
-
Bonsoir,
A noter que les modifications de cette procédure induisent une très nette augmentation de son temps d'exécution.
Au point qu'on se demande si tout se passe bien :!:
Au point que je me demande si je ne vais pas revenir en arrière sur ce point. Les dernières modifications étaient surtout pour éviter de déclarer un autre département si par hasard il avait été mal saisi, espaces devant ou derrière, majuscule ou minuscule différents de la table de réference. Je vois que çà coûte trop de temps. Et normalement çà devrait être saisi avec la table de réference.
Votre avis?
Pour le reste, tu parles bien des états? pas du module complémentaire?
Parce que je n'ai pas modifié l'état. Chez moi le fichier Stat_Graph_naiss_dept.rtm date du 25/08/2001 et n'a que 2 colonnes: le nom du département (ou du pays) et le nombre d'évènements. Il n'aurait pas été modifié chez toi?
A+
André
-
Je pense aussi qu'il faur alléger les contrôles à ce niveau pour ganer en temps de réponse.
Comme tu le dis, en principe, personne ne saisit manuellement le département si on utilise correctement la table des villes. Il ne doit donc y avoir qu'exceptionnellement des fautes de frappe, et les moyens manuels de contrôle doivent suffir (lecture des listes rapports etc...)
Pour le reste, tu parles bien des états? pas du module complémentaire?
Je parle effectivement du module complémentaire qui affiche maintenant des choses sensées alors qu'avant, tout le Hainaut (Belgique) se retrouvait comptabilisé dans le Calvados.
çà restera donc à améliorer.
Je vais regarder maintenant ce que donnent les implexes et cousinages
-
Je suis revenu en arrière sur ces contrôles dans la PROC_STATISTIQUES, en laissant le tri primaire par pays dans l'état par département. Donc tu gardes bien le Hainault en Belgique. :wink: La différence de temps est énorme.
Les fichiers en ligne ont été modifiés.
A+
André
-
Bonsoir André,
J'y perds mon flamand, il faudrait préciser l'époque à laquelle nous sommes. Beaucoup de mes ancêtres originaires ou proches de Lille ont obtenu une dispense de l'Evéque de Tournai pour publication d'un seul ban de mariage au lieu de trois!!!!!!
Pour ne pas trop choquer certain, il s'agit d'une plaisanterie.
André, souhaites-tu un test de ta dernière mouture de migration de base à partir de V368 b3.57? Le but étant de revérifier l'ensemble de la migration à partir d'une version antérieure.
De mon coté j'ai appliqué les dernières versions les unes après (ou sur) les autres et les résultats anticipés sont là.
-
Je suis revenu en arrière sur ces contrôles
Le résultat est éloquant, affichage quasi instantané au lieu d'environ 20s d'attente (j'avais chronométré).
A mon avis, laisse comme çà.
Qui va augmenter l'affichage à plus de 40 départements dans ce module (payant !)
Pour le calcul de cousinage, je trouve bien les mêmes résultats qu'avec ta requête, mais tu ne calcules qu'en %
Il est plus fréquent de donner le cousinage en générations selon le droit civil (cousins germains = 3). Là aussi on trouve de tout sur le net.
Je n'arrive pas à suivre ton calcul pour les anes, c'est peut-être moi qui porte le bonnet. Il ne correspond pas aux calculs que j'utilisais. Mais je ne doute pas de la justesse de tes chiffres dans l'application de la formule.
-
Pour Christian, si tu veux continuer à tester la récupération c'est ok. Je maîtrise assez bien les maj, mais on ne sait jamais. Ce qui m'intéresserai le plus maintenant de vérifier c'est le calcul, et çà je crois bien qu'il faut que ce soit fait par les pros de la généalogie.
Pour le module stat complémentaires, c'est uniquement la programmation du module, et çà je n'y peux rien.
Horemans, sous quel format voudrais-tu voir les résultats du calcul de cousinage? Pour des cousins germains, si je suis la formule de Malécot, çà devrait donner 1/16 soit 6,67% c'est bien çà?
(1/2)^5 + (1/2)^5 = (1/2)^4 = 1/16
La méthode que tu utilisais donnait-elle le même résultat?
Je n'ai pas d'exemple dans ma généalogie pour tester ce calcul.
La présentation 1/X est possible, mais sur un seul niveau. Comment représenter si on multiplie par le (1+ Fa) de la formule où Fa est la consanguinité de l'ancêtre commun? Dur le calcul symbolique en informatique...
Y a-t-il une méthode logique pour donner le cousinage en génération?
Petite question: serait-il intéressant d'inclure un champ "consanguinité" dans la fiche de l'individu?
Mais avant celà, il faut valider le calcul, et trouver une méthode plus rapide si on veut l'appliquer à tout un dossier. Pour un seul individu, c'est à peine perceptible, mais tout à l'heure j'ai fait un essai sur toute ma base de 2300 individus. Le calcul a duré plus d'1/4h processeur à 100% avec un atlon64 3500+ et 1Go de RAM. Mais il doit être possible de trouver beaucoup mieux.
Bonne nuit
André
-
je ne peux déjà pas faire la mise à jour en 4.004, alors cela risque d'être pareil pour la 4.009 ! :cry:
lors de la mise à jour, j'obtiens le message d'erreur :
Composant introuvable
Cette application n'a pas pu démarrer car fbclient.dll est introuvable. La réinstallation de cette application peut corriger ce problème.
-
lors de la mise à jour, j'obtiens le message d'erreur :
Composant introuvable
Cette application n'a pas pu démarrer car fbclient.dll est introuvable. La réinstallation de cette application peut corriger ce problème.
Bonsoir,
Pourrais-tu dire comment est installé Firebird ou Interbase et Ancestrologie sur ton PC?
A+
André
-
Le système est sur le disque C:
Ancestrologie est sur le disque D: dans Program Files
Firebird (version serveur il me semble, je ne sais plus ce que j'ai installe ! :oops: ) est sur le disque D: dans Program Files
-
Si tu utilises la version FB embedded livrée avec Ancestro, tu dois avoir un fichier gds32.dll dans le répertoire D:\program files\ancestrologie (je suppose qu'ancestro est aussi sur D:)
Si tu utilises FB serveur 1.5 tu dois avoir dans c:\windows\system32, un fichier fbclient.dll et si lors de l'installation tu as coché la case de compatibilité avec les anciennes versions, gds32.dll. Ancestrologie ayant été conçu avec Interbase utilise gds32.dll.
Si tu utilises Interbase ou FB serveur 1.0, tu n'as que gds32.dll dans system32.
A+
André
-
j'ai effectivement firebird 1.5 mais dans le dossier c:\windows\system32 je n'ai pas de FBCLIENT.DLL. J'ai bien par contre le GDS32.DLL.
Que dois-je faire ?
-
Bonsoir André
Je me mêle peut-être de ce qui ne me regarde pas, mais il me semble que lors de ton message, dans lequel tu expliquais comment passer de Firebird embedded à fb serveur et comment utiliser IBOconsole Ransac après quelques hésitations c'était résolu à franchir le pas,et avec succès pour autant qu'il me souvienne.
A+
roger
-
c'est bien ça, mais je n'ai toujours pas pris de cours de SQL et c'est à peine si je sais ce qu'est une base de données, alors les IBconsole et les IBeasy j'ai pas encore franchi le pas ! :oops:
-
alors les IBconsole et les IBeasy j'ai pas encore franchi le pas ! :oops:
et en plus ya aussi ibexpert :wink: :) :lol: :D
-
j'ai effectivement firebird 1.5 mais dans le dossier c:\windows\system32 je n'ai pas de FBCLIENT.DLL. J'ai bien par contre le GDS32.DLL.Que dois-je faire ?
Cà m'étonne, parce qu'il me semble bien que c'est l'installation de gds32 qui est optionnelle. Essaye de faire une copie de ton gds32.dll dans le même répertoire system32 et renomme la fbclient.dll.
A+
André
-
Bonsoir à tous, bonsoir André,
Je reviens sur le test de la migration de la base et l'utilisation d'Ancestrologie v402.
Configuration: Windows XP home sp2
Situation initiale: la précedente v391 b4.009 issue du passage de v3.91 b4005 à v391 b4.009 par lutilisation de l'outil de migration (le premier) b3.57_b4.009.
Situation intermédiaire: retour à v368 b3.57
Situation finale: v402 b4.009 en deux temps (la base puis Ancestrlogie)
Les modifications sont faites Ancestrologie stoppé.
-1-La situation intermédiaire est optenue par la recopie d'une base du type b3.57, remplacement d'Ancestrologie 391 par Ancestrologie 368 (mise à jour + Clé), suppression dans le répertoire des tables de références des trois fichiers indexés 2.
Redémarrage d'Ancestrologie sans problème ni erreur.
Les départements de Nouvelle Calédonie du Nord et du Sud ont respectivement les libellés Nord et Sud.
-2-Passage en b4.009. Il est réalisé à l'aide de l'outil de migration (le dernier modifié) dont la copie a été placée dans le répertoire Ancestrologie. La modification s'effectue sans difficulté.
Le bouton Détail dans Mes Généalogies/Informations n'est plus bloquant.
L'affichage de l'age à la première union dans Documents/Statistiques se fait correctement. La Nouvelle Calédonie Nord et Sud est restée Nord et Sud avec une anomalie dans l'affichage des naissances ou décès par départements. Le Nord apparaît deux fois.
Mise en oeuvre de la requète pour refaire la modification avec BOA (v1.7). L'utilisation simultanée des deux requètes est inefficace. La mise en oeuvre successivement d'une requète puis de l'autre est opérationnelle.
Le document dénombrement ascendant est bien modifié avec le calcul de la consanguinité.
-3-Passage en v402: Utilisation de Ancestrologie màj 402 + Clé.
Lancement d'Ancestrologie sans problème ni erreur.
Passage de fiche (avec ou sans naissance) à répertoire et inversement sans pb ni erreur.
L'affichage des Documents/Statistiques se fait convenablement.
Je n'ai pas le fichier adéquat pour faire le contrôle des implexes et de consanguinité.
A l'instant je n'ai pas tout testé, il est un peu tard, mais dans l'immédiat les fonctions sont au rendez-vous. Seule la conversion sur la Nouvelle Calédonie reste un problème qui trouve une solution avec le BOA. Ce serait mieux de pouvoir y échapper.
La partie Astrologie est contrôlable à partir de Configuration/Préférences Générales.
-
Bonjour à tous, bonjour André,
Pour essayer de faire un contrôle j'ai construit une petite généalogie d'une bonne trentaine de personnes avec des liaisons destinées à faire apparaître des pourcentages d'implexes autres que zéro.
Apparemment les résultats sont conformes à la règle de calcul décrite dans un de tes messages.
L'édition papier, comme l'écran, n'indique pas le point de départ de l'ascendance ou de la descendance. Il me semble que c'est un manque, une fois imprimée la liste perd de son intérêt si cette indication est absente.
-
Un bon moyen de tester est d'importer le gedcom des rois de France qui est dans le sous-répertoire ImportExport d'Ancestrologie, dans la base vide. Là il y en a des implexes :shock:
Il y a un blocage dont je n'arrive pas à trouver pas la cause lorsqu'on calcule la consanguinité de Jeanne de Bourbon. Pourriez-vous me confirmer ce blocage également? Obligation de sortir par le gestionnaire de tâches et même d'arrêter Firebird. Il se peut même qu'après un tel blocage, la base soit inutilisable.
J'ai fait une recherche sur internet pour voir s'il existait d'autres méthodes que celle de Malécot pour calculer le coefficient de consanguinité, mais je n'en trouve pas de différente. Un site instructif: http://www.infobiogen.fr/services/chromcancer/IntroItems/ConsangFr.html
J'y ai découvert en particulier que la consanguinité n'était pas ce que je pensais. La consanguinité est égale à la parenté des parents. Donc on cherche uniquement des ancêtres communs aux 2 parents. Ce qui signifie que si l'un des parents est le fruit d'une longue lignée incestueuse, celà n'a aucune importance sur la consanguinité des enfants si l'autre parent n'a aucun ancêtre commun au premier. La consanguinité c'est la probabilité qu'ont 2 parents de transmettre le même gêne d'un ancêtre à leur progéniture. Celà n'a rien à voir avec un manque d'ancêtres dû à l'implexe.
Pas évident...
D'ailleur j'ai fait une version avec un coefficient (que j'appelle sans doûte à tort consanguinité) dans la-quelle je fais un calcul dans ce sens (qui est beaucoup plus facile et rapide). Je calcule pour chaque génération le rapport entre le nombre d'individus dont je suis sûr qu'ils ont "disparu" parce qu'ils sont en double ou triple dans la génération, et le nombre d'ancêtres théoriques de cette génération, ce qui fait qu'un enfant de cousins germains à un taux de 25% (il n'a que 6 ancêtres au lieu de 8 à la 3ième génération, donc il en manque 2/8. Ce calcul ne vous est-il pas plus parlant?
Pour l'imprimé, j'ai regardé, mais je ne sais pas comment modifier le titre (pas encore) :wink:
A+
André
:wink:
-
Ce calcul ne vous est-il pas plus parlant?
J'aime beaucoup mieux çà, on retrouve ce calcul dans d'autres logiciels et c'est plus parlant.
-
La consanguinité c'est la probabilité qu'ont 2 parents de transmettre le même gêne d'un ancêtre à leur progéniture. Celà n'a rien à voir avec un manque d'ancêtres dû à l'implexe.
quand il y a implexe, il y a consanguinité et inversement.
Je veux bien qu'il y ait une différence de formulation, mais dans les 2 cas, on comptabilise les ancêtres communs.
Le lien que je donnais vers le site de Beaucarnot dans un autre fil peut faire référence, c'est quand même un professionnel de la généalogie.
http://www.beaucarnot-genealogie.com/contenu/1-assistance-genealogique/1-3-vous-cherchez-une-information-un-acte-un-document/1-3-1-vous-cherchez-une-information-precise/1-3-1-5-bis-endogamie-et-implexe/
-
quand il y a implexe, il y a consanguinité et inversement.
Non justement, tu peux avoir implexe sans consanguinité. Lya m'a passé ce lien qui différencie bien les choses:
http://www.ciaq.com/Consanguinite_f.html
Et comme je l'ai dit plus haut dans l'exemple du parent fruit d'unions incestueuses (donc beaucoup d'implexes ou ancêtres communs), si l'autre parent n'a pas d'ancêtres communs avec le premier il n'y a pas consanguinité. Comme dit dans le lien ci-dessus," N'oubliez pas, la consanguinité n'est pas héréditaire!
* Deux sujets très consanguins mais qui n'ont pas de parenté en commun donneront une progéniture non consanguine et bénéficieront de la vigueur hybride.
* Deux sujets non consanguins avec de la parenté en commun auront une progéniture consanguine.
Troublant n'est-il pas :?
A+
André
-
:oops: Convaincu :oops:
Je vais avoir des choses à réviser.
-
Pour moi c'est pas de la révision, j'ai plutot fait de la technologie que de la biologie. :cry:
Au final, je me demande simplement si c'est la consanguinité "des généticiens" qui nous intéresse?
Et comment s'appele le ratio dont je vous ai parlé?
Encore une nouvelle définition de l'implexe :evil:
A+
André
-
Bonjour à tous, bonjour André,
J'ai fait la manip avec les Rois de France.
-1- Mise en place d'une base 4.009 vide dans Database,
-2- Faire pointer Ancestrologie v402 sur cette base,
-3- Import dans cette base du gedcom des Rois de France,
-4- Navigations diverses dans la généalogie,
-5- Faire apparaître Jeanne de Bourbon,
-6- Lancer Documents/Statistiques/Dénombrement ascendance.
J'ai attendu un peu, le PC a mouliné plein pot (UC à 100%) et par lassitude j'ai tout laissé en l'état. En gros UC à 100% pendant 45 minutes puis ensuite UC à 50-60% pendant 45 minutes, ensuite la machine s'est débrouillée toute seule.
Ce matin, après 7 ou 8 heures de fonctionnement, le process était pratiquement inactif mais toujours pas de document dans la fenêtre Ancestrologie.
J'ai pris la décision de stopper, l'arrêt s'est fait proprement. J'ai relancé Ancestrologie sur les Rois de France sans problème.
Toutefois: dimension de la BDD Rois de France 2.2 Go!!! et dimension du back up 6.8 Mo. En dépit de la taille très importante de BDD, le démarrage Ancestrologie reste normal.
Configuration: Windows XP Home sp2, P4, 2.5 GHz, RAM 512 Ko.
-
Bonjour,
7 à 8 heures, tu es vraiment très patient...
Avec une base de cette taille, tu auras plus vite fait de la supprimer que de l'optimiser.
Merci pour ces tests, mais arrêtez maintenant avec cette version.
J'ai trouvé la cause du bouclage (un individu dans plusieurs générations) et j'y ai remédié. Maintenant le calcul est bon. Je l'ai comparé avec quelques valeurs calculées par GeneWeb.
Je vais bientot mettre en ligne une b4.010, dans laquelle il y aura un champ dans la table INDIVIDU pour conserver et afficher la valeur de la consanguinité. Pour le moment avec la v402, ce champ interdit l'import gedcom, et Philippe CM à dans ses cartons une v403 qui arrange celà et affiche le champ.
En attendant, pour convaincre les incrédules :wink: , une définition de la consanguinité par Albert Jacquard, extrait que m'a communiqué Roger1Consanguinité et Parenté
Le génome d'un individu est constitué d'un grand nombre de gènes qui, si l'on ignore les mutations, se reproduisent de façon identique. Les gènes peuvent servir à mesurer l'identité d'une personne.
Les gènes sont disposés à des emplacements précis appelés "locus". Chaque individu possède pour chaque locus deux gènes, l'un transmis par sa mère, l'autre par son père,et transmet à ses enfants un copie de l'un de ses gènes.
La Consanguinité d'un individu x est la probabilité cg(x) de trouver à un locus donné deux gènes identiques.
La Parenté de deux individus x et y est la probabilité pr(x,y) de trouver à un même locus deux gènes identiques.
Calculs
Un calcul de probabilité montre que:
La consanguinité cg(x) est égale à la parenté pr(px,mx) des parents px et mx de x.
Si x..a..y est un lien de parenté minimal entre x et y (c'est-à-dire tel que les branches x..a et a..y n'ont que a comme personne commune), alors il contribue à la parenté de x et y d'un facteur:
1
---- (1 + cg a)
n+1
2
où n est la longueur (distance x..a + distance a..y) du lien de parenté x..a..y.
La parenté de x et y est la somme des contributions de tous leurs liens de parenté minimaux.
Références
Albert Jacquard. Structures Génétiques des Populations. Masson & Cie, 1970.
A+
André
-
Pour André.
J'ai un petit pb avec la base 4.009 et la dll arbres.
C'est dans ce post : http://www.ybruant.magic.fr/phpBB2a/viewtopic?&p=34963#34963
-
Bonjour,
7 à 8 heures, tu es vraiment très patient...
Je te rassure André ma patience a des limites. Le PC ne se pose pas les mêmes questions.
Philippe a mis en libre service Ancestrologie v4055 qui s'affiche v405. Est-ce que cette version reprend ce qui était en stand-by dans la 403?
-
Je crois qu'il y a un "5" en trop sur le site, mais que cette version crée le champ CONSANGUINITE dans la table INDIVIDU s'il n'existe pas, règlant en même temps le problème d'impossibilité d'importation d'un gedcom dû à ce champ supplémentaire.
Je vais crééer un autre fil avec la b4.010
Bonsoir
André