Le deep learning a le vent en poupe mais il se trouvent quelques uns pour rappeler que l'approche, aussi interessante et fructueuse soit elle, a quelques limites et inconvenients.
MIT technology review fait un article sur Gary Marcus et la boite qu'il vient de fonder, Geometric Intelligence.
Il prone une AI basee sur des algos plus proches du fonctionnement du cerveau humain. En particulier, une maniere d'acquerir des regles generales a partir d'un nombre reduit d'exemples.
En comparaison, un reseau de neurones type deep learning va avoir besoin d'entre quelques centaines a plusieurs millions d'exemples afin de decouvrir le fonctionnement qu'on lui demande d'atteindre.
Ca semble etre l'approche pronee aussi par bon nombre de chercheurs dans le domaine de l'AGI (Artificial General Intelligence). Certains presentent des architectures conceptuelles assez elaboree mais il manque les details pratiques de conception ainsi que des demonstrations des capacites reelles.
Geometric Intelligence a l'air d'avoir deja des resultats pratiques donc j'espere qu'ils sortiront des demonstrations de leur technologie bientot!
jeudi 17 décembre 2015
mardi 15 décembre 2015
Le deep learning pour tous
C'est la foire aux bonnes nouvelles pour tout ceux qui veulent se mettre au deep learning, des labos et grosses boites sortent leurs outils maison au grand jour, en version gratuite et open source!
- Caffe, de l'univeriste de Berkeley, USA, etait deja la depuis un bout de temps
- Theano a egalement une bonne longueur d'avance
- il y a presque un an, Facebook filait un module deep learning pour le framework Torch
- Brainstorm, de l'institut IDSIA, Suisse, est arrive sur Github il y a quelques mois
- MxNet, du groupe DMLC, s'est pointe dans ces eaux la aussi, je crois...
- quelques semaines apres, Google file son TensorFlow
- il y a quelques jours, la creation d'OpenAI, une organisation dediee a la recherche et le partage (gratuit!) de travaux en IA (ils n'ont encore rien sorti mais elle contient deja pas mal d'experts dans le domaine apparemment)
- et maintenant, Facebook ouvre le design de Big Sur, son matos hardware specialise pour le deep learning
... et il me semble qu'il y avait encore d'autres annonces de ce style ces derniers mois...
C'est le moment de se remettre au Python et/ou de ressortir le C++! ...et de trouver une idee geniale d'application qui aille au dela des domaines usuels.
Pour s'initier au domaine, il y a quelques cours bien faits et gratuits sur le net, dont celui sur les reseaux de neurones sur Coursera, et puis les tutoriaux qui viennent avec certains de ces frameworks.
Pour l'instant, d'apres les echos du net, MxNet semble etre le plus interessant (et surtout, rapide!).
- Caffe, de l'univeriste de Berkeley, USA, etait deja la depuis un bout de temps
- Theano a egalement une bonne longueur d'avance
- il y a presque un an, Facebook filait un module deep learning pour le framework Torch
- Brainstorm, de l'institut IDSIA, Suisse, est arrive sur Github il y a quelques mois
- MxNet, du groupe DMLC, s'est pointe dans ces eaux la aussi, je crois...
- quelques semaines apres, Google file son TensorFlow
- il y a quelques jours, la creation d'OpenAI, une organisation dediee a la recherche et le partage (gratuit!) de travaux en IA (ils n'ont encore rien sorti mais elle contient deja pas mal d'experts dans le domaine apparemment)
- et maintenant, Facebook ouvre le design de Big Sur, son matos hardware specialise pour le deep learning
... et il me semble qu'il y avait encore d'autres annonces de ce style ces derniers mois...
C'est le moment de se remettre au Python et/ou de ressortir le C++! ...et de trouver une idee geniale d'application qui aille au dela des domaines usuels.
Pour s'initier au domaine, il y a quelques cours bien faits et gratuits sur le net, dont celui sur les reseaux de neurones sur Coursera, et puis les tutoriaux qui viennent avec certains de ces frameworks.
Pour l'instant, d'apres les echos du net, MxNet semble etre le plus interessant (et surtout, rapide!).
jeudi 9 juillet 2015
la désillusion du loto
Un petit site pour essayer de nous faire comprendre pourquoi on ne gagnera probablement jamais au loto:
http://chronoloto.com/index.phpComme disait mon prof de math au lycée, pendant le cours de probabilités: avec une chance sur plusieurs millions, on paie un impot volontaire pour rêver un peu.
Il aimait bien rêver!
Le retour de la vengeance des robots compagnons: buddy
Buddy: le nouveau projet de robot compagnon à financement participatif (français!)
https://www.indiegogo.com/projects/buddy-your-family-s-companion-robot#/storyCa comprend:
- une tablette 8 pouces (20.3 cm, système métrique, bordel de merde!!) qui peut tourner sur 2 axes
- une petite base mobile qui comprend des capteurs d'obstacles
- connectivité wifi et bluetooth pour éventuellement commander ton bordel à la maison
- en option, un bras incluant un pico projecteur
Il rejoint la course des robots, relativement abordables, qui se veulent utiles dans la maison, et qui comprend quelques poids lourds dont:
- Jibo : https://www.jibo.com/
- Personal Robot : https://www.kickstarter.com/projects/403524037/personal-robot/description
Je suis curieux de voir ce que vont donner tout ces robots à l'utilisation. J'ai peur que la compréhension du langage soit un gros frein à leur adoption en masse.
Avec Siri ou Google Now, il faut régulièrement se répéter pour qu'un ordre soit compris correctement, et du coup, je m'en passe complètement.
Dans une maison avec du bruit autour, si t'es pas juste à côté du robot, ca risque d'être encore pire.
vendredi 22 mai 2015
un ordinateur à 9$
plus fort que le raspberry pi ou arduino!
..en tout cas, moins cher et qui fait plein de trucs:
https://www.kickstarter.com/projects/1598272670/chip-the-worlds-first-9-computerCHIP comprend: CPU, GPU, RAM, disque dur, wifi, bluetooth 4.0, micro USB, sortie composite video, entrée micro, sortie headphone, entrees/sorties analogiques et numeriques.
Et tout ça tourne sur une debian, à peu près, de base avec interface graphique.
ideal pour un ordi pour enfant ou une multitude de projets robotiques ou IoT (Internet of Things)
Par contre, ca n'est livré que l'année prochaine (...si ca n'est pas juste un beau rêve qui ne se réalisera pas)
vendredi 24 avril 2015
bande annonce ICRA 2015
La plus grosse conférence internationale en robotique aura lieu le mois prochain a Seattle, USA.
THE rendez-vous incontournable pour tous les chercheurs en robotique afin de se tenir au courant des dernières avancées dans les différentes branches!Alors, ça manque un peu de joie de vivre et d'entrain dans la narration, et, bien sur, il manque tous les travaux qui ne sont pas livrés avec vidéo... mais ça reste intéressant! J'espère qu'ils pousseront l'idée un peu plus loin d'année en année.
jeudi 23 avril 2015
Technique de log .NET C#: TraceSource et FileLogTraceListener
.NET possède un système pas trop mal pour logger différents types d'infos dans des fichiers de façon relativement simple. En fait, plusieurs façons de le faire existent mais je ne détaille que la méthode retenue qui correspond à ce que je cherche en ce moment: TraceSource et FileLogTraceListener.
La classe TraceSource nous donne accès à quelques méthodes et constantes pour enregistrer plusieurs types d'informations de côté. Ces informations peuvent être filtrées et récupérées par des Listener qui peuvent les afficher dans des consoles ou les enregistrer dans des fichiers.
FileLogTraceListener range les infos qu'on lui dis de récupérer dans un ou plusieurs fichiers en fonction de la date ou divers autres paramètres.
Dans mon code source .cs:
using System.Diagnostics;
using Microsoft.VisualBasic.Logging;
...
class Program{
// défini un TraceSource avec un nom spécifique
static TraceSource tracer = new TraceSource( "mesTraces" );
static void Main( string[] args ) {
int idTrace = Process.GetCurrentProcess().Id;
// change le nom de base du fichier de log utilisé pour les traces
var ecouteurs = tracer.Listeners; // récupère la liste des listeners liés à mon TraceSource
for( int i=0; i<ecouteurs.Count; i++ ) {
try{
var ecout = (FileLogTraceListener)ecouteurs[i];
ecout.BaseFileName = "TestTraces-"+ args[1]; // le nom du fichier log généré sera du type TestTraces-<nom donné en argument d'entrée>-<date du jour>
break;
}catch( Exception e ){}
}
...
tracer.TraceEvent( TraceEventType.Information, idTrace, "infos blabla" );
...
tracer.TraceEvent( TraceEventType.Warning, idTrace, "Attention!" );
...
tracer.TraceEvent( TraceEventType.Error, idTrace, "Gros Problème!" );
...
tracer.Close();
}
}
Bref, pas trop de trucs compliqués à gérer dans le code!
- on ajoute les using qui correspondent
- on définit et initialise un TraceSource
- optionnellement, on peut modifier le nom de base du fichier crée par les listeners lié au TraceSource
- on logge les infomations que l'on veut avec la fonction TraceEvent qui nous permet d'indiquer le type d'informations (voir les Trace Event Type), un entier que l'on peut utiliser comme on veut, et notre message
- on ferme le Tracer quand on en a plus besoin
La gestion des infos loggées peut se faire dans le code source directement, mais j'ai préféré mettre tout ca dans le fichier de configuration de façon à pouvoir modifier le comportement sans avoir à tout recompiler.
Dans mon app.config:
<system.diagnostics>
<!-- switchValue= Off, Error, Warning, Info, Verbose -->
<sources>
<source name="mesTraces" switchType="System.Diagnostics.SourceSwitch" switchValue="Verbose">
<listeners>
<add name="ecouteurFileLog" type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
Location="ExecutableDirectory"
logFileCreationSchedule="Daily"
baseFileName="ListingPrint"
traceOutputOptions="Timestamp" />
<remove name="Default" />
</listeners>
</source>
</sources>
</system.diagnostics>
La, c'est un peu plus verbeux..
- dans la définition de la source, on indique le nom du TraceSource à regarder = le nom donné à ton TraceSource dans le code source.
- switchValue permet de dire quelles informations vont être sauvegardées dans le fichier. Off: on ne met rien, Verbose: on met tout, ...
- on peut ajouter plusieurs listeners par source pour avoir plusieurs fichiers de log différents ou pour afficher aussi les logs à l'écran...
- mon FileLogTraceListener a un type qui est long à définir.. mais il faut tout ca sinon on a des problèmes à l'exécution!
- quelques paramètres à donner au listener (voir la page MSDN pour plus de détails). A noter que les dates et heures récupérées avec les options traceOutputOptions DateTime et Timestamp sont UTC, pas locales! ...et ca ne se configure pas..
- de base, FileLogTraceListener ajoute la date du jour au nom de fichier de log généré!
Bon, ca n'est pas parfait:
- les infos rajoutées à chaque ligne du fichier log sont dans un ordre défini:
nom du traceSource, id, type de message, message, traceOutputOptions
si tu veux mettre la date au début ou virer le nom du traceSource, tant pis!
- les dates/heures du traceOutputOptions sont en UTC! Donc vive le calcul mental, ou alors tu laisses tomber le traceOutputOptions et tu intègres la date locale dans chacun de tes messages (surcharges des fonctions traceEvent, ...)
Après, rien ne nous empêche de créer notre propre listener selon nos envies.
La classe TraceSource nous donne accès à quelques méthodes et constantes pour enregistrer plusieurs types d'informations de côté. Ces informations peuvent être filtrées et récupérées par des Listener qui peuvent les afficher dans des consoles ou les enregistrer dans des fichiers.
FileLogTraceListener range les infos qu'on lui dis de récupérer dans un ou plusieurs fichiers en fonction de la date ou divers autres paramètres.
Dans mon code source .cs:
using System.Diagnostics;
using Microsoft.VisualBasic.Logging;
...
class Program{
// défini un TraceSource avec un nom spécifique
static TraceSource tracer = new TraceSource( "mesTraces" );
static void Main( string[] args ) {
int idTrace = Process.GetCurrentProcess().Id;
// change le nom de base du fichier de log utilisé pour les traces
var ecouteurs = tracer.Listeners; // récupère la liste des listeners liés à mon TraceSource
for( int i=0; i<ecouteurs.Count; i++ ) {
try{
var ecout = (FileLogTraceListener)ecouteurs[i];
ecout.BaseFileName = "TestTraces-"+ args[1]; // le nom du fichier log généré sera du type TestTraces-<nom donné en argument d'entrée>-<date du jour>
break;
}catch( Exception e ){}
}
...
tracer.TraceEvent( TraceEventType.Information, idTrace, "infos blabla" );
...
tracer.TraceEvent( TraceEventType.Warning, idTrace, "Attention!" );
...
tracer.TraceEvent( TraceEventType.Error, idTrace, "Gros Problème!" );
...
tracer.Close();
}
}
Bref, pas trop de trucs compliqués à gérer dans le code!
- on ajoute les using qui correspondent
- on définit et initialise un TraceSource
- optionnellement, on peut modifier le nom de base du fichier crée par les listeners lié au TraceSource
- on logge les infomations que l'on veut avec la fonction TraceEvent qui nous permet d'indiquer le type d'informations (voir les Trace Event Type), un entier que l'on peut utiliser comme on veut, et notre message
- on ferme le Tracer quand on en a plus besoin
La gestion des infos loggées peut se faire dans le code source directement, mais j'ai préféré mettre tout ca dans le fichier de configuration de façon à pouvoir modifier le comportement sans avoir à tout recompiler.
Dans mon app.config:
<system.diagnostics>
<!-- switchValue= Off, Error, Warning, Info, Verbose -->
<sources>
<source name="mesTraces" switchType="System.Diagnostics.SourceSwitch" switchValue="Verbose">
<listeners>
<add name="ecouteurFileLog" type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
Location="ExecutableDirectory"
logFileCreationSchedule="Daily"
baseFileName="ListingPrint"
traceOutputOptions="Timestamp" />
<remove name="Default" />
</listeners>
</source>
</sources>
</system.diagnostics>
La, c'est un peu plus verbeux..
- dans la définition de la source, on indique le nom du TraceSource à regarder = le nom donné à ton TraceSource dans le code source.
- switchValue permet de dire quelles informations vont être sauvegardées dans le fichier. Off: on ne met rien, Verbose: on met tout, ...
- on peut ajouter plusieurs listeners par source pour avoir plusieurs fichiers de log différents ou pour afficher aussi les logs à l'écran...
- mon FileLogTraceListener a un type qui est long à définir.. mais il faut tout ca sinon on a des problèmes à l'exécution!
- quelques paramètres à donner au listener (voir la page MSDN pour plus de détails). A noter que les dates et heures récupérées avec les options traceOutputOptions DateTime et Timestamp sont UTC, pas locales! ...et ca ne se configure pas..
- de base, FileLogTraceListener ajoute la date du jour au nom de fichier de log généré!
Bon, ca n'est pas parfait:
- les infos rajoutées à chaque ligne du fichier log sont dans un ordre défini:
nom du traceSource, id, type de message, message, traceOutputOptions
si tu veux mettre la date au début ou virer le nom du traceSource, tant pis!
- les dates/heures du traceOutputOptions sont en UTC! Donc vive le calcul mental, ou alors tu laisses tomber le traceOutputOptions et tu intègres la date locale dans chacun de tes messages (surcharges des fonctions traceEvent, ...)
Après, rien ne nous empêche de créer notre propre listener selon nos envies.
Premier pas en robotique pour les tout petits
Ils proposent des sets de pièces en bois/plastique/électronique qui s'emboitent facilement pour créer un robot mobile (ou pas).
Le comportement du robot se programme en assemblant des gros cubes: pas besoin de savoir lire pour créer le programme!
Les tout petits peuvent s'initier avec ce kit et, en grandissant, continuer la programmation avec Scratch, ou la robotique avec Lego Mindstorms.
Inscription à :
Articles (Atom)
Articles
