Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 154 sur 159 PremièrePremière ... 54104144146147148149150151152153154155156157158159 DernièreDernière
Affichage des résultats 4 591 à 4 620 sur 4746
  1. #4591
    Citation Envoyé par deathdigger Voir le message
    Y’a un truc génial mais aussi pourri dans lis IA, c’est leurs non-prédictibilités.
    Ça dépends de ce qu'on appelle « IA ». Une IA comportementale simple (rare en dehors du domaine des JV et des labos) c'est effectivement non prédictible mais ça converge vite vers un comportement moyen parfaitement connu. Statistiquement c'est au contraire très facilement prédictible.
    Une IA comportementale plus complexe c'est une autre paire de manche, mais ça ne sort presque jamais des labos (jamais vu appliqué dans d'autres domaine réellement).

    Enfin une IA de type entrée/sortie, un simple réseau de neurone type deep learning (la très large majorité des applis dites « d'IA », c'est bien prédictible (même si on ne sait pas comment ça converge exactement dans le détail des poids, on sait parfaitement vers quel résultat ça va, à quel vitesse approximative etc.) .

  2. #4592
    Citation Envoyé par Nilsou Voir le message
    Enfin une IA de type entrée/sortie, un simple réseau de neurone type deep learning (la très large majorité des applis dites « d'IA », c'est bien prédictible (même si on ne sait pas comment ça converge exactement dans le détail des poids, on sait parfaitement vers quel résultat ça va, à quel vitesse approximative etc.) .
    Pas vraiment d'accord. Tu ne peux pas garantir un taux de fausses alarmes avec un classifieur à apprentissage qu'il soit (deep learning, svm ou autre chose). Sauf à maitriser complètement les entrées, ce qui est plutôt rare en application réelle. Les perfs sont donc non prédictibles.
    Les seuls classifieurs que je connaisse qui reste avec des taux prédictibles sont les classifieurs à test d'hypothèse. Mais c'est vraiment particulier à mettre en œuvre (il faut être capable de prouver le comportement stat des données), c'est donc peu répandu.
    Rien ne me choque moi, je suis un scientifique ! - I. Jones

  3. #4593
    Citation Envoyé par Helix Voir le message
    Pas vraiment d'accord. Tu ne peux pas garantir un taux de fausses alarmes avec un classifieur à apprentissage qu'il soit (deep learning, svm ou autre chose). Sauf à maitriser complètement les entrées, ce qui est plutôt rare en application réelle. Les perfs sont donc non prédictibles.
    En général tu a une petite idée des entrée quand même, et tu fais des tests en pratique dans le milieu d'application pour sortir une stats au bout de X jours que ça te donne tant de % de faux positif, faux négatif et tuti quanti. C'est très largement suffisant comme stats dans la majeure partie des cas.

    Pour les applis industrielles ont met en règle générale un système de contrôle non IA qui va venir prendre la main en cas de dépassement de certaine bornes, ça suffit à garantir la sécurité du matériel.

    Par contre, effectivement, les gens qui donnent la main à des IA sans trop de sécurité sur des applications dangereuses, ils ont quand même bien la confiance ^^.

  4. #4594
    Je pensais à des usages chez mes clients. Typiquement, dans le retail, on pourrait imaginer que ça permette de sortir les best-sellers dans un futur proche. Sauf que l'IA évoluant en même tant que tu l'interroges (de ce que j'en ai compris), c'est compliqué de comparer des résultats sur plusieurs périodes : en gros, est-ce que mon produit a plus performé grâce à la conjoncture ou autres, ou parce que mon IA a mieux performé.

    Edit la démo :


    Je pense que les profs vont avoir du souci à se faire pour trouver les fraudes
    Dernière modification par deathdigger ; 16/01/2022 à 11h37.
    Pouet.

  5. #4595
    Citation Envoyé par Nilsou Voir le message
    En général tu a une petite idée des entrée quand même, et tu fais des tests en pratique dans le milieu d'application pour sortir une stats au bout de X jours que ça te donne tant de % de faux positif, faux négatif et tuti quanti. C'est très largement suffisant comme stats dans la majeure partie des cas.
    On est d'accord, mais ce n'est pas ce que j'appelle "garantir" des perfs ou un comportement, c'est plutôt promettre que dans un usage normal, on peut espérer telle ou telle performance.
    Rien ne me choque moi, je suis un scientifique ! - I. Jones

  6. #4596
    Si tu veux, on ne peut certes rien « garantir », mais je n'irais pas non plus parler de « non-prédictibilités.» comme le faisait le canard plus haut. En réalité on sait très bien prédire le comportement global, dans la plupart des cas, de tel ou tel IA, surtout sur avec les outils d'IA les plus communs.
    On peut même dire qu'a entrée connue on peut parfaitement prédire la sortie.

    Dès qu'on parle de « non prédictibilité » ça donne l'impression que le machin est assez bordélique et aléatoire, alors qu'en fait non, c'est plutôt quand les entrées deviennent bordélique et aléatoire qu'on ne peut plus rien garantir, mais est-ce la faute de l'IA ou de l'application dans laquelle on la met ?

  7. #4597
    Ça me semble plus stimulant de dire que c'est la faute des algos.
    Rien ne me choque moi, je suis un scientifique ! - I. Jones

  8. #4598
    Plus « stimulants » ?

  9. #4599
    Oui, ça motive beaucoup plus à chercher des trucs qui marche mieux lorsque tu as en tête que les défauts sont liés à l'approche plutôt qu'au manque de propreté des données, ou que l'application est mal fichue.
    Rien ne me choque moi, je suis un scientifique ! - I. Jones

  10. #4600
    Hello, pour les questions sur du scripting en bash, je suis au bon endroit?

    J'essaie de générer des fichiers pdf depuis des fichiers markdown en passant par pandoc. Je sais taper les commandes séparément:

    find . -maxdepth 1 -name "*.md" -type f

    et

    pandoc -t latex -s mon_fichier.md -o mon_fichier.pdf

    Mais je suis un noob en bash, pour passer les noms de fichier trouvés par la commande find en arguments des options -s et -o de ma commande pandoc, c'est quoi la fonctionnalité que je dois utiliser? Des redirections? Des pipes? Autre chose?

  11. #4601
    Le mieux avec c'est "find [options de recherche] -exec macommand '{}' ';'" mais pas de substitution pour le fichier de sortie. Sinon si tu n'as pas de retour à la ligne dans les noms de fichiers "find [options de recherche] -print | while read file; do macommand "$file" "${file%.md}.pdf"; done". Mais comme tu n'as pas besoin de find dans ton cas précis: "for file in *.md; do macommand "$file" "${file%.md}.pdf"; done" peut suffir.

  12. #4602
    Citation Envoyé par Cwningen Voir le message
    Mais comme tu n'as pas besoin de find dans ton cas précis: "for file in *.md; do macommand "$file" "${file%.md}.pdf"; done" peut suffir.
    Ah, en effet! Merci beaucoup!

    EDIT:

    Citation Envoyé par deathdigger Voir le message
    Je pense que les profs vont avoir du souci à se faire pour trouver les fraudes
    Si d'un autre côté il n'y a plus besoin de créer des supports de cours, c'est un mal pour un bien.

    Blague à part, si les étudiants sont capables d'écrire la logique dans un commentaire, d'utiliser des noms de classes/fonctions conventionnels ou de décomposer en unités avec les bonnes entrées/sorties, est-ce que ce n'est pas la=à le plus important à apprendre? En gros est-ce que l'IA va nous faire plus pratiquer les fondamentaux / abstractions en nous délestant de la syntaxe?

    REEDIT: J'aurais du essayer avec ma commande bash, tiens.
    Dernière modification par raaaahman ; 18/01/2022 à 14h16.

  13. #4603
    Pas tant pour les devs que pour la rédaction (quand elle montre le texte sur le cloud).
    Pouet.

  14. #4604
    Tu as réussi à lire quelque chose sur la rediffusion ou tu étais dans la salle?

  15. #4605
    Sur la vidéo, à la fin, pourquoi ?
    Pouet.

  16. #4606
    Bon il faudra que je la re-mate (la vidéo, hein), j'ai pas bien vu ce que CoPilot produisait.

  17. #4607
    Dites, je rencontre un petit soucis en C standard sur le système d'IO. Je ne m’étais jamais trop frotté aux subtilités du bouzin sérieusement pour faire des choses portables. Mais là j'en ai eu besoin lors de la conception d'un TP.

    En gros, il fut un temps, pour virer ce qu'il y avait dans stdin (si l'utilisateur tape n’importe quoi après une input par exemple) on avait tendance à utiliser fflush(stdin). Mais en réalité le machin n'est pas vraiment censé marcher et, de fait, il ne marche pas sur certaines config.

    Alors en alternative il est souvent proposé d'employer de façon portable une boucle avec un getchar() jusqu’à la fin de l'entrée marquée par \n ou EOF. Néanmoins cette solution a un gros défaut : si l'input est vide à ce moment là alors point de salut et on restera bloqué sur le getchar...

    J'ai un peu fouillé pour voir comment passer stdin temporairement en mode non bloquant ou comment contourner le problème et je ne trouve pas de véritable solution portable...

    Si quelqu'un en connait une ...

    (edit : je me demande si le plus simple n'est pas de combiner avec un ungetc comme ça :

    int c;
    ungetc(32,stdin);
    while ((c = getchar()) != '\n' && c != EOF) { }

    ça semble correct ? (comme je n'ai trouvé cette solution proposée nul part, j'ai un doute ^^)
    )

  18. #4608
    Je les connais mal ces fonctions. fseek, ça marche avec un pipe/terminal ?

    Ah non, tu veux juste passer la ligne courante, pas tout jeter, j'ai lu trop vite.

  19. #4609
    Tu lis comment le début de ligne ? Il n'y a pas moyen de tester si tu as tout lu (getc va bloquer) ou non ?

    Par exemple :
    Code:
    		if (!fgets(line, ARRAY_SIZE(line), stdin)) {
    			fprintf(stderr, "fgets failed\n");
    			return EXIT_FAILURE;
    		}
    		int len = strlen(line);
    		if (len > 0 && line[len-1] != '\n' && !feof(stdin)) {
    			int c;
    			do c = fgetc(stdin);
    			while (c != '\n' && c != EOF);
    		}
    Ça fait longtemps que je les ai pas utilisées, mais à relire les pages de man, je trouve les fonctions de stdio vraiment pas pratiques (et encore, on a supprimé les horreurs comme gets).

  20. #4610
    Code:
    fcntl(0, F_SETFL, fcntl(0, F_GETFL) | O_NONBLOCK);
    C'est tricher?

    - - - Mise à jour - - -

    Sinon de manière portable tu peux toujours créer un thread qui lit avec getc et que tu synchronises comme tu as envie avec le main.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  21. #4611
    Citation Envoyé par Cwningen Voir le message
    Tu lis comment le début de ligne ? Il n'y a pas moyen de tester si tu as tout lu (getc va bloquer) ou non ?
    Bah difficilement je dirais ...
    Perso j'utilisais un fgets suivi d'un scanf avec détection d'erreur, mais va savoir pourquoi parfois ça laisse un machin derrière selon ce que l'utilisateur tape (un \n en plus j'imagine, qui n'est pas récup par le fgets) ...
    Note que ça marche parfaitement sur certaine config et pas parfaitement sur d'autre, mystère.

    Citation Envoyé par rOut Voir le message
    Code:
    fcntl(0, F_SETFL, fcntl(0, F_GETFL) | O_NONBLOCK);
    C'est tricher?
    C'est pas triché mais c'est pas portable du tout de mémoire non ?
    Et c' est bien le problème...

    Je croyais que j'arriverais à quelque chose avec le ungetc(32,stdin); puisque c'est portable et que ça m'assure qu'il y a quelque chose dans la chaine, mais le soucis c'est que si c'est déjà un \n dans la chaine et que je mets un \n en plus, par exemple. Je prends le risque de pas lire jusqu'au bout avec :

    while ((c = getchar()) != '\n' && c != EOF) { }


    Par contre je me demande si je ne pourrais pas écrire tout simplement :

    while ((c = getchar()) != EOF) { }


    Pourquoi les solutions proposées incluent toutes le \n ici ? Il y a un cas ou on rencontrerais la fin de stdin et que ce soit un \n sans EOF tout à la fin ?

    Parce que sinon la solution simple c'est de faire un :
    ungetc([bidule],stdin);
    while ((c = getchar()) != EOF) { }
    Dernière modification par Nilsou ; 26/01/2022 à 19h16.

  22. #4612
    Citation Envoyé par Nilsou Voir le message
    Pourquoi les solutions proposées incluent toutes le \n ici ? Il y a un cas ou on rencontrerais la fin de stdin et que ce soit un \n sans EOF tout à la fin ?
    Parce que tu voulais tout lire (et ignorer) jusqu'à la fin de la ligne, non ? Si tu lis jusqu'à un EOF, tu risques de bloquer entre temps. Et après il n'y aura plus jamais rien à lire dans stdin, donc autant ne rien lire du tout.

  23. #4613
    Qu'entends tu par « tu risques de bloquer entre temps. » en l’occurrence ?
    Mais ok, je vois que EOF n'est pas la solution en fouillant de ci de là.

    Pas si simple de simplement vider stdin

  24. #4614
    EOF ne sera retourné que quand le pipe sera fermé. Si l'utilisateur arrête d'écrire sans fermer le pipe, les fonctions de lecture (getchar, fgets, scanf, ...) bloqueront. C'est ce que tu disais vouloir éviter dans ton premier post.

    Le problème c'est qu'est-ce que ça veut dire "vider stdin" ? Si c'est vider le buffer interne à la libc, fflush le fait, mais comme tu sais pas comment est gérer le buffer, tu ne connais pas l'effet de fflush (qui n'est bien défini que pour les sorties). Si c'est lire tout ce qu'il y a à lire dans le pipe, alors il faudra attendre (donc éventuellement bloquer) que l'autre bout du pipe soit fermé. Même avec des "read" POSIX non-bloquant tu ne peux pas avoir la garantie qu'un pipe soit vide (mais non-fermé), read peut retourner avec EAGAIN mais quelque chose a déjà été écrit le temps que tu lises la valeur de retour.

    Je comprenais l'idée d'ignorer la fin de la ligne, mais là, je ne sais plus trop ce que tu veux faire.

  25. #4615
    Citation Envoyé par Cwningen Voir le message
    EOF ne sera retourné que quand le pipe sera fermé. Si l'utilisateur arrête d'écrire sans fermer le pipe, les fonctions de lecture (getchar, fgets, scanf, ...) bloqueront. C'est ce que tu disais vouloir éviter dans ton premier post.
    Yep, oublions cette solution.

    Citation Envoyé par Cwningen Voir le message
    Le problème c'est qu'est-ce que ça veut dire "vider stdin" ? Si c'est vider le buffer interne à la libc, fflush le fait, mais comme tu sais pas comment est gérer le buffer, tu ne connais pas l'effet de fflush (qui n'est bien défini que pour les sorties).
    C'est bien le problème, ça marche sur quelques config mais pas sur toutes.

    Citation Envoyé par Cwningen Voir le message
    Si c'est lire tout ce qu'il y a à lire dans le pipe, alors il faudra attendre (donc éventuellement bloquer) que l'autre bout du pipe soit fermé. Même avec des "read" POSIX non-bloquant tu ne peux pas avoir la garantie qu'un pipe soit vide (mais non-fermé), read peut retourner avec EAGAIN mais quelque chose a déjà été écrit le temps que tu lises la valeur de retour.
    Bah non, dans mon cas le problème c'est que l'utilisateur a mis quelque chose dans le pipe avant, mais à l'instant t ou je vérifie le pipe j'ai la garantie que personne ne touche au pipe. J'ai juste un pipe dans un état inconnu, mais j'ai la garantie qu'il ne bouge pas, et je veut le vider de son contenu pour pouvoir mettre quelque chose dedans de façon propre sans trainer des caractères parasites.

    Ça me parait clair

    La solution propre est éventuellement d'utiliser fcntl mais ce n'est pas portable il me semble (équivalent sous windows ? )

  26. #4616
    Pour moi, ce n'est pas clair. J'ai l'impression que tu cherches quelque chose de trop compliqué dont tu n'as pas vraiment besoin. En tout cas, ce cas d'utilisation n'est pas prévu par la bibliothèque standard.

    fcntl c'est posix, et posix et win32 n'ont pas grand chose en commun. Il te reste la suggestion de rout avec un thread, son buffer et la synchronisation que tu gères comme tu veux. Mais il n'y a pas de threads dans la bibliothèque standard non plus (ou ça a été ajouté récemment ? je ne suis plus trop à jour sur le C), donc il te faudra une bibliothèque en plus.

  27. #4617
    Je m'en rappelle très mal parce que ça fait longtemps que je n'ai pas utilisé de pipe, mais il me semble que c'est très fortement recommandé de n'utiliser les pipes qu'avec 1 seul producteur (et 1 seul consommateur aussi je crois).
    Citation Envoyé par Nilsou Voir le message
    Bah non, dans mon cas le problème c'est que l'utilisateur a mis quelque chose dans le pipe avant, mais à l'instant t ou je vérifie le pipe j'ai la garantie que personne ne touche au pipe. J'ai juste un pipe dans un état inconnu, mais j'ai la garantie qu'il ne bouge pas, et je veut le vider de son contenu pour pouvoir mettre quelque chose dedans de façon propre sans trainer des caractères parasites.
    Du coup pour moi la solution à ce problème, c'est d'avoir 1 pipe utilisé par l'utilisateur pour pousser des donnés dans ton programme, et qu'il fermera quand il aura fini de s'en servir, et 1 pipe de toi vers l'utilisateur dans lequel tu pousses les donnés que tu veux lui envoyer ?

  28. #4618
    Hello,

    Je sais pas si c'est le bon topic... j'essaye de bricoler un script en NodeJS, et je me retrouve coincé :

    Je crée une connexion ssh avec une private key et je passe une commande, laquelle nécessite un mot de passe pour s'exécuter -- c'est pas du sudo donc pas d'option de modifier sudoers.

    Suite à ma commande, je reçois bien le stdout qui me demande d'écrire le mot de passe, mais là je ne trouve pas comment transmettre ce que le serveur demande et obtenir le résultat.

    (note, j'avais réussi mais en mettant le mot de passe en dur dans le script, ce qui n'est pas une option pour la prod)


    Donc en gros j'ai ceci :

    var conn = new Client();
    conn.on('ready', function() {
    conn.exec('MA COMMANDE QUI DEMANDE UN MOT DE PASSE', function(err, stream) {
    if (err) throw err;
    stream.on('close', function(code, signal) {
    console.log('Stream :: close :: code: ' + code + ', signal: ' + signal);
    conn.end();
    }).on('data', function(data) {
    console.log('STDOUT' + data); ça m'affiche bien ---> "Enter password:"

    Et là rien de ce que j'essaie ne fonctionne... (prompt, prompt-sync, inquirer...)


    Si quelqu'un a une solution, je lui en serais éternellement reconnaissant. (je débute totalement en node)
    F*ck all.

  29. #4619
    Ton Client, j'imagine qu'il vient du module ssh2 ? (https://www.npmjs.com/package/ssh2)
    Je ne l'ai jamais utilisé, mais vu que tu reçois un stream dans ton callback, s'il s'agit d'un duplex stream (sur lequel tu peux lire et écrire), tu devrais pouvoir faire un stream.write() ?

  30. #4620
    exact, ssh2.

    oui c'est ce que j'essaye de faire, mais je ne parviens pas à obtenir un prompt. La doc de ssh2 n'est pas claire là dessus.
    F*ck all.

Page 154 sur 159 PremièrePremière ... 54104144146147148149150151152153154155156157158159 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •