Ok merci
Houphouet, fait attention a ta generation de nombre aleatoire.
Ici tu genere tes nombres aleatoire par pair au sein du meme generateur aleatoire. C'est fortement deconseiller car pour beaucoup de generateur (en fait tout les generateurs lineair congruentiel), la generation de valeur est uniforme, mais la generation de pair de valeur ne l'est pas.
Je parlais de ca dans un vielle article que j'avasi ecrit et qui a ete backupe sur [1]
[1] http://demont.valerie.free.fr/site/momo/www.mandragor.org/article4ef9.html?id=12
J'ai pas tout compris après lecture de ton article, mais en gros, le générateur Math.random n'est pas uniforme?
En gros, sur 1.000.000 de lancer d'un Dé de 6, j'aurais pas la même probabilité sur chaque lancer ?
Bon, je vais essayer de déchiffrer ce que sont ces LCG...
Merci
Si je poste le code complet du petit programme que je crée, tu pourrais m'en faire une critique?
Merci ![]()
"le générateur Math.random n'est pas uniforme?"
Le generateur est probablement uniforme en dimension 1, mais pas en dimension 2.
"En gros, sur 1.000.000 de lancer d'un Dé de 6, j'aurais pas la même probabilité sur chaque lancer ?"
La tu auras la meme probabilit sur chaque lance.
Parcontre si tu lance 1.000.000 de fois 2 De a 6 faces, le De numero 1 n'aura pas la meme probabilite que le De numero 2.
"Si je poste le code complet du petit programme que je crée, tu pourrais m'en faire une critique?"
Sure.
Donc pour le Math.random, c'est parce qu'il est éxécuter 2 fois dans la même fonction qu'il y a un problème?
Sinon voilà mon code qui contient 5 classes:
Main: http://pastebin.com/TVgy7nj8
Job: http://pastebin.com/78RMgpRX
Fight: http://pastebin.com/4FzqigKe
Damages: http://pastebin.com/kin7kbcY
Mob: http://pastebin.com/fXMyz80D
Le programme n'est pas du tout fini, tu verras que tout s'exécute en ligne de commande. (Un jour j'aborderai les interface graphique, mais je n'y suis pas encore)
Sinon les propositions (Sorts/Aptitudes et Défendre) ne renvoie à rien, tout comme l'esquive et l'armure ne sont pas encore utilisée.
Je pense qu'il va falloir que j'ordonne un peu mieux tout ce foutoir, mais bon faut bien commencer par quelquechose
Voilà, n'hésite pas à commenter tout ça.
J'aborde tout juste le chapitre de la POO dans le bouquin que je lis:
http://www.amazon.fr/livre-Java-premier-langage-1C%C3%A9d%C3%A9rom/dp/2212119941
(Faudra que je le rende à la bibliothèque un jour d'ailleurs...)
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/
Mine d'or ce texte de Carmack.
petite question à but de perf' principalement : j'ai une appli' Android à reprendre/améliorer/faire évoluer.
Je dois mettre en place une recherche (plein texte et une correspondance terme <-> données). Les données sont, pour le moment, en mémoire vive et devrait être insérée dans la BDD embarquée et prévue pour.
Le problème est que, si le schéma de la BDD est bon, la gestion de celle-ci est catastrophique (pas un jugement, un fait). L'application met de 2 à 8 secondes pour parser les données et de 20 secondes à 1 minute 40 pour sauvegarder 15% des données parsées (le reste n'étant pas encore implémentée mais devrait l'être à terme).
J'hésite donc entre revoir la gestion de la BDD et l'oublier bonnement et simplement et faire mes recherches avec les données en mémoire vive.
Quel serait votre(vos) avis la-dessus s'il vous plaît ?
(si besoin de plus d'infos, pas de souci)
Impossible de répondre...
1) BDD c'est quoi?
2) Quel est le format de données et les quantités attendues?
3) Est-ce que tu insères/update beaucoup ou est-ce que tu fais qu'enregistrer un état des données?
1) BDD => Base de données. Celle utilisée est une SQLite ici, version 3.6.22 (non-ouvert au changement). Je pensais que le terme serait compris de tous, mes excuses ^^'
2) Là, c'est moi qui comprends moins bien. De ce que je comprends de la question : toute les données enregistrées en base seront des Strings. Niveau quantité ... on devrait dépasser le millier d'enregistrement total je pense. J'espère y avoir répondu.
3) Deuxième solution : enregistrer un état de données. Ensuite, ce serait utilisé pour lecture de la base pour recherche/affichage.
Te recherches seront comment?
- Chercher une chaine a l'identique?
- Commence par?
- Ou quelque chose qui ressemble?
En gros, j'essaie de voir de qu'une bdd peut t'apporter en terme de possibilité d'indexage.
C'est pour cela que je te demandais quel était le format de tes enregistrements (ce sont des graphes? des datasets tabulaires?)
Ok je vois mieux.
Les recherches seront basiques :
-mot(s) contenu dans un texte
-mot(s) lié à d'autres
Pour le second cas, une liste de correspondance nous est fourni (si un mot se rapproche de "ALPHA", on voit ce qui correspond et on fait la recherche avec la correspondance). Vu que je n'ai pas encore plus de détail que ça sur ces "tables de correspondance", je ne peux pas être plus clair.
Pour le format, je suis hors-jeu par manque de connaissance, je ne peux pas répondre. Je peux, par contre, donner un exemple de fichier : http://cdm.utdanning.no/eno/example_of_cdm_xml_document (meilleur exemple que j'ai pu trouver -_-').
Pour le coup, j'ai appris le terme "jeu de données tabulaires".
Fichier complet : http://greldinard.heliohost.org/hizin/exemple.xml
Bunyan
Posté le 27 avril 2012 à 12:53:23
Ok je vois mieux.
Les recherches seront basiques :
-mot(s) contenu dans un texte
-mot(s) lié à d'autres
""Pour le second cas, une liste de correspondance nous est fourni (si un mot se rapproche de "ALPHA", on voit ce qui correspond et on fait la recherche avec la correspondance). Vu que je n'ai pas encore plus de détail que ça sur ces "tables de correspondance", je ne peux pas être plus clair.""
A voir c'est une table de synonymes.
"Pour le format, je suis hors-jeu par manque de connaissance, je ne peux pas répondre. Je peux, par contre, donner un exemple de fichier : http://cdm.utdanning.no/eno/example_of_cdm_xml_document (meilleur exemple que j'ai pu trouver -_-').
Pour le coup, j'ai appris le terme "jeu de données tabulaires".
Fichier complet : http://greldinard.heliohost.org/hizin/exemple.xml"
Wow le joli tas de merde... Cependant tu as besoin d'une tolérence orthographique?
Tu dois pouvoir matcher n'importe quoi dans ce contenu ou seulement quelques éléments spécifiques comme les noms et descriptions?
Accent et caractères spéciaux mis à part, pas de tolérance orthographique de prévue (ni de demandée pour le moment).
Pour le fichier, c'est seulement sur quelques balises, qui me sont spécifiées par le client (au moins, ça m'épargne cette recherche).
Généralement, ce sont des feuilles descriptives.
C'est obligatoire que tu bosses en local sur le téléphone ou tu peux envisager un truc client-serveur à travers le web?
Oui, obligatoire.
Ah ca c'est con... Parce qu'il y aurait eu un moyen très simple de faire ces recherches sur un serveur, avec correction orthographique, recherche booléenne, tf-idf et tout.
Actuellement tu fais ça comment? Tu crées un index contenant tous les mots et tu fais un SELECT dessus?
Pour le moment, rien.
Avant de commencer à mettre le tout en branle (savoir si on refond le modèle objet et/ou la base et sa gestion) on s'interroge, ce qui m'amène à cette discussion.
Pour le coup, je pensais faire comme tu le dis. Un bête SELECT sur les tables contenants les infos et voila. Peut-être optimiser un peu en plus.
Histoire de situer aussi, mon collègue et moi connaissons un peu les bases de données (SQL et schéma), mais aller plus loin, c'est largement au-dessus de notre niveau actuel (ce qui n'empêche rien dans l'absolu).
Ps : par contre, je serai quand même intéressé, à titre de curiosité, par ce que tu pensais avec la gestion sur serveur.
j'ai pas entierement compris le probleme exacte, mais ca me fait penser au probleme de reconstruction de genome.
C'est basiquement un probleme de lookup avec innexactitude. Les outils classiquement utilise sont des tables de hashages ou des techniques a base de transformation de burrows-wheeler. Je ne connais pas les details, mais tout le monde fait ca depuis 10 ans et explose tout les autres d'un ordre de grandeur.
Et en particulier, personne ne fait de base de donnees sql pour traiter ces problemes la.
Bunyan
Posté le 27 avril 2012 à 14:03:28
Pour le moment, rien.
Avant de commencer à mettre le tout en branle (savoir si on refond le modèle objet et/ou la base et sa gestion) on s'interroge, ce qui m'amène à cette discussion.
Pour le coup, je pensais faire comme tu le dis. Un bête SELECT sur les tables contenants les infos et voila. Peut-être optimiser un peu en plus.
Les bases de données offrent rarement des possibilités satisfaisantes de recherche full-text. Faire un select sur différentes tables avec des WHERE CONTAINS ou des LIKE reviendra grosso-modo au même que de lire la totalité des données en brute force faute d'index satisfaisant.
En plus il te faudra organiser un ranking.
Il faudrait essayer de créer une table d'index avec dans une colonne chaque mot *unique* recherchable et une relation 1:n vers une autre table contenant contenant.
1) L'ID de l'enregistrement du document qui correspond a la recherche
2) l'endroit ou le mot se trouve (description?, titre?) dans ce document
En fonction de l'endroit tu peux créer un ranking qui dit par exemple qu'un mot trouvé dans le titre est mieux qu'un mot trouvé dans la description. Et là, les index de la DB sont utilisables contrairement à du full-text.
Par contre, cette table faut la générer, si vos données changent pas c'est pas un problème, mais si l'utilisateur supprime-ajoute-édite à tout va faudra en gérer le rafraîchissement, tout à fait faisable mais c'est du boulot.
""Histoire de situer aussi, mon collègue et moi connaissons un peu les bases de données (SQL et schéma), mais aller plus loin, c'est largement au-dessus de notre niveau actuel (ce qui n'empêche rien dans l'absolu).""
Et moi je ne connais pas les performances de sqlite sur des mobiles android. Cependant c'est quand même du boulot et ça demanderait un test grandeur nature avant que vous décidiez d'une solution.
""Ps : par contre, je serai quand même intéressé, à titre de curiosité, par ce que tu pensais avec la gestion sur serveur.""
On dirait une application de consultation de données, donc on peut se poser la question de savoir s'il est nécessaire que chacun des mobiles ait une copie locale des données avec tout ce que ça implique comme problème de mise à jour. Perso j'aurai centralisé les données sur un serveur accessibles depuis le web, et j'aurai laissé en local sur le mobile que les interfaces graphiques.
Tu aurais fabriqué quelques servlets tomcat basées sur lucene que ton client aurait utilisé par HTTP pour se procurer les données. Ainsi tu avais la recherche booléenne, le ranking, le support des approximations, aucun souci de performance et en prime le contenu centralisé.
Enfin, si toi et ton pote êtes assez faibles question dév, c'est quand même pas totalement trivial comme problématique la recherche de contenu.
Je sais parce que c'est l'une de mes spécialités (enfin pas sur android).