-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid using unnecessay key variables in multi-table feature construction #485
Avoid using unnecessay key variables in multi-table feature construction #485
Conversation
2487446
to
f571965
Compare
// d'enregistrements (par CountDistinct, ici redondant avec Count). | ||
// On interdit l'utilisation des cles du schema-multi-table pour la construction de variables. | ||
// Les cles ne sont pas des attributs porteurs d'information. | ||
// Pour la classe racine, les cles apparaissent une seule fois par instance, et ne peuvent pas etre informatives. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we rather mention "classe principale" ("main class" / "main table") rather than "root"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corrigé
- cette PR a été fait indépendamment de la PR 462 improving uniqueness management in multi table schemas #484 qui a pris en charge le renommage systématique selon root ou main
- et ici, il s'agit bien de la classe pirncipale
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small rephrasal (see relevant comment)?
f571965
to
052bcff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, the comment seems clear.
Contexte - schema en etoile, construction de variable - comme la cle d'une sous-table (du moins la sous-partie commune à la cle de la table mere) ne peut contenir d'information dejà traitee dans le dictionnaire parent, cette cle n'est pas exploitee pour la construction de variable - exemple: SpliceJunction - la variable SampleId est utilise en cle de SpliceJunction - la variable SampleId est utilisee en cle de la table secondaire SpliceJunctionDNA - on n'exploite donc pas cette variable Probleme potentiel: - si le champ cle de la table secondaire a un autre nom, cette variable secondaire peut alors etre traitee à tort comme un champ non cle distinct de la cle du dictionnaire parent, et etre exploitee pour la construction de variable - exemple: - SpliceJunction, en renommant Sample_Id en SampleId dans la table secondaire - les resultats de modelisation en generant 100 variables seraient alors differents à tort En fait, le probleme est deja traite correctement dans le code - KDMultiTableFeatureConstruction::ComputeAllClassesCompliantRules - on a uniquement enrichi le commentaire, et corrige les typos Ajout d'un jeu de test dedie LearningTest\TestKhiops\MultiTables\SchemaDifferentKeyNames
052bcff
to
1d4a36d
Compare
Contexte
Probleme potrentiel:
En fait, le probleme est deja traite correctement dans le code
Ajout d'un jeu de test dedie LearningTest\TestKhiops\MultiTables\SchemaDifferentKeyNames