Sono lo sviluppatore di alcuni software per alberi genealogici (scritti in C ++ e Qt). Non ho avuto problemi fino a quando uno dei miei clienti non mi ha inviato una segnalazione di bug. Il problema è che il cliente ha due figli con la propria figlia e, di conseguenza, non può utilizzare il mio software a causa di errori.

Questi errori sono il risultato delle mie varie asserzioni e invarianti sull'elaborazione del grafico familiare (ad esempio, dopo aver camminato su un ciclo, il programma afferma che X non può essere sia padre che nonno di Y).

Come posso risolvere quegli errori senza rimuovere tutte le asserzioni sui dati?

Sembra che tu (e / o la tua azienda) abbiate un fraintendimento fondamentale di ciò che dovrebbe essere un albero genealogico.

Vorrei chiarire che lavoro anche per un'azienda che ha (come uno dei suoi prodotti) un albero genealogico nel suo portafoglio e abbiamo avuto problemi simili.

Il problema, nel nostro caso, e presumo anche il tuo caso, deriva dal formato GEDCOM che è estremamente supponente su ciò che dovrebbe essere una famiglia. Tuttavia, questo formato contiene alcune idee sbagliate su come appare realmente un albero genealogico.

GEDCOM ha molti problemi, come l'incompatibilità con le relazioni dello stesso sesso, l'incesto, ecc. Che nella vita reale accade più spesso di quanto si possa immaginare (soprattutto quando si torna indietro nel tempo al 1700-1800).

Abbiamo modellato il nostro albero genealogico su ciò che accade nel mondo reale: eventi (ad esempio nascite, matrimoni, fidanzamento, sindacati, morti, adozioni, ecc.). Non imponiamo alcuna limitazione su questi, tranne quelli logicamente impossibili (ad esempio, non si può essere il proprio genitore, le relazioni hanno bisogno di due individui, ecc ...)

La mancanza di convalide ci offre una soluzione più "reale", più semplice e più flessibile.

Per quanto riguarda questo caso specifico, suggerirei di rimuovere le asserzioni in quanto non valide universalmente.

Per visualizzare i problemi (che sorgeranno), suggerirei di disegnare lo stesso nodo tutte le volte che è necessario, suggerendo la duplicazione illuminando tutte le copie selezionando uno di essi.

Rilassa le tue affermazioni.

Non modificando le regole, che sono probabilmente molto utili al 99,9% dei tuoi clienti nel rilevare errori nell'inserimento dei loro dati.

Invece, cambiarlo da un errore "impossibile aggiungere una relazione" a un avviso con un "aggiungi comunque".

Ecco il problema con gli alberi genealogici: non sono alberi. Sono grafici aciclici diretti o DAG. Se capisco correttamente i principi della biologia della riproduzione umana, non ci saranno cicli.

Per quanto ne so, anche i cristiani accettano i matrimoni (e quindi i bambini) tra cugini, che trasformeranno l'albero genealogico in un DAG di famiglia.

La morale della storia è: scegliere le giuste strutture di dati.

Immagino che tu abbia un valore che identifica in modo univoco una persona su cui puoi basare i tuoi assegni.

Questo è difficile. Supponendo che tu voglia mantenere la struttura come un albero, ti suggerisco questo:

Supponi questo: Aha figli con sua figlia.

Asi aggiunge al programma come Ae come B. Una volta nel ruolo di padre, chiamiamolo ragazzo.

Aggiungi una is_same_for_out()funzione che dice all'output che genera parte del tuo programma che tutti i link che vanno Binternamente dovrebbero andare alla Apresentazione dei dati.

Ciò renderà un lavoro extra per l'utente, ma immagino che l'IT sarebbe relativamente facile da implementare e mantenere.

Partendo da questo, potresti lavorare sulla sincronizzazione del codice AeB evitare incoerenze.

Questa soluzione non è sicuramente perfetta, ma è un primo approccio.

Dovresti concentrarti su ciò che rende davvero prezioso il tuo software . Il tempo impiegato per farlo funzionare per UN consumatore vale il prezzo della licenza? Probabilmente no.

Ti consiglio di scusarti con questo cliente, dirgli che la sua situazione non rientra nel campo di applicazione del tuo software e di concedergli un rimborso.

Avresti dovuto creare la famiglia Atreides (moderna, Dune o antica, Edipo Rex ) come caso di prova. Non trovi bug usando i dati sanificati come test case.

Questo è uno dei motivi per cui lingue come "Go" non hanno affermazioni. Sono usati per gestire casi a cui probabilmente non hai pensato, troppo spesso. Dovresti solo affermare l'impossibile, non semplicemente l'improbabile . Fare quest'ultimo è ciò che dà alle asserzioni una cattiva reputazione. Ogni volta che digiti assert(, vai via per dieci minuti e davvero pensaci .

Nel tuo caso particolarmente inquietante, è sia immaginabile che spaventoso che una simile affermazione sia falsa in circostanze rare ma possibili. Quindi, gestiscilo nella tua app, anche solo per dire "Questo software non è stato progettato per gestire lo scenario che hai presentato".

Affermare che il tuo grande, grande, bisnonno essere tuo padre come impossibile è una cosa ragionevole da fare.

Se avessi lavorato per una società di test che era stata assunta per testare il tuo software, ovviamente avrei presentato quello scenario. Perché? Ogni "utente" giovanile ma intelligente farà esattamente la stessa cosa e apprezzerà il "bug report" che ne deriva.

Odio commentare una situazione così sbagliata, ma il modo più semplice per non riaccendere tutti i tuoi invarianti è creare un vertice fantasma nel tuo grafico che funga da proxy per il padre incestuoso.

Quindi, ho fatto qualche lavoro sul software dell'albero genealogico. Penso che il problema che stai cercando di risolvere sia che devi essere in grado di camminare sull'albero senza entrare in loop infiniti - in altre parole, l'albero deve essere aciclico.

Tuttavia, sembra che tu stia affermando che esiste solo un percorso tra una persona e uno dei suoi antenati. Ciò garantirà che non ci siano cicli, ma è troppo rigoroso. Biologicamente parlando, la discendenza è un grafico aciclico diretto (DAG). Il caso che hai è certamente un caso degenerato, ma quel tipo di cose succede sempre sugli alberi più grandi.

Ad esempio, se guardi i 2 ^ n antenati che hai alla generazione n, se non ci fossero sovrapposizioni, avresti avuto più antenati nel 1000 d.C. di quante persone vivessero. Quindi, ci deve essere una sovrapposizione.

Tuttavia, si tende anche a ottenere cicli non validi, solo dati errati. Se stai attraversando l'albero, allora i cicli devono essere affrontati. Puoi farlo in ogni singolo algoritmo o sotto carico. L'ho fatto a carico.

La ricerca di cicli reali in un albero può essere eseguita in diversi modi. Il modo sbagliato è di contrassegnare ogni antenato di un determinato individuo e, quando si attraversa, se la persona che si sta per passare al prossimo è già contrassegnata, quindi tagliare il collegamento. Ciò interromperà relazioni potenzialmente accurate. Il modo corretto per farlo è partire da ogni individuo e contrassegnare ogni antenato con il percorso verso quell'individuo. Se il nuovo percorso contiene il percorso corrente come sottotraccia, allora è un ciclo e deve essere interrotto. È possibile memorizzare i percorsi come <bool> vettoriale (MFMF, MFFFMF, ecc.) Che rende il confronto e l'archiviazione molto rapidi.

Esistono alcuni altri modi per rilevare i cicli, come l'invio di due iteratori e la possibilità di scontrarsi con il test del sottoinsieme, ma alla fine ho usato il metodo di archiviazione locale.

Si noti inoltre che non è necessario recidere effettivamente il collegamento, è possibile modificarlo da un normale collegamento a un collegamento "debole", che non è seguito da alcuni dei tuoi algoritmi. Dovrai anche fare attenzione quando scegli quale link contrassegnare come debole; a volte puoi capire dove dovrebbe essere interrotto il ciclo guardando le informazioni sulla data di nascita, ma spesso non riesci a capire nulla perché mancano così tanti dati.

Un'altra finta risposta seria per una domanda stupida:

La vera risposta è utilizzare una struttura dati appropriata. La genealogia umana non può essere pienamente espressa usando un albero puro senza cicli. Dovresti usare una sorta di grafico. Inoltre, parla con un antropologo prima di andare oltre, perché ci sono molti altri posti in cui si potrebbero fare errori simili cercando di modellare la genealogia, anche nel caso più semplice del "matrimonio monogamico patriarcale occidentale".

Anche se vogliamo ignorare le relazioni tabù a livello locale come discusso qui, ci sono molti modi perfettamente legali e completamente inaspettati per introdurre cicli in un albero genealogico.

Ad esempio: http://en.wikipedia.org/wiki/Cousin_marriage

Fondamentalmente, il matrimonio con la cugina non è solo comune e previsto, è la ragione per cui gli esseri umani sono passati da migliaia di piccoli gruppi familiari a una popolazione mondiale di 6 miliardi. Non può funzionare diversamente.

Ci sono davvero pochi universali quando si tratta di genealogia, famiglia e lignaggio. Quasi ogni severa ipotesi sulle norme che suggeriscono chi può essere una zia, o chi può sposare chi, o come i bambini sono legittimati ai fini dell'eredità, può essere sconvolta da qualche eccezione in qualche parte del mondo o della storia.

A parte le potenziali implicazioni legali, sembra certamente che tu debba trattare un "nodo" su un albero genealogico come una persona predecessore piuttosto che supporre che il nodo possa essere la sola persona.

Chiedi al nodo dell'albero di includere una persona e i successori, quindi puoi avere un altro nodo più in profondità nell'albero che include la stessa persona con successori diversi.

Alcune risposte hanno mostrato modi per mantenere le asserzioni / invarianti, ma questo sembra un uso improprio di asserzioni / invarianti. Le asserzioni devono assicurarsi che qualcosa che dovrebbe essere vero sia vero, e gli invarianti devono assicurarsi che qualcosa che non dovrebbe cambiare non cambi.

Quello che stai affermando qui è che non esistono relazioni incestuose. Chiaramente fanno esistere, così la sua affermazione non è valida. Puoi aggirare questa affermazione, ma il vero bug sta nell'affermazione stessa. L'asserzione dovrebbe essere rimossa.

Il tuo albero genealogico dovrebbe usare le relazioni dirette. In questo modo non avrai un ciclo.

I dati genealogici sono ciclici e non rientrano in un grafico aciclico, quindi se si hanno asserzioni contro i cicli, è necessario rimuoverli.

Il modo di gestirlo in una vista senza creare una vista personalizzata è di trattare il genitore ciclico come genitore "fantasma". In altre parole, quando una persona è sia padre che nonno della stessa persona, allora il nodo del nonno viene mostrato normalmente, ma il nodo padre viene visualizzato come nodo "fantasma" che ha una semplice etichetta come ("vedi nonno" ) e indica il nonno.

Per eseguire i calcoli potrebbe essere necessario migliorare la logica per gestire i grafici ciclici in modo che un nodo non venga visitato più di una volta se esiste un ciclo.

La cosa più importante è avoid creating a problem, quindi credo che dovresti usare una relazione diretta per evitare di avere un ciclo.

Come diceva @markmywords, #include "fritzl.h".

Finalmente devo dire recheck your data structure. Forse qualcosa non va laggiù (forse un elenco collegato bidirezionale risolve il tuo problema).

Le asserzioni non sopravvivono alla realtà

Di solito le affermazioni non sopravvivono al contatto con i dati del mondo reale. Fa parte del processo di ingegneria del software decidere, con quali dati si desidera trattare e quali non rientrano nell'ambito.

Grafici familiari ciclici

Per quanto riguarda gli "alberi" familiari (in realtà sono grafici completi, inclusi i cicli), c'è un bel aneddoto:

Ho sposato una vedova che aveva una figlia adulta. Mio padre, che ci visitava spesso, si innamorò della mia figliastra e la sposò. Di conseguenza, mio ​​padre divenne mio figlio e mia figlia divenne mia madre. Qualche tempo dopo, ho dato a mia moglie un figlio, che era il fratello di mio padre, e mio zio. La moglie di mio padre (che è anche mia figlia e mia madre) ha un figlio. Di conseguenza, ho avuto un fratello e un nipote nella stessa persona. Mia moglie ora è mia nonna, perché è la madre di mia madre. Quindi sono il marito di mia moglie e allo stesso tempo il nipote di mia moglie. In altre parole, sono mio nonno.

Le cose diventano ancora più strane quando prendi i surrogati o "paternità sfocata".

Come affrontarlo

Definire i cicli come fuori campo

Potresti decidere che il tuo software non dovrebbe affrontare casi così rari. In tal caso, l'utente dovrebbe utilizzare un prodotto diverso. Ciò rende la gestione dei casi più comuni molto più solida, poiché è possibile mantenere più asserzioni e un modello di dati più semplice.

In questo caso, aggiungi alcune buone funzionalità di importazione ed esportazione al tuo software, in modo che l'utente possa migrare facilmente su un prodotto diverso quando necessario.

Consenti relazioni manuali

È possibile consentire all'utente di aggiungere relazioni manuali. Queste relazioni non sono "cittadini di prima classe", ovvero il software li prende così come sono, non li controlla e non li gestisce nel modello di dati principale.

L'utente può quindi gestire casi rari a mano. Il tuo modello di dati rimarrà abbastanza semplice e le tue affermazioni sopravviveranno.

Fai attenzione alle relazioni manuali. C'è la tentazione di renderli completamente configurabili e quindi creare un modello di dati completamente configurabile. Questo non funzionerà: il tuo software non si ridimensionerà, otterrai strani bug e infine l'interfaccia utente diventerà inutilizzabile. Questo anti-pattern è chiamato "soft coding" , e "Il WTF quotidiano" è pieno di esempi per questo.

Rendi il tuo modello di dati più flessibile, salta asserzioni, verifica invarianti

L'ultima risorsa sarebbe rendere il tuo modello di dati più flessibile. Dovresti saltare quasi tutte le asserzioni e basare il tuo modello di dati su un grafico completo. Come mostra l'esempio sopra, è facilmente possibile essere tuo nonno, quindi puoi anche avere dei cicli.

In questo caso, è necessario testare ampiamente il software. Hai dovuto saltare quasi tutte le asserzioni, quindi ci sono buone possibilità di ulteriori bug.

Utilizzare un generatore di dati di test per verificare casi di test insoliti. Ci sono biblioteche di controllo rapido per Haskell , Erlang o C . Per Java / Scala ci sono ScalaCheck e Nyaya . Un'idea di prova sarebbe quella di simulare una popolazione casuale, lasciarla incrociare a caso, quindi prima importare il software e quindi esportare il risultato. L'aspettativa sarebbe che tutte le connessioni nell'output siano anche nell'input e viceversa.

Un caso in cui una proprietà rimane invariata viene chiamato invariante. In questo caso, l'invariante è l'insieme di "relazioni romantiche" tra gli individui nella popolazione simulata. Prova a trovare il maggior numero possibile di invarianti e testali con dati generati casualmente. Gli invarianti possono essere funzionali, ad esempio:

• uno zio rimane zio, anche quando aggiungi più "relazioni romantiche"
• ogni bambino ha un genitore
• una popolazione con due generazioni ha almeno un nonno

Oppure possono essere tecnici:

• Il tuo software non andrà in crash su un grafico fino a 10 miliardi di membri (indipendentemente da quante interconnessioni)
• Il software si ridimensiona con O (numero di nodi) e O (numero di bordi ^ 2)
• Il tuo software può salvare e ricaricare ogni grafico familiare fino a 10 miliardi di membri

Eseguendo i test simulati, troverai molti casi angolari strani. La loro riparazione richiederà molto tempo. Inoltre perderai molte ottimizzazioni, il tuo software funzionerà molto più lentamente. Devi decidere se ne vale la pena e se questo rientra nell'ambito del tuo software.

Invece di rimuovere tutte le asserzioni, dovresti comunque controllare cose come una persona che è il suo genitore o altre situazioni impossibili e presentare un errore. Forse emettere un avviso se è improbabile in modo che l'utente possa ancora rilevare errori di input comuni, ma funzionerà se tutto è corretto.

Vorrei memorizzare i dati in un vettore con un numero intero permanente per ogni persona e memorizzare i genitori e i figli in oggetti di persona in cui il suddetto int è l'indice del vettore. Sarebbe abbastanza veloce per passare da una generazione all'altra (ma lento per cose come la ricerca dei nomi). Gli oggetti sarebbero in ordine di quando sono stati creati.

Duplica il padre (o usa il link simbolico / riferimento).

Ad esempio, se si utilizza un database gerarchico:

$ #each person node has two nodes representing its parents.
$ mkdir Family
$ mkdir Family/Son
$ mkdir Family/Son/Daughter
$ mkdir Family/Son/Father
$ mkdir Family/Son/Daughter/Father
$ ln -s Family/Son/Daughter/Father Family/Son/Father
$ mkdir Family/Son/Daughter/Wife
$ tree Family
Family
└── Son
    ├── Daughter
    │   ├── Father
    │   └── Wife
    └── Father -> Family/Son/Daughter/Father

4 directories, 1 file