Rétroaction
fraction
La vertu de la boucle rétroactive est inhérente à son programmeur.
L'information structurante de ce réseau rétroactif est déjà proposée
par lui. Si j'apprends à mon IA à jouer aux dames, elle deviendra peut-
être meilleure que moi dans les faits, mais pas en droit. Car c'est
moi qui lui ai injecter la structure vertueuse.
Quant à parler de rétroaction structurante, je crois que l'alcool
n'est pas suffisant.
Yliur
fraction <frac...@tele2.fr> a écrit :
> Il n'existe qu'une seule fonction circulaire vertueuse : le travail.
> La vertu de la boucle rétroactive est inhérente à son programmeur.
> L'information structurante de ce réseau rétroactif est déjà proposée
> par lui. Si j'apprends à mon IA à jouer aux dames, elle deviendra
> peut- être meilleure que moi dans les faits, mais pas en droit. Car
> c'est moi qui lui ai injecter la structure vertueuse.
Oui, c'est apprentissage.
fraction
>
> > Il n'existe qu'une seule fonction circulaire vertueuse : le travail.
> > La vertu de la boucle rétroactive est inhérente à son programmeur.
> > L'information structurante de ce réseau rétroactif est déjà proposée
> > par lui. Si j'apprends à mon IA à jouer aux dames, elle deviendra
> > peut- être meilleure que moi dans les faits, mais pas en droit. Car
> > c'est moi qui lui ai injecter la structure vertueuse.
>
> Oui, c'est apprentissage.
D'accord. Mais l'apprentissage machine c'est quoi ? De nouveaux objets
et de nouvelles propriétés. Rien d'autre. Nous avons l'amont
structurel sur elle, c'est irréversible, ontologique. A nous de lui
offrir une structure digne de représenter l'ensemble de ce qui peut se
concevoir.
Je n'y arriverais pas seul, c'est évident. Il existe meilleurs
programmeurs (c'est certain) et meilleur manager que moi. Mais la
philosophie (analytique), si longtemps improductive et oisive au cours
des siècles, peut s'avérer pertinente s'agissant de l'IA généraliste.
C'est mon propre.
fraction
déterminer une collection sous forme d'arbre (un arbre causal par
exemple, généalogique) ?
Yliur
fraction <frac...@tele2.fr> a écrit :
> Saurais-tu par hasard s'il est possible (avec Visual Basic) de
> déterminer une collection sous forme d'arbre (un arbre causal par
> exemple, généalogique) ?
Je ne connais pas Visual Basic (ou très peu).
Et je ne comprends pas ta question : qu'entends-tu par "déterminer une
collection sous forme d'arbre" ? Est-ce que tu veux représenter un
arbre ?
fraction
>
> > Saurais-tu par hasard s'il est possible (avec Visual Basic) de
> > déterminer une collection sous forme d'arbre (un arbre causal par
> > exemple, généalogique) ?
>
> Je ne connais pas Visual Basic (ou très peu).
> Et je ne comprends pas ta question : qu'entends-tu par "déterminer une
> collection sous forme d'arbre" ? Est-ce que tu veux représenter un
> arbre ?
J'ai besoin de représenter un arbre causal, dont le nombre de noeuds
est variable. VB offre la possibilité de déterminer une collection
d'objets, ainsi que de définir des classes. Mais cette collection est
linéaire. J'aurais aimé pouvoir définir des arbres sans faire
intervenir de module parent.
J'ai posté ce message sur "objet" et sur "algorithmes". Espérons
qu'ils connaissent VB.
Yliur
fraction <frac...@tele2.fr> a écrit :
> On 13 oct, 16:43, Yliur <yl...@free.fr> wrote:
Il doit y avoir un groupe consacré à VB :) .
Sinon pour faire un arbre il te faut juste une classe représentant un
noeud de l'arbre. Cette classe contient une liste de noeuds fils et
d'autres informations que tu veux stocker dans ton noeud.
Et c'est tout : un arbre c'est un noeud qui possède un certain nombre
de noeuds fils :) .
fraction
> Sinon pour faire un arbre il te faut juste une classe représentant un
> noeud de l'arbre. Cette classe contient une liste de noeuds fils et
> d'autres informations que tu veux stocker dans ton noeud.
> Et c'est tout : un arbre c'est un noeud qui possède un certain nombre
> de noeuds fils :) .
J'ai à peu près compris.
Mais d'abord je ne sais pas déclarer une liste dont le nombre
d'éléments est variable.
Ensuite j'ai besoin de traiter ces noeuds en fonction de leurs
coordonnées dans l'arbre.
fraction
VB à C++, compte tenu de mes ambitions ? Si oui, pourquoi ?
Yliur
fraction <frac...@tele2.fr> a écrit :
> Pour information, me conseillerais-tu de passer de VB à prolog ou de
> VB à C++, compte tenu de mes ambitions ? Si oui, pourquoi ?
Ca dépend de ce que tu veux faire exactement. Je trouve ça toujours
flou.
Prolog ça peut convenir à ce que tu veux faire, mais c'est...
particulier. Ce sera peut-être plus simple de commencer avec un
langage que tu connais (ou proche de ce que tu connais). Il sera
toujours temps de passer à un autre quand tu auras avancé et que tu
auras une idée plus précise de la manière dont tu veux représenter
l'information.
Et je ne vois pas bien l'intérêt de C++, à ce compte-là fais du Java,
ce sera nettement plus simple, surtout si tu n'as jamais fais de
C/C++.
Ca m'ennuierait de défendre le monde de Microsoft, mais si tu sais faire
des classes en VB (des vraies classes de données, pas juste
manipuler les composants graphiques), tu peux commencer avec ça. Le
principal inconvénient c'est peut-être que ce n'est pas vraiment
portable sur autre chose que Windows (et encore... il faut être sûr
d'avoir toutes les DLL).
Je ne pense pas que tu aies besoin de structures complexes
actuellement, donc tu peux choisir n'importe quel langage que tu
connais bien, ce sera plus facile pour commencer. Et ensuite... on
verra suivant ce à quoi ça ressemble.
fraction
qu'il boguait avec de trop gros modules).
Yliur
fraction <frac...@tele2.fr> a écrit :
> VB ne saurait pas gérer les structures complexes ? (J'ai déjà constaté
> qu'il boguait avec de trop gros modules).
Si tu cherches un langage à objets pas trop difficile, passe alors à
Java. Tu as tout ce qu'il te faut comme collections pour structurer
l'information comme tu veux (listes, tables de hachage, ...) et ce
n'est pas très compliqué (beaucoup moins technique que C++).
fraction
>
> > VB ne saurait pas gérer les structures complexes ? (J'ai déjà constaté
> > qu'il boguait avec de trop gros modules).
>
> Si tu cherches un langage à objets pas trop difficile, passe alors à
> Java. Tu as tout ce qu'il te faut comme collections pour structurer
> l'information comme tu veux (listes, tables de hachage, ...) et ce
> n'est pas très compliqué (beaucoup moins technique que C++).
D'accord,mais le plus de VB, c'est qu'il travail avec Excel. Java a-t-
il l'équivalent (en matière de mémoire morte) ? J'en doute.
Yliur
fraction <frac...@tele2.fr> a écrit :
> On 13 oct, 22:29, Yliur <yl...@free.fr> wrote:
Elle est pas morte... C'est de la mémoire de masse.
Si vraiment tu veux un stockage aussi simple que des lignes de valeurs,
utilise le format CSV (Excel sait par exemple lire et écrire des
fichiers au format CSV). Il s'agit de lignes de valeurs, les valeurs
étant séparées par des virgules (en principe la première valeur de
chaque ligne correspond à une colonne et donc les premières valeurs
sont du même type).
Mais ce sera peut-être plus simple de stocker les données dans une base
de données (suivant comment tu représentes tes informations, encore
une fois).
Je ne vois pas l'intérêt d'Excel là-dedans.
fraction
masse ?
Yliur
fraction <frac...@tele2.fr> a écrit :
> C'est quoi la différence entre une mémoire morte et une mémoire de
> masse ?
La mémoire morte c'est celle sur laquelle tu ne peux plus écrire (ROM
en anglais : Read-Only Memory, mémoire en lecture seule). Par exemple
il y en avait dans les BIOS mais je crois que maintenant c'est de la
mémoire flashable, donc plus morte :) .
fraction
> en anglais : Read-Only Memory, mémoire en lecture seule). Par exemple
> il y en avait dans les BIOS mais je crois que maintenant c'est de la
> mémoire flashable, donc plus morte :) .
Merci.
J'ai résolu mon problème d'arborescence. Mais je suis actuellement
confronté à un autre problème qui me semble insurmontable. J'ai besoin
de définir un tableau dont le nombre de dimensions est variable. J'ai
peur qu'à partir des variables de VB, ce soit impossible. Mais peut-
être que je peux avec Excel, en construisant un tableau 2D croissant
(le nombre d'éléments de chaque dimension étant constant).
Yliur
fraction <frac...@tele2.fr> a écrit :
> > La mémoire morte c'est celle sur laquelle tu ne peux plus écrire
Tu peux aussi définir un très grand tableau à une seule dimension,
toutes les cases se trouvant les unes à la suite des autres. Et une
fonction d'accès à un case à laquelle tu passes un tableau de
coordonnées et qui calcule l'adresse de la case dans ton grand
tableau et renvoie la valeur. Mais je ne pense pas que ce soit un
tableau dont tu as besoin.
Qu'est-ce que tu veux stocker dans ton grand tableau ? Et les valeurs
sur les axes des dimensions sont-elles vraiment des nombres ? Selon
ce que tu veux faire, tu pourrais sans doute t'en sortir mieux avec
des valeurs indexées en utilisant des tables de hachage (ou avec une
base de donneés sinon).
fraction
> toutes les cases se trouvant les unes à la suite des autres. Et une
> fonction d'accès à un case à laquelle tu passes un tableau de
> coordonnées et qui calcule l'adresse de la case dans ton grand
> tableau et renvoie la valeur. Mais je ne pense pas que ce soit un
> tableau dont tu as besoin.
> Qu'est-ce que tu veux stocker dans ton grand tableau ? Et les valeurs
> sur les axes des dimensions sont-elles vraiment des nombres ? Selon
> ce que tu veux faire, tu pourrais sans doute t'en sortir mieux avec
> des valeurs indexées en utilisant des tables de hachage (ou avec une
> base de donneés sinon).
Ça y est, mon problème est résolu. J'ai fait un tableau à une
dimension, avec une procédure de conversion pour convertir
l'emplacement en coordonnées à n dimensions.
Je ne connais pas les tables de hachage, ni comment m'en servir.
Je dois étudier une propriété d'objet dont la valeur de vérité dépend
de n autres propriétés. Comme il n'y a que deux valeurs possibles (0
et 1), la conversion est facile.
J'ai déjà fait un premier déducteur. Il peut déduire la valeur
d'existence de toutes les propriétés intrinsèques à un objet.
Mon deuxième déducteur sera un déducteur technique. Il saura trouver
une méthode pour générer n'importe quelle propriété intrinsèque à un
objet.
Dans quelques semaines