J'ai commencé à regarder et ça me semblait pas mal jusqu'à ce que je tombe sur quelques trucs...
Pourquoi avoir enlevé les parenthèses autour des if, for... On obtient des trucs du genre : for i := 0; i < len(a); i++ {
if a[i] != ' ' {
s += a[i]
}
}
C'est peut-être moi qui suit bigleux mais franchement je trouve ça beaucoup moins clair. Les parenthèse on quand même l'avantage de bien délimiter chaque parties.
Et ensuite, pourquoi suivre la mode qui hélas touche de plus en plus de langage, qui consiste à mélanger la syntaxe et la sémantique. Ici on se retrouve à définir la visibilité des variables, fonctions, membres... en utilisant ou non des majuscules.
Là aussi, je vais peut-être passer pour un con, mais que ce soit le choix des majuscule, des underscores ou de l'indentation ; j'estime que c'est à moi de choisir ce que je trouve le plus lisible, et le langage n'a pas à m'imposer une manière plus qu'une autre.
Le seul avantage, c'est que ça tue le débat entre les partisans du camelcase ou du jesaispasquoi... Mais pour moi, ça donne plus l'impression qu'il veulent imposer leurs conventions et leur style de code.
Donc dommage, encore un langage qui n'est pas pour moi, vieux grincheux que je suis ;-(
C'est même pire que ça. J'ai beau préférer les logiciels libres, j'utilise fréquemment wine pour jouer à quelques jeux que j'aime beaucoup et qui ne sont pas disponible sous linux ou freebsd, les deux seuls os qu'il me reste chez moi.
Le soucis ici, c'est que leur jeux dispose d'un système destiné à favoriser les pirates par rapport aux joueurs honêtes, ils ont donc perdu une vente de plus car même si la démo m'a beaucoup plus, j'acheterais pas ce jeux.
Le système en question favorise les pirates dans le sens ou, il cause pas aml de problème à des gens honêtes qui achêtent le jeux et qui veulent juste pour voir y jouer (et pas uniquement ceux qui veulent y jouer sous wine) alors que les pirates, avant même de lancer le jeux commencent par chercher un crack ou un nocd, savent ou le trouver, et on une version fonctionelle du jeux en moins de temps qu'il ne m'en faut pour installer le jeux.
C'est pas les premiers à perdre mon argent pour ce genre de conneries, et, hélas, j'ai bien peur que ce ne soient pas les derniers.
Je suis désolé mais je vais ignorer la partie débat "logiciel libre" vs "propriétaitaire" de ton message pour me concentré sur la discution sur la forme. Même si ce débat est toujours intéressant, vule contenu de cette page, je ne veut pas y prendre part.
Dans l'ensemble, je pense qu'on est d'accord pour considérer que, d'un point de vue strictement logique, "Je veux voir ma famille en audio/vidéo donc j'utilise Skype" et "Je veux n'utiliser que des logiciels propriétaires donc je n'utilise pas Skype", qu'il s'agisse de choix ou d'obligations, sont des formulations équivalentes (d'un point de vue logique, je le répète).
Et que la formulation "Je n'ai pas le choix, je suis obligé d'utiliser Skype, car je veux absolument voir ma famille en audio/vidéo" est équivalente à "Je n'ai pas le choix, je ne peux pas utiliser Skype, car je ne veux absolument pas de protocole propriétaire".
Ici, on est parfaitement d'accord, donc on part sur de bonnes bases. Je préfère les formulations du premier paragraphe car elles mettent bien en évidence l'ordre dans lequel sont fait les choix, sans ambigüités.
Autrement dit, étant donné que la logique est la même (des impératifs, ou choix, qui ont une conséquence, et l'utilisateur explique la conséquence en listant ses impératifs), comment se fait-il que la façon de le dire est typiquement différente?
Mon avis à moi est que la formulation "je n'ai pas le choix" serait utilisée afin de se débarrasser de la responsabilité dudit choix, donc liée à un sentiment de culpabilité: si ce n'est plus un choix, je n'ai pas de raisons de me sentir coupable de ses conséquences.
[...] alors je me garderai bien de présenter cette conclusion comme définitive: ça reste pour moi une hypothèse, faute de mieux.
Ici par contre, je serait plus mitigé. D'un point de vue construction des phrases, il me semble plus naturel de parler 'obligation pour quelque chose que l'on doit faire, plutôt que pour quelque chose que l'on ne peut pas faire.
Pour être un peut plus clair, si l'on reformule la phrase précédente pour utiliser le terme "obligé" on obtient : "Je n'ai pas le choix, je suis obligé de ne pas utiliser Skype, car je ne veux absolument pas de protocole propriétaire"
Le sens de la phrase à subtilement changé et maintenant, implicitement, il indique que à la base on aurait aimé utilisé skype mais que le choix de ne pas utiliser de protocole propriétaire nous empêche de la faire.
Pour moi, il faut bien voir que dans les deux sens, il y a des implications différentes. A la base on a toujours un utilisateurs de logiciel libres, et qui a donc une préférence pour ceux-ci.
- dans le premiers cas, il est ammener à faire un choix qui par la suite l'empêche d'utiliser des logiciel libres, ce choix va donc à l'encontre de son souhait d'utiliser des logiciel libres, il est donc bien perçu comme faire quelque chose de désagréable ;
- dans le deuxième cas, il fait un choix qui le conforte dans ses convictions : "ne pas utiliser de protocol fermé", donc ses conséquences : "ne pas utiliser skype", sont perçues comme naturelles.
On peut reformuler à nouveau la deuxième phrase en : "je souhaite voir ma famille en vision ; je choisit de ne pas utiliser de logiciels propriétaire, donc je n'ai pas le choix, je suis obliger d'abandonner l'idée de voir ma famille en visio et je vais me rabatre sur le téléphone." et dans ce cas on voit bien apparaitre l'aspect impératif.
Le truc, c'est qu'en général, on ne donne pas les prémices elle semblent toujours implicites, donc dans leurs discours :
- l'utilisateur de logiciels libres semble conforter dans sa position et n'a pas vraiment l'air d'être privé de quelque chose, ou bien passe pour un intégriste ou un extrémiste ;
- celui qui finit par utiliser un logiciel libre passe pour une pauvre victime ou pour quelqu'un qui veut que l'on s'apitoie sur son sort.
Mais dans les deux cas, je ne suis pas sur que ce soit volontaire. Je suis même persuadé que c'est le plus souvent dû aux ambigüités de notre belle langue...
Tes précisions ne doivent pas être suffisantes pour moi car j'ai l'impression que je n'ais toujours pas compris ce que tu mets derrière le mot "obligatoire".
Est-ce que tu peut me donner un exemple d'une action qui serait obligatoire pour toi.
Si j'ai bien compris ce que tu entends par obligatoire, ce serait une action pour laquelle on ne peut pas choisir entre l'executer, ou ne pas l'executer. Et, dans tous les cas que je peut imaginer actuellement, la seule solution pour ne pas avoir ce choix, c'est de volontairement interdire un des deux.
Donc soit j'ai mal compris ce que tu entends par obligatoire, soit il y a un truc qui cloche. Dans tous les cas un exemple serait le bien venu.
Pour ce qui est de faire le malin avec une phrase compliqué, c'était juste pour détendre un peu l'atmosphère et sortir des attaques ridicules que l'on peut voir tout au long de cette page. En soit je trouve qu'un petit débat sur la notion de choix n'est pas inintéressant, bien au contraire, mais les discutions peuvent vite devenir stérile ici.
J'essaye de comprendre ton point de vue et de t'expliquer le mien, c'est tout, et un peu d'humour évite parfois les dérapage. Mais il me semble que j'ai loupé mon coup.
D'ailleur, si l'on regarde la page de wikipedia sur les sophismes, puisque tu en parlais à mon propos, on peut voir une liste des types d'arguments falacieux:
Si on prend ton deuxième paragraphe, même si tu met entre parenthèse "enfin pour moi", la dernière phrases est quand même relativement catégorique. On pourrais facilement le mettre dans la première catégorie des sophismes selon john stuart mill. Et c'est justement le fais que tu ne donne pas d'arguments, mais que tu te contente de dire "c'est comme ça" sans expliquer pourquoi, qui fait que je ne peut pas comprendre ton point de vue.
Et ta dernière phrase entre dans le cadre, à mon avis, des arguments falacieux de type "Argumentum ad hominem" un peu plus bas sur la même page.
Donc, soit on continue, et tu m'explique ton point de vue en argumentant et moi je fais l'effort d'essayer de comprendre, comme ça tout se passe bien et on finira peut-être un peu moins cons tous les deux. Soit tu dis clairement que tu ne veut pas discuter calmement du sujet en exposant des arguments plutôt qu'en faisant de la broderie et on arrête là cette discution pour pas perdre de temps.
Qu'un choix entraine une obligation n'est pas une connerie, c'est parfaitement naturel. Si ce n'était pas le cas, rien ne serais obligatoire et ce concept n'existerais même pas.
Une obligation résulte des contraintes qui se posent et qui réduisent les possibilités. Tu te trouves être obligé de choisir parmis ces possibilités uniquement, car les autres sont interdites du fait des contraintes.
Donc, pour un problème donné, tu commences par choisir les contraintes que tu acceptes, et ensuite tu regardes les possibilités qu'il te reste. Et dans le cas ou il n'y en à qu'une, tu es obligé de la choisir.
Dans la pratique c'est même bien plus complexe que cela et la chaine est souvent très longue. Les contraintes que tu est succeptible de choisir sont définies par les choix précédents et ainsi de suite.
Dans le cas présent, il faut bien voir que les deux choix sont fais l'un après l'autre et non-pas simultanément. Le premier à donc une influence sur le deuxième, une influence qui est même très forte car elle réduit le choix à une seule possibilité, donc une obligation.
Il aurrait aussi pus faire un choix global entre : "voir ma famille en vision -> utiliser skype" et "utiliser uniquement des LL -> ne pas voir ma faille en visio". Mais dans la pratique on fait toujours les choix séquentiellement en fonction de ses priorités, et ventuellement on les révises s'ils posent de trop fortes contraintes sur les choix suivants.
En quelques sortes, tu "t'obliges toi-même". Ça te paraît pas débile comme concept ? Pour moi, ça ne veut rien dire : ce n'est pas une "obligation", c'est un choix.
Si l'on suis ton raisonement jusqu'au bout, rien n'est obligatoire et je ne comprend même pas que l'on ai pus imaginer ce concept. D'après ce que tu dis, si quelqu'un t'oblige à faire quelque chose, tu as toujours le choix de refuser, non ?
Pour faire de la philo de comptoir, On peut même dire qu'une obligation ne peut venir que de soit. On fait le choix d'accepter de faire ce que nous demande une autre personne, plutôt que de faire le choix de refuser.
Donc fait le choix de s'obliger à faire ce qu'une autre personne pense nous obliger à faire sans nous laisser le choix ;-)
Votre discution est bien marrante mais il y a une chose que personne n'a dit clairement mais qui devrait mettre les chose un peu en ordre...
Pour ce qui est des choix vous avez tous les deux raisons puisque vous ne parlez pas de la même chose ;-)
Il à fait le choix de voir sa famille quelque soit le logiciel qu'il doivent utiliser. <-- à ce moment là, il a le choix et il à fait son choix.
Seul skype marche correctement, donc il l'utilise. <-- à ce moment là il n'a pas le choix, pour pouvoir réaliser son premier choix, il est obligé d'utiliser skype.
Il faut bien distinguer les deux étapes, et on voit clairement qu'il à fait un choix : "sa famille avant tout" et que ce choix entraine une obligation "utiliser skype" car c'est le seul logiciel qui puisse satisfaire son premierchoix.
Donc au final, sur l'aspect réthorique de la discution, vous avez tous les deux raison vu que vous ne parlez pasde la même chose. Sur tout ce qu'il y a autour, je ne donnerais pas mon avis, je me contenterais de dire que je me suis bien marrer en lisant certains commentaires...
Tout d'abord quelques précisions sur la gestion des tableaux en C et surtout en C99. Le terme tableau dynamique est ambigüe dans le sens ou la taille des tableaux ne change pas. Elle est juste fixée à l'éxecution et non pas à la compilation.
Ce qui veut dire que si tu déclare : int tbl[3][5]; Le compilateur va produire du code pour allouer 15 emplacements sur la pile, et quand tu va indicer ton tableau, il va produire du code qui fait x * 5 + y. 5 est donc ici une constante qu'il peut stocker dans la pile, dans un registre ou dans l'instruction elle-même.
Quand tu fait : int tbl[X][Y]; Il va produire une allocation sur la pile qui commence par calculer la taille et ensuite réserve l'espace sur la pile. Pour l'indicage, c'est pareil sauf que cette fois ci la taille est forcement dans la pile ou dans un registre et ne peut pas être dans l'instruction elle-même.
Dans les deux cas, une fois la mémoire allouée sur la pile, il n'est plus possible de changer la taille du tableau; et ce n'est pas lié au C mais au principe même des allocation sur la pile.
Si l'on utilise la gestion interne des tableau par C99, on a un programme simple et lisible, aux prix de devoir tout mettre dans la même fonction.
Les solution alternative sont (ne pas oublier que l'on travail ici avec plusieurs tableaux) :
1/ continuer d'utiliser la gestion classique mais avec de multiple fonctions qui passe en plus des tableaux, leur dimension. On obtient des prototypes à rallonge et on augmente les risque d'erreurs au moment du passage de paramètres. Si l'on passe 4 tableaux à 2 dimension, ça fait 12 paramètres.
2/ on fait une grosse structure dans laquelle on passe le tout, ce qui nous donne :
typedef struct {
int *t1, x1, y1;
int *t2, x2, y2;
int *t3, x3, y3;
} state_t;
void etape1(state_t *st) {
...
st->t1[x * st->y1 + y] = val;
...
}
void algo(void) {
int x1 = ...;
....
int t1[...], t2[...], t3[...];
state_t st = {t1, x1, x1, t2, x2, x2, t3, x3, x3};
etape1(&st);
...
}
C'est un schéma très classique en C mais c'est tout sauf lisible. L'accès à un élément dans les sous-fonction est ien moins simple car le calcul que le compilo peut faire tout seul doit ici être fait de manière explicite.
La création et l'initialisation de la structure montre que l'on retrouve le même problème que lors du passage de paramètre: Une grosse liste de valeur à passer dans le bon ordre sans ce tromper.
3/ Faire une petite bibliothèque à côter pour gérer les tableaux. On note tout d'abord que même si elle est parfaite elle ne résout pas le problème. Dans le cas de l'algo de CRF, tu a 7 tableaux et 5 variables à passer aux différentes fonction, donc même si tes tableaux sont réduit à une structure, ça fait encore 13 variables donc tu est obligé de passer par une autre structure qui englobe le tout.
Ensuite, il devient difficile d'allouer cette structure dans la pile sans faire des acrobaties, imaginons la structure suivante :
typedef struct {
int *d, sx, sy;
} table_t;
Pour créer un tableau sur la pile il faut que tu ai quelquechose allouer sur la pile à mettre dans *d, ce qui te donne un code d'initialisation du genre :
int raw_d[x * y];
table_t tbl = {raw_d, x, y};
Ce qui n'est pas vraiment lisible, et tu as toujours le problème de l'indiçage.
Pour l'indiçage, une seule solution : une macro ce qui implique une syntaxe qui n'est plus celle des tableaux, donc moins lisible.
Pour la création des tables, tu ne peux pas utiliser directement une macro car la variable raw_d doit avoir un nom différent à chaque fois.
Donc la seule solution qui reste est de passer par une fonction qui fait un malloc et il ne faudra donc pas oublier de faire un free à la fin...
Comme tu peut le voir, c'est un truc que j'ai déjà pas mal potassé, et avant de faire des fonctions de cette taille je réfléchit toujours plusieurs fois et je cherche d'autre solutions.
Pour être honnête il y a une éventuelle solution au sujet de l'initialisation, tu peut faire une macro qui crée ta structure avec un "alloca" pour allouer les donnée sur la pile, mais ce n'est plus portable et ça ne résout pas le problème de l'indiçage qui est illisible.
Le problème ici n'est pas lié au langage mais au calcul que l'on souhaite faire. Ce calcul nécessite de construire de nombreux résultats intermédiaire qui sont utilisés tout au long des différentes étapes du calcul. Si l'on souhaite découper ce calcul en sous fonctions il est donc nécessaire de pouvoir faire passer un grand nombre de paramètre d'une fonction à l'autre sans que cela deviennent illisible.
Dans le cas du C ça demanderais deux modifications :
- pouvoir passer un tableaux dynamique à plusieurs dimensions dans une structure ;
- l'ajout d'une directive du style du "with" en pascal qui permet d'importer dans l'espace lexical local les nom d'une structure. ça permettrait de ce passer du "st->".
Cela ne résoudrais pas complètement le problème car il faudrait toujours construire et détruire cette structure, mais les sous-fonctions pourrait être lisibles.
L'aspect gestion de la mémoire était plus un élément anecdotique dans mon argumentaire au début, quand je listait les avantages que l'on a parfois faire de grosse fonctions ou gros blocs indentés.
as de bol d'avoir parlé du C vu que justement c'est le language que j'utilise dans les deux cas et qu'il est la source d'un argument supplémentaire dans le deuxième cas...
Pour l'algo sur les CRF je dois utiliser des tableaux à deux dimensions et plus dont la taille n'est pas connue à la compilation. Une des nouveautée cool du C99 est la tableau dynamiques qui me permmettent de faire :
int x = /* calcul de la taille X */;
int y = /* calcul de la taille Y */;
double tbl[x][y];
Le problème c'est que ce tableau ne peut pas se trouver dans une structure car la taille de la structure doit être connue à la compilation... De même, le passage de ce tableau en paramètre d'une fonction est embetant, soit je passe la taille des dimenssion en paramètre :
void mafonction(int x, int y, double tbl[x][y])
Ce qui devient vite les bordel si on a plusieurs tableau en paramètres. Soit ma fonction est capable de retrouver toute seule les dimension et donc je peut passer le tableau sous forme unidimentionelle, mais dans ce cas l'indicage devien chiant à mourir.
On est ici dans le cas ou une limitation du langage rajoute encore une couche au fait que le programme est bien plus lisible. La version splité en plusieurs fonctions se retrouve avoir des trucs du genre :
mdl->tbl[x * mdl->dimenx + y] = val;
ce qui est bien moins lible que juste
tbl[x][y] = val;
Mais si l'indicage est lié au langage, le fait de devoir aller chercher le tableaux dans une structure est lié à la décomposition. Pourquoi aller chercher un tableaux qui est juste une étape temporaire dans l'algo à l'interieur du structure qui donne l'impréssion d'avoir étée allouée quelque part ailleur ?
Bien sur, il est toujour possible d'avoir une structure "state" qui devient un fourtout pour toutes les variables à passer d'une fonction à l'autre. Mais dans ce cas pourquoi ce faire chier avec ce genre de truc :
void etape1(state *st) {...}
void etape2(state *st) {...}
void etape3(state *st) {...}
void etape4(state *st) {...}
void algo(void) {
state st;
etape1(&st);
etape2(&st);
etape3(&st);
etape4(&st);
}
alors que
void algo(void) {
/* etape1 */
...
/* etape2 */
...
/* etape3 */
...
/* etape4 */
...
}
est tout aussi clair, indique bien que les trois étape sont séquentielles, et n'oblige pas de faire une gymnastique avec une structure batarde ?
Et il ne faut pas oublier que ça simplifie le travail du compilateur. La sémantique et la portée des données et explicite et permet souvent des optimisations plus agréssive.
Perso, je pense toujours qu'il ne faut faire confiance ni aux dévelopeurs, ni au compilateur... donc je fais le code le plus simple, le plus lisible et le plus explicite possible, même si ça doit violer les style de codage.
Le compilo ne produira pas forcement du code plus rapide, mais dans tous les cas, il y a peut de chance qu'il soit plus lent.
Les autres dévellopeurs comprennent plus facilement mon code et on moins de chances de faire des conneries quand ils le modifient ou le maintiennent.
> Le problème c'est plutôt ton bloc de 3-4 écrans que l'indentation type python....
> Personnellement, un bloc qui fait 10 lignes je m'en méfie, qu'il y ai des {} ou non.
Pas forcément... Je me bat depuis longtemps contre les personnes qui considèrent ce genre de choses comme étant absolues, et qui veulent imposer des style de code sans réfléchir...
J'ai deux exemples de code ou j'ai fait des fonctions de 150 à 200 lignes et qui sont bien plus lisible et ou le risque de bug est bien plus faible que leur équivalent découpé en petites fonctions.
1/ L'implémentation de l'algo benson-pass-alive dans un jeu de go : Cet algo nécéssite 6 tableaux temporaires et tout un tas de petites variables qui sont utilisés tout aux long de l'algo.
Il se découpe facilement en 5 ou 6 étapes: calcul des deux premiers tableaux, premier passage sur le goban, mise à jour des deux suivant, itération de l'algo...
La version en une fonction déclare toutes les donnée au début de la fonction, les tableaux étant internes à l'algo se trouvent alloués dans la pile donc les perfs sont meilleures et il n'y a pas à se préoccuper de les désallouer, c'est fait automatiquement à la sortie de la fonction. Les variables gardent le même nom tout au long de l'algo.
Chaque étape est bien séparée des suivantes par un court commentaire qui indique à quelle étape on en est, ce qui permet de se référer à la description de l'algo dans un gros commentaire avant le début de la fonction.
Bref ça ce lit très bien et le code est facilement compréhensible.
La version qui découpe les différentes étapes dans différentes fonction est par contre beaucoup moin lisible, chaque fonction prend une dizaine de paramètres l'algo en lui même se retrouve explosé, de manière logique bien sur mais c'est plus dur à suivre.
Chaque fonction n'est appellée qu'une fois donc il n'y a pas de problème pour inliner le code mais ça reste moche.
Le grand nombre de paramètre des fonctions fait qu'il est facile de ce tromper.
Je vais pas détailler mais c'est beaucoup moins pratique et bien moins facile de comprendre ce qui ce passe vraiment.
Bien sur ont peut aussi faire une structure ou un objet qui contienne toutes les variables et tableaux temporaire, mais dans ce cas la soit on a langage ou il faut gérer explicitement la mémoire et il faut faire une allocation qui coute cher et ne pas oublier le free. Si on a un langage ou la memoire est gérée automatiquement on ne sait plus vraiment ce qui ce passe ni quel est l'impact de l'allocation.
2/ Le même genre de problème dans le calcul de l'espérance pour l'apprentissage d'un modele CRF. La aussi on a besoin de pas mal de tableaux intermédiaires qui sont chiant à faire passer d'une fonction à une autre alors que de simples variables locales sont tellement plus simple et regroupe toutes les étapes de l'algo au même endroit dans l'ordre ou elle sont éffectuées de manière logique et lisible.
Donc même si de manière générale, il faut éviter les fonctions ou indentations longues, ce n'est pas une véritée absolue et parfois un code peut être écrit de manière bien plus sûre, lisible et maintenable et violant les style de code.
Mon code pour l'éxemple deux est une fonction 175 lignes contenant notament une boucle for de 103 lignes. Une autre version du code qui est distribuée sur 5 fonctions fait au total 286 lignes.
Pour avoir discuté avec 3 personne qui ont du utiliser les deux versions, toutes on admis que la première est bien plus compréhensible, et pour l'une d'elle ce fut vraiment très difficile à admettre...
La seule chose avec ce genre de code c'est qu'il faut être très discipliné, avoir des noms pour toutes les variables qui soient parfaitement explicite et cohérent bien séparer toutes les étapes et avoir un gros pavé de commentaire avant la fonction expliquant ce qu'elle fait et comment elle le fait.
Et bien sûr il ne faut utiliser ce genre de chose que lorsque c'est nécéssaire.
Oui, tu peut créer une application sans Eclipse ou sans le plugin, mais dans ce cas c'est : «démerde toi et assume!» Il n'y a aucune doc de la part de Google et impossible de trouver rien qu'un petit tutoriel sur le net.
Pour ce qui est de l'IHM et du XML, là encore, c'est possible de tout créer à la main, mais toujours pas de doc. Et pour ce qui est du constructeur d'interface, c'est pas encore au point. La méthode recomandée par Google c'est l'écriture directe de XML, et c'est ce qui est recomandé par tous les bouquins que j'ai pus trouver sur Android. Tous les commentaires que j'ai pus voir sur le constructeur d'interfaces était pour le critiquer ou parler de ses bugs.
Je ne connais pas les autres plateformes mobiles, donc je ne peut pas comparer les SDKs, j'ai éssayé Android car je viens de chaanger de portable et le miens est sous cete plateforme, mais je reste super mitigé. C'est peut-être une super plateforme pour certains, mais en tout cas pour moi, ça reste un truc lourding et bordelique à souhaits.
J'en aurais eu besoin pour mon boulot, pas de problème, j'aurais fait l'éffort.
Par contre la ces personel et donc non, je ne vais pas me forcer a programmer dans un langage que je ne peut pas blairer avec une IDE que je trouve inutilisable.
Les dévelopement que je fait sur mon temps personel, je les fais pour mon plaisir, donc oui, j'ai abandonné cette plateforme en grande partie à cause de java, et non ce n'est pas une pale excuse pour de la flemme.
J'ai plein de projet qui me branchent et pas suffisament de temps pour tous, il me semble donc normal de choisir ceux qui me plaisent le plus.
C'est une impression générale après avoir fait les tutoriels du SDK, parcouru la docs et fait quelques éssais. Ce n'est pas lié uniquement au SDK mais aussi à java en lui même, à Eclipse, (qui n'esp pas loin d'être obligatoire) et au good practice de google.
C'est assez dur à décrire, mais en gros on se retrouve avoir un max de fichiers en bordel qui contiennent pas grand chose ou des infos sans vraiment de rapport enrtre elles, des fichiers générés automatiquement sans que l'on sache vraiment ce qu'il y a dedans, n'y quand ils ont été mis-à-jour, mais qu'il faut quand même réussir à utiliser d'une manière ou d'une autre.
Les widgets proposé sont plutôt pas mal, mais pour les utiliser il faut surcharger des méthodes aux noms parfois obscures avec des prototypes à ralonge. Et utiliser l'une d'elles implique parfois de surcharger telle autre sans que ce soit vraiment explicite.
Si on met de côter le fait que je trouve le java particulièrement illisible et eclipse imbitable ; avec un peu de patience il doit pas être trop difficile de ce mettre dans le SDK et de s'en sortir, si on y consacre le temps qu'il faut.
Pour d'en rajouter une couche, j'ai tendance à être alergique au XML, donc on peut dire que j'avais pas beaucoup de chance d'aprécier le SDK... J'asume, et je rééssayerais surement un de ces jours.
Histoire de ne pas être totalement négatif, si quelqu'un connait un bon tutoriel sur le developpement pour android sans passer par Eclipse, et la création des interface à l'aide de code sans les fichiers XML, je suis preneur.
PS: pour pas que le troll soit trop poilu, je tiens quand même à préciser que mes critiques à l'encontre de java ne sont pas du tout liées à des histoire de performance ou autre, mais bien à sa syntaxe et à des critères d'esthétique et d'ergonomie, qui sont des aspects relativement subjectif j'en conviens.
Désolé pour la réponse un peu tardive.
Je ne connaissait pas ce papier, j'ai regardé mais pas encore détaillé. En effet il y a des similaritées dans le sens ou c'est aussi une approche d'optimisation coordonées par coordonées, mais leur approche est stochastique. Il est maintenant dans ma liste de papiers à étudier en détails.
Pour ce qui est du hashing des features, la réponse est non. Le hashing à deux avantages :
-réduire la taille du modèle final en regroupant les features en paquets plus ou moins aléatoire, dans notre cas la régularization L1 permet déjà de réduire la taille du modèle en supprimant les features qui ne sont pas informative, donc au moins théoriquement c'est plus éfficace ;
- réduire la taille du modèle à l'apprentissage, et donc accélérer l'apprentissage. Ça pourrait accélérer l'apprentissage de notre modèle, mais ça peut aurrait des interaction avec la norme L1. Ces interaction ne sont pas forcément génantes en pratique mais il faudrait faire des expérimentation pour en être sur. Pour l'instant en tout cas, on reste sur une gestion classique pour pouvoir évaluer objectivement l'algo.
De plus le hashing n'accélère pas tant que ça l'apprentissage, aussi bien le mapping feature->id que la mise à jour des poids des features sont néligeables par rapport au temps passé au calcule des espérance pour chaque séquences (qui représente en gros 92% du temps d'aprentisage dans notre algo) et il à l'inconvénient que ça fait encore un paramètre de plus à regler. (le nombre de features final)
Il a l'avantage par contre d'être bien plus simple à coder.
J'ai noté ton mail, je te préviens dès que le code est libre.
Mais le NDK ne permet que de faire des bibliothèques de fonctions utilisée par le reste, aps l'interface graphique.
Et, autant sur un ordi classique, ce qui me branche c'est la partie purement algorithmique d'un programe. Autant sur Android, j'avais envie de faire des éssais sur les aspects ergonomiques des interface que l'on peut faire sur ces petits machins.
Donc le NDK, c'est très bien pour coder le coeur d'un programme dont l'interface reste en java tout moche et bien bordelique. Donc pas pour moi...
Hélas, il s'intègre très bien à Android puisqu'il n'y a que ça de disponible. C'est d'ailleur ce qui m'a fait abandoner l'idée de dévelloper pour cette plateforme après avoir joué un peu avec le SDK... Je ne me souvenais pas qu'un programme en Java pouvais être un tel bordel...
Je connais et il est bon pour ce pourquoi il est prévu, c'est à dire une version très simple des CRF linéaires. Les features bigrammes ne peuvent dépendre que des éttiquettes et pas des autres données d'entrée, ce qui est relativement limité mais permet beaucoup d'optimisation du code.
Donc si ce modèle suffit il fait bien le boulot, mais ces pas notre cas... Et le problème c'est justement qu'il est très lié à son modèle ce qui rend difficile de le modifier pour en faire autre chose.
Mon objectif était d'implémenter un nouvel algorithme d'optimisation des CRFs qui optimise le modèle coordonées par coordonées. CRFSuite implémente le gradient classique à l'aide de LBFGS qui optimise tout le modèle à chaque itérations avec toutes les séquences d'entrées ainsi qui le SGD qui optimise tout le modèle avec une seule séquence. Notre approche est d'optimiser une seule coordonée à la fois mais avec toutes les séquence ou cette coordonée est active. On a soumit un papier sur l'algorithme, si le sujet t'intéresse tu peut trouver un preprint ici http://oniros.org/papers/sokolovska09jstsp.pdf .
Il optimise aussi les CRF linéaire mais à l'inverse de CRFSuite il permet d'utiliser des features bigrammes aussi riches que les features unigrammes, ce qui permet de construire des modèles bien plus performants. (mais aussi bien plus long à entrainer...)
La version du programme utilisée quand on à écrit le papier n'utilisait pas le sse, donc les comparaison de vitesse avec CRF++ et CRFsgd sont équitable.
Pour l'instant je travail au nettoyage du code car si l'algorithme en lui même en plutôt propre, c'est pas vraiment le cas de la partie lecture des données et génération des features... J'espère pouvoir le publier bientôt sous licence libre, je ferais un journal au moment ou ce sera près, mais s'il y en à que ça intéresse, n'hésitez pas à me contacter directement.
Les deux version sont compilées sans fast-math, vu les calculs il n'y a de toute façon pas le choix, il faut la précision maximale et c'est déjà parfois limite (un forward/backward sur des séquences un peu longue demande de faire très attention au calcul pour ne pas avoir de probèmes). En plus dans ce cas, l'avantage va nettement à GCC.
C'est même ce problème qui fait que j'ai codé à la fois une version sse2 et une version classique, le sse2 à des registres vectoriels sur 64bits par éléments. Le programme normal choisit, en fonction des conditions, s'il peut utiliser la version sse2 ou s'il doit se rabatre sur la version classique car il risque d'avoir des problèmes.
Qu'il soit compilé avec GCC ou CLang, le programme donne exactement le même résultat au bit près, donc à priori ils font bien le même calcul. Un accord aussi parfait entre les deux m'a même étonné... la preuve que le standard IEEE sur les flotants est pas mal foutu.
Pour ce qui est du code ASM, j'ai beaucop exploré celui de la version sse2 car 95% des séquences sont calculées avec, donc celui là j'ai passé pas mal de temps à l'optimiser, et donc à comprendre le code que me génerait chacun des compilos en fonction de ce que je leur donnait ; par contre la version classique représente trop peu du temps d'éxecution pour que ça vaille le coup de s'en préoccuper. J'ai juste vérifié que les deux compilos utilisait bien la pile flottante classique et pas le sse pour être sur mais c'est tout.
C'est un gros casse tête ces problèmes de précision et à mon avis ces ce qui limite l'utilisation des instruction SIMD dans le calcul scientifique. Avec 80bits de précision, on réussit souvent à s'en sortir sans utilisé de bibliothèque spécialisées. Avec 64 bits c'est un vrai casse-tête.
C'est en effet très dépendant du code, je vous donne les résultats de mes tests entre GCC 4.4 et LLVM+CLang 2.6. Pour les deux j'ai passé pas mal de temps à chercher les bonnes options pour obtenir les meilleurs perfs.
Sur mon programme de Go en C99 pur qui contient beaucoup de manipulation de tableaux d'entiers, CLang est environ 20% plus rapide.
Sur mes programme de calcul scientifique (apprentissage de modèle CRF) avec beaucoup de caculs en flotants double précision. La version qui utilise du code vectoriséen sse2 (intrinsics plus opération sur des __m128d du genre a + b * c) est 24% plus rapide avec CLang ; par contre la version en C99 pur sans utiliser sse2 (juste i686) est 29% plus rapide avec GCC.
Il semble que CLang à plus de mal avec l'unitée de calcul flotant des x86 mais s'en sort très bien quand on lui permet d'utiliser les sse.
Au niveau temps de compilation, je peut pas vraiment dire, même si ce sont des programme très complexes, ils ne dépassent pas les quelques miliers de lignes de code et sont donc très rapide à compiler même avec toutes les options au max.
J'ai dans ma TODO list de pousser un peu plus loin pour voir ce qui fait vraiment la différence ; mais ça reste une entrée de plus dans la liste.. donc je ne sais pas quand j'en aurais vraiment le temps.
Ce qu'il faut bien voir avec LLVM+CLang c'est pas vraiment les perfs actuelles mais surtout le fait que c'est est framework propre et moderne pour la compilation qui est très agréable à utiliser. Donc même si actuellement il n'est pas toujours plus rapide que GCC, il à de bonne chances de représenter l'avenir.
Implémenter de nouvelle passe d'optimisation dans LLVM est infiniment plus facile et plus agréable que dans GCC ; il est donc probable que, progressivement, les nouvelles techniques d'optimisation soient d'abord intégrées dans LLVM avant GCC.
Bien au contraire, il y a beaucoup dans la BSD pour les utilisateurs ; la BSD donne quasiment tous les droits à l'utilisateurs, là ou la GPL ne leur donne pas celui de faire du proprio avec le code.
Il faut bien ce mettre dans le crane que ce sont deux licences différentes et que chacun choisit celle qu'il veut. Et le fait de choisir l'une ou l'autre n'implique pas que tu soit un gentil ou un connard.
L'idée c'est que tu fineras par profiter de son code.
La GPL le force à partager ses modification avec toi même s'il n'en a pas envie. L'idée de la BSD c'est que techniquement la meilleure solution c'est de partager donc pas besoin de le forcer à partager, il finira bien par le faire, ou alors ta solution ouverte attirera d'autre personnes qui ferons la même chose en mieux.
En gros (attention passage à fort caractère trollogène) :
- La GPL c'est "rejoin ma religion et tu profiteras de mon savoir" ;
- La BSD c'est "profite de mon savoir, tu finiras bien par rejoindre ma religion".
J'ai toujours choisit la licence BSD pour mon code tout simplement car je m'en fout que quelqu'un éssaye de faire du proprio avec, par contre si un mec dans une boite pense que mon code peut lui servir et l'intègre dans son logiciel avec quelques améliorations, peut-être qu'il m'enverra un patch ; et ça c'est pas possible avec la GPL.
Et je reste convaincu qu'un jour il n'y aura plus besoin de licence sur les code source car il ne sera même pas envisageable qu'il ne soit pas partageable ou que l'on puisse garder des modifs pour soit. C'est mon côté idéaliste...
Mais en matière de licences, chacun ses goûts.
PS: Pour alimenter les trolls, je rajouterais que j'ai jamais été fichu de comprendre toute la GPL tellement elle est imbitable (comme à peu près tous les document juridiques) donc je préfère mettre mon code sous une licence que je comprend et que me utilisateurs comprendrons surement eux aussi...
C'est marrant car j'ai une vision exactement oposée à la tienne. Pour moi mettre du code sous licence BSD c'est viser l'avenir au contraire de la GPL.
La licence BSD mise sur le fait que techniquement le code ouvert est superieur au code fermer car plus il y a de personnes à regarder, vérifier et contribuer à un code meilleur il sera. Donc il n'y a pas besoin d'utiliser une licence complexe pour assurer l'avenir, technique ceux qui ne jouent pas le jeu finiront par perdre.
Au contraire la GPL c'est n'avoir aucune confiance en l'avenir et être persuader qu'une boite qui reprend le code pour en faire quelque chose de fermé fera mieux que ceux qui y contribuent de manière ouverte, et donc on préfère metre une licence qui empêche cette possibilité.
Mon point de vue c'est que je n'ai pas envie de faire de la politique quand je donne du code, mais juste partager de la technique, donc mon code je le publie sous licence BSD ou équivalente.
Cette formulation n'est plus vraiment correcte, une virgule ça ne s'utilise pas n'importe comment.
Ça me fait penser à un passage du livre «L'élégance du hérisson» de Muriel Barbery :
«Le chat dort.»
La lecture de cette petite phrase anodine n'a éveillé en vous aucun sentiment de douleur, aucun flamboiement de souffrance ? C'est légitime.
Maintenant :
«Le chat, dort.»
Je répète, pour qu'aucune ambiguïté ne demeure :
«Le chat virgule dort.»
D'un côté, nous avons ce prodigieux usage de la virgule qui, prenant des libertés avec la langue parce que d'ordinaire on n'en place point avant une conjonction de coordination, en magnifie la forme :
«M'a-t-on fait assez de reproches, et pour la guerre, et pour la paix...»
Et de l'autre, nous avons les bavouilleries sur vélin de Sabine Pallières transperçant la phrase d'une virgule devenue poignard.
Tu te retrouve à dépendre d'un logiciel compatible avec les scripts init-ng au lieu de dépendre d'un système ayant un shell compatible bourne.
Bien sûr, pour l'instant il y a plus de réimplémentations du bourne shell que de init-ng, mais est-ce une preuve que techniquement c'est mieux ?
Pour corriger ce que dit l'auteru du journal, on ne peut pas vraiment dire que llvm soit encore vraiment expérimental. Il est relativement proche de ce que 'lon pourrait appeller un programme stable, et encore plus dans le cas de la 2.6 qui va bientot sortir, le freeze c'est produit il y a quelques jours.
Le code intermédiaire devrait être parfaitement compatible dans le sens ou un code actuel devrait rester executable par toutes les futures version de llvm, ce qui n'empeche pas à l'avenir d'ajouter de nouvelles instruction si celles-ci sont nécéssaire.
LLVM est même suffisament stable pour que Apple ait choisit de le mettre au coeur de son système, et contribu pas mal au passage. LLVM est une des brique éssentielle du fameux OpenCL.
Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
Vu le projet il y a relativement peut de chance que le dévellopement s'arrete, mais même si c'était le cas, c'est du logiciel libre et il est possible de reprendre le dev.
Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant
LLVM seul ne supporte absolument rien ;-)
C'est juste la spécification d'un code intermédiaire et tout un tas de bibliothèques et outils pour le manipuler et notament le copiler en code natif. Il y a pas mal de projet de compilateurs qui produisent ce code intermédiaire au lieu de produire directement du code natif.
C'est le cas par exemple de clang qui est un copilateur destiner à compiler du C ainsi que d'autre langage dérivés. Et pour CLang, en effet, il supporte actuellement très bien le C et produit du code très performant. L'objective-C est relativeent bien supporté, je sais pas le staus exacte mais là aussi c'est un truc ou apple contribue pas mal. Par contre pour le C++, pour l'instant c'est encore très expérimental et de nombreuse choses ne sont pas implémentée.
Par contre il existe aussi llvm-gcc qui est un bacend pour gcc. C'est-à-dire que c'est une modification de gcc qui lui permet de produire du code llvm au lieu de code pour un processeur. Donc ça permet d'avoir un copilateur qui supporte éxactement les même langages que gcc.
Et il y a différents autres compilos disponibles, même parfois pour des langages auquels on ne penserais as du style un compilateur pour lua.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non?
Comme tu le dis après, L'objectif de llvm c'est quand même de produire du code très performant, et les perfs du code interprété sont quand même pas térrible à côter de celle du binnaire. Et vu le coût du JIT autant ne pas s'en priver.
Et un dernier petit point pour l'auteur du journal. L'argument de ca prend moins de place est loin d'être pertinent, dans la grosse majoritée des pacquet, à mon avis, ce qui prend de la place c'est pas les binnaires mais les donnés. De plus les mesures sont à faire sur le code une foi compressé car à tous les formats de paquets que je connais compressent le tout.
Avant de penser à des optimisation sur la taille du code, il vaudrais mieux faire quelques stat pour savoir s'il y a quelque chose à gagner.
Voilà, j'éspère avoir clarifier quelques points sur llvm et le reste.
Ce que j'aime pas avec apt, c'est comme cité dans un post: apt-get, apt-cache, apt-faitmoilecafe etc..
C'est pénible.
En même temps c'est ton problème si tu utilise encore des outils obsolètes. Le gestionnaire de paquets officiel est aptitude et de ce que je comprend, en plus d'être celui conseillé par la distrib, corespondrait mieux à ce que tu aime.
Mais les gens n'aiment pas lire les release notes...
# Première remarques
Posté par beagf (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 10.
Pourquoi avoir enlevé les parenthèses autour des if, for... On obtient des trucs du genre :
for i := 0; i < len(a); i++ {if a[i] != ' ' {
s += a[i]
}
}
C'est peut-être moi qui suit bigleux mais franchement je trouve ça beaucoup moins clair. Les parenthèse on quand même l'avantage de bien délimiter chaque parties.
Et ensuite, pourquoi suivre la mode qui hélas touche de plus en plus de langage, qui consiste à mélanger la syntaxe et la sémantique. Ici on se retrouve à définir la visibilité des variables, fonctions, membres... en utilisant ou non des majuscules.
Là aussi, je vais peut-être passer pour un con, mais que ce soit le choix des majuscule, des underscores ou de l'indentation ; j'estime que c'est à moi de choisir ce que je trouve le plus lisible, et le langage n'a pas à m'imposer une manière plus qu'une autre.
Le seul avantage, c'est que ça tue le débat entre les partisans du camelcase ou du jesaispasquoi... Mais pour moi, ça donne plus l'impression qu'il veulent imposer leurs conventions et leur style de code.
Donc dommage, encore un langage qui n'est pas pour moi, vieux grincheux que je suis ;-(
[^] # Re: Projets réalisés avec Ogre
Posté par beagf (site web personnel) . En réponse à la dépêche Conférence sur le moteur 3D "Ogre" le 12 novembre 2009. Évalué à 2.
Le soucis ici, c'est que leur jeux dispose d'un système destiné à favoriser les pirates par rapport aux joueurs honêtes, ils ont donc perdu une vente de plus car même si la démo m'a beaucoup plus, j'acheterais pas ce jeux.
Le système en question favorise les pirates dans le sens ou, il cause pas aml de problème à des gens honêtes qui achêtent le jeux et qui veulent juste pour voir y jouer (et pas uniquement ceux qui veulent y jouer sous wine) alors que les pirates, avant même de lancer le jeux commencent par chercher un crack ou un nocd, savent ou le trouver, et on une version fonctionelle du jeux en moins de temps qu'il ne m'en faut pour installer le jeux.
C'est pas les premiers à perdre mon argent pour ce genre de conneries, et, hélas, j'ai bien peur que ce ne soient pas les derniers.
[^] # Re: Skype dans Télépathy
Posté par beagf (site web personnel) . En réponse au journal Skype en open-source : pétard mouillé ?. Évalué à 5.
Dans l'ensemble, je pense qu'on est d'accord pour considérer que, d'un point de vue strictement logique, "Je veux voir ma famille en audio/vidéo donc j'utilise Skype" et "Je veux n'utiliser que des logiciels propriétaires donc je n'utilise pas Skype", qu'il s'agisse de choix ou d'obligations, sont des formulations équivalentes (d'un point de vue logique, je le répète).
Et que la formulation "Je n'ai pas le choix, je suis obligé d'utiliser Skype, car je veux absolument voir ma famille en audio/vidéo" est équivalente à "Je n'ai pas le choix, je ne peux pas utiliser Skype, car je ne veux absolument pas de protocole propriétaire".
Ici, on est parfaitement d'accord, donc on part sur de bonnes bases. Je préfère les formulations du premier paragraphe car elles mettent bien en évidence l'ordre dans lequel sont fait les choix, sans ambigüités.
Autrement dit, étant donné que la logique est la même (des impératifs, ou choix, qui ont une conséquence, et l'utilisateur explique la conséquence en listant ses impératifs), comment se fait-il que la façon de le dire est typiquement différente?
Mon avis à moi est que la formulation "je n'ai pas le choix" serait utilisée afin de se débarrasser de la responsabilité dudit choix, donc liée à un sentiment de culpabilité: si ce n'est plus un choix, je n'ai pas de raisons de me sentir coupable de ses conséquences.
[...] alors je me garderai bien de présenter cette conclusion comme définitive: ça reste pour moi une hypothèse, faute de mieux.
Ici par contre, je serait plus mitigé. D'un point de vue construction des phrases, il me semble plus naturel de parler 'obligation pour quelque chose que l'on doit faire, plutôt que pour quelque chose que l'on ne peut pas faire.
Pour être un peut plus clair, si l'on reformule la phrase précédente pour utiliser le terme "obligé" on obtient : "Je n'ai pas le choix, je suis obligé de ne pas utiliser Skype, car je ne veux absolument pas de protocole propriétaire"
Le sens de la phrase à subtilement changé et maintenant, implicitement, il indique que à la base on aurait aimé utilisé skype mais que le choix de ne pas utiliser de protocole propriétaire nous empêche de la faire.
Pour moi, il faut bien voir que dans les deux sens, il y a des implications différentes. A la base on a toujours un utilisateurs de logiciel libres, et qui a donc une préférence pour ceux-ci.
- dans le premiers cas, il est ammener à faire un choix qui par la suite l'empêche d'utiliser des logiciel libres, ce choix va donc à l'encontre de son souhait d'utiliser des logiciel libres, il est donc bien perçu comme faire quelque chose de désagréable ;
- dans le deuxième cas, il fait un choix qui le conforte dans ses convictions : "ne pas utiliser de protocol fermé", donc ses conséquences : "ne pas utiliser skype", sont perçues comme naturelles.
On peut reformuler à nouveau la deuxième phrase en : "je souhaite voir ma famille en vision ; je choisit de ne pas utiliser de logiciels propriétaire, donc je n'ai pas le choix, je suis obliger d'abandonner l'idée de voir ma famille en visio et je vais me rabatre sur le téléphone." et dans ce cas on voit bien apparaitre l'aspect impératif.
Le truc, c'est qu'en général, on ne donne pas les prémices elle semblent toujours implicites, donc dans leurs discours :
- l'utilisateur de logiciels libres semble conforter dans sa position et n'a pas vraiment l'air d'être privé de quelque chose, ou bien passe pour un intégriste ou un extrémiste ;
- celui qui finit par utiliser un logiciel libre passe pour une pauvre victime ou pour quelqu'un qui veut que l'on s'apitoie sur son sort.
Mais dans les deux cas, je ne suis pas sur que ce soit volontaire. Je suis même persuadé que c'est le plus souvent dû aux ambigüités de notre belle langue...
[^] # Re: Skype dans Télépathy
Posté par beagf (site web personnel) . En réponse au journal Skype en open-source : pétard mouillé ?. Évalué à 3.
Est-ce que tu peut me donner un exemple d'une action qui serait obligatoire pour toi.
Si j'ai bien compris ce que tu entends par obligatoire, ce serait une action pour laquelle on ne peut pas choisir entre l'executer, ou ne pas l'executer. Et, dans tous les cas que je peut imaginer actuellement, la seule solution pour ne pas avoir ce choix, c'est de volontairement interdire un des deux.
Donc soit j'ai mal compris ce que tu entends par obligatoire, soit il y a un truc qui cloche. Dans tous les cas un exemple serait le bien venu.
Pour ce qui est de faire le malin avec une phrase compliqué, c'était juste pour détendre un peu l'atmosphère et sortir des attaques ridicules que l'on peut voir tout au long de cette page. En soit je trouve qu'un petit débat sur la notion de choix n'est pas inintéressant, bien au contraire, mais les discutions peuvent vite devenir stérile ici.
J'essaye de comprendre ton point de vue et de t'expliquer le mien, c'est tout, et un peu d'humour évite parfois les dérapage. Mais il me semble que j'ai loupé mon coup.
D'ailleur, si l'on regarde la page de wikipedia sur les sophismes, puisque tu en parlais à mon propos, on peut voir une liste des types d'arguments falacieux:
Si on prend ton deuxième paragraphe, même si tu met entre parenthèse "enfin pour moi", la dernière phrases est quand même relativement catégorique. On pourrais facilement le mettre dans la première catégorie des sophismes selon john stuart mill. Et c'est justement le fais que tu ne donne pas d'arguments, mais que tu te contente de dire "c'est comme ça" sans expliquer pourquoi, qui fait que je ne peut pas comprendre ton point de vue.
Et ta dernière phrase entre dans le cadre, à mon avis, des arguments falacieux de type "Argumentum ad hominem" un peu plus bas sur la même page.
Donc, soit on continue, et tu m'explique ton point de vue en argumentant et moi je fais l'effort d'essayer de comprendre, comme ça tout se passe bien et on finira peut-être un peu moins cons tous les deux. Soit tu dis clairement que tu ne veut pas discuter calmement du sujet en exposant des arguments plutôt qu'en faisant de la broderie et on arrête là cette discution pour pas perdre de temps.
[^] # Re: Skype dans Télépathy
Posté par beagf (site web personnel) . En réponse au journal Skype en open-source : pétard mouillé ?. Évalué à 3.
Une obligation résulte des contraintes qui se posent et qui réduisent les possibilités. Tu te trouves être obligé de choisir parmis ces possibilités uniquement, car les autres sont interdites du fait des contraintes.
Donc, pour un problème donné, tu commences par choisir les contraintes que tu acceptes, et ensuite tu regardes les possibilités qu'il te reste. Et dans le cas ou il n'y en à qu'une, tu es obligé de la choisir.
Dans la pratique c'est même bien plus complexe que cela et la chaine est souvent très longue. Les contraintes que tu est succeptible de choisir sont définies par les choix précédents et ainsi de suite.
Dans le cas présent, il faut bien voir que les deux choix sont fais l'un après l'autre et non-pas simultanément. Le premier à donc une influence sur le deuxième, une influence qui est même très forte car elle réduit le choix à une seule possibilité, donc une obligation.
Il aurrait aussi pus faire un choix global entre : "voir ma famille en vision -> utiliser skype" et "utiliser uniquement des LL -> ne pas voir ma faille en visio". Mais dans la pratique on fait toujours les choix séquentiellement en fonction de ses priorités, et ventuellement on les révises s'ils posent de trop fortes contraintes sur les choix suivants.
En quelques sortes, tu "t'obliges toi-même". Ça te paraît pas débile comme concept ? Pour moi, ça ne veut rien dire : ce n'est pas une "obligation", c'est un choix.
Si l'on suis ton raisonement jusqu'au bout, rien n'est obligatoire et je ne comprend même pas que l'on ai pus imaginer ce concept. D'après ce que tu dis, si quelqu'un t'oblige à faire quelque chose, tu as toujours le choix de refuser, non ?
Pour faire de la philo de comptoir, On peut même dire qu'une obligation ne peut venir que de soit. On fait le choix d'accepter de faire ce que nous demande une autre personne, plutôt que de faire le choix de refuser.
Donc fait le choix de s'obliger à faire ce qu'une autre personne pense nous obliger à faire sans nous laisser le choix ;-)
[^] # Re: Skype dans Télépathy
Posté par beagf (site web personnel) . En réponse au journal Skype en open-source : pétard mouillé ?. Évalué à 7.
Pour ce qui est des choix vous avez tous les deux raisons puisque vous ne parlez pas de la même chose ;-)
Il à fait le choix de voir sa famille quelque soit le logiciel qu'il doivent utiliser. <-- à ce moment là, il a le choix et il à fait son choix.
Seul skype marche correctement, donc il l'utilise. <-- à ce moment là il n'a pas le choix, pour pouvoir réaliser son premier choix, il est obligé d'utiliser skype.
Il faut bien distinguer les deux étapes, et on voit clairement qu'il à fait un choix : "sa famille avant tout" et que ce choix entraine une obligation "utiliser skype" car c'est le seul logiciel qui puisse satisfaire son premierchoix.
Donc au final, sur l'aspect réthorique de la discution, vous avez tous les deux raison vu que vous ne parlez pasde la même chose. Sur tout ce qu'il y a autour, je ne donnerais pas mon avis, je me contenterais de dire que je me suis bien marrer en lisant certains commentaires...
[^] # Re: Langage idéal...
Posté par beagf (site web personnel) . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 2.
Ce qui veut dire que si tu déclare : int tbl[3][5]; Le compilateur va produire du code pour allouer 15 emplacements sur la pile, et quand tu va indicer ton tableau, il va produire du code qui fait x * 5 + y. 5 est donc ici une constante qu'il peut stocker dans la pile, dans un registre ou dans l'instruction elle-même.
Quand tu fait : int tbl[X][Y]; Il va produire une allocation sur la pile qui commence par calculer la taille et ensuite réserve l'espace sur la pile. Pour l'indicage, c'est pareil sauf que cette fois ci la taille est forcement dans la pile ou dans un registre et ne peut pas être dans l'instruction elle-même.
Dans les deux cas, une fois la mémoire allouée sur la pile, il n'est plus possible de changer la taille du tableau; et ce n'est pas lié au C mais au principe même des allocation sur la pile.
Si l'on utilise la gestion interne des tableau par C99, on a un programme simple et lisible, aux prix de devoir tout mettre dans la même fonction.
Les solution alternative sont (ne pas oublier que l'on travail ici avec plusieurs tableaux) :
1/ continuer d'utiliser la gestion classique mais avec de multiple fonctions qui passe en plus des tableaux, leur dimension. On obtient des prototypes à rallonge et on augmente les risque d'erreurs au moment du passage de paramètres. Si l'on passe 4 tableaux à 2 dimension, ça fait 12 paramètres.
2/ on fait une grosse structure dans laquelle on passe le tout, ce qui nous donne :
typedef struct {
int *t1, x1, y1;
int *t2, x2, y2;
int *t3, x3, y3;
} state_t;
void etape1(state_t *st) {
...
st->t1[x * st->y1 + y] = val;
...
}
void algo(void) {
int x1 = ...;
....
int t1[...], t2[...], t3[...];
state_t st = {t1, x1, x1, t2, x2, x2, t3, x3, x3};
etape1(&st);
...
}
C'est un schéma très classique en C mais c'est tout sauf lisible. L'accès à un élément dans les sous-fonction est ien moins simple car le calcul que le compilo peut faire tout seul doit ici être fait de manière explicite.
La création et l'initialisation de la structure montre que l'on retrouve le même problème que lors du passage de paramètre: Une grosse liste de valeur à passer dans le bon ordre sans ce tromper.
3/ Faire une petite bibliothèque à côter pour gérer les tableaux. On note tout d'abord que même si elle est parfaite elle ne résout pas le problème. Dans le cas de l'algo de CRF, tu a 7 tableaux et 5 variables à passer aux différentes fonction, donc même si tes tableaux sont réduit à une structure, ça fait encore 13 variables donc tu est obligé de passer par une autre structure qui englobe le tout.
Ensuite, il devient difficile d'allouer cette structure dans la pile sans faire des acrobaties, imaginons la structure suivante :
typedef struct {
int *d, sx, sy;
} table_t;
Pour créer un tableau sur la pile il faut que tu ai quelquechose allouer sur la pile à mettre dans *d, ce qui te donne un code d'initialisation du genre :
int raw_d[x * y];
table_t tbl = {raw_d, x, y};
Ce qui n'est pas vraiment lisible, et tu as toujours le problème de l'indiçage.
Pour l'indiçage, une seule solution : une macro ce qui implique une syntaxe qui n'est plus celle des tableaux, donc moins lisible.
Pour la création des tables, tu ne peux pas utiliser directement une macro car la variable raw_d doit avoir un nom différent à chaque fois.
Donc la seule solution qui reste est de passer par une fonction qui fait un malloc et il ne faudra donc pas oublier de faire un free à la fin...
Comme tu peut le voir, c'est un truc que j'ai déjà pas mal potassé, et avant de faire des fonctions de cette taille je réfléchit toujours plusieurs fois et je cherche d'autre solutions.
Pour être honnête il y a une éventuelle solution au sujet de l'initialisation, tu peut faire une macro qui crée ta structure avec un "alloca" pour allouer les donnée sur la pile, mais ce n'est plus portable et ça ne résout pas le problème de l'indiçage qui est illisible.
Le problème ici n'est pas lié au langage mais au calcul que l'on souhaite faire. Ce calcul nécessite de construire de nombreux résultats intermédiaire qui sont utilisés tout au long des différentes étapes du calcul. Si l'on souhaite découper ce calcul en sous fonctions il est donc nécessaire de pouvoir faire passer un grand nombre de paramètre d'une fonction à l'autre sans que cela deviennent illisible.
Dans le cas du C ça demanderais deux modifications :
- pouvoir passer un tableaux dynamique à plusieurs dimensions dans une structure ;
- l'ajout d'une directive du style du "with" en pascal qui permet d'importer dans l'espace lexical local les nom d'une structure. ça permettrait de ce passer du "st->".
Cela ne résoudrais pas complètement le problème car il faudrait toujours construire et détruire cette structure, mais les sous-fonctions pourrait être lisibles.
L'aspect gestion de la mémoire était plus un élément anecdotique dans mon argumentaire au début, quand je listait les avantages que l'on a parfois faire de grosse fonctions ou gros blocs indentés.
[^] # Re: Langage idéal...
Posté par beagf (site web personnel) . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 5.
Pour l'algo sur les CRF je dois utiliser des tableaux à deux dimensions et plus dont la taille n'est pas connue à la compilation. Une des nouveautée cool du C99 est la tableau dynamiques qui me permmettent de faire :
int x = /* calcul de la taille X */;
int y = /* calcul de la taille Y */;
double tbl[x][y];
Le problème c'est que ce tableau ne peut pas se trouver dans une structure car la taille de la structure doit être connue à la compilation... De même, le passage de ce tableau en paramètre d'une fonction est embetant, soit je passe la taille des dimenssion en paramètre :
void mafonction(int x, int y, double tbl[x][y])
Ce qui devient vite les bordel si on a plusieurs tableau en paramètres. Soit ma fonction est capable de retrouver toute seule les dimension et donc je peut passer le tableau sous forme unidimentionelle, mais dans ce cas l'indicage devien chiant à mourir.
On est ici dans le cas ou une limitation du langage rajoute encore une couche au fait que le programme est bien plus lisible. La version splité en plusieurs fonctions se retrouve avoir des trucs du genre :
mdl->tbl[x * mdl->dimenx + y] = val;
ce qui est bien moins lible que juste
tbl[x][y] = val;
Mais si l'indicage est lié au langage, le fait de devoir aller chercher le tableaux dans une structure est lié à la décomposition. Pourquoi aller chercher un tableaux qui est juste une étape temporaire dans l'algo à l'interieur du structure qui donne l'impréssion d'avoir étée allouée quelque part ailleur ?
Bien sur, il est toujour possible d'avoir une structure "state" qui devient un fourtout pour toutes les variables à passer d'une fonction à l'autre. Mais dans ce cas pourquoi ce faire chier avec ce genre de truc :
void etape1(state *st) {...}
void etape2(state *st) {...}
void etape3(state *st) {...}
void etape4(state *st) {...}
void algo(void) {
state st;
etape1(&st);
etape2(&st);
etape3(&st);
etape4(&st);
}
alors que
void algo(void) {
/* etape1 */
...
/* etape2 */
...
/* etape3 */
...
/* etape4 */
...
}
est tout aussi clair, indique bien que les trois étape sont séquentielles, et n'oblige pas de faire une gymnastique avec une structure batarde ?
Et il ne faut pas oublier que ça simplifie le travail du compilateur. La sémantique et la portée des données et explicite et permet souvent des optimisations plus agréssive.
Perso, je pense toujours qu'il ne faut faire confiance ni aux dévelopeurs, ni au compilateur... donc je fais le code le plus simple, le plus lisible et le plus explicite possible, même si ça doit violer les style de codage.
Le compilo ne produira pas forcement du code plus rapide, mais dans tous les cas, il y a peut de chance qu'il soit plus lent.
Les autres dévellopeurs comprennent plus facilement mon code et on moins de chances de faire des conneries quand ils le modifient ou le maintiennent.
[^] # Re: Langage idéal...
Posté par beagf (site web personnel) . En réponse au journal Nimrod, ça se rapproche du langage idéal. Évalué à 8.
> Personnellement, un bloc qui fait 10 lignes je m'en méfie, qu'il y ai des {} ou non.
Pas forcément... Je me bat depuis longtemps contre les personnes qui considèrent ce genre de choses comme étant absolues, et qui veulent imposer des style de code sans réfléchir...
J'ai deux exemples de code ou j'ai fait des fonctions de 150 à 200 lignes et qui sont bien plus lisible et ou le risque de bug est bien plus faible que leur équivalent découpé en petites fonctions.
1/ L'implémentation de l'algo benson-pass-alive dans un jeu de go : Cet algo nécéssite 6 tableaux temporaires et tout un tas de petites variables qui sont utilisés tout aux long de l'algo.
Il se découpe facilement en 5 ou 6 étapes: calcul des deux premiers tableaux, premier passage sur le goban, mise à jour des deux suivant, itération de l'algo...
La version en une fonction déclare toutes les donnée au début de la fonction, les tableaux étant internes à l'algo se trouvent alloués dans la pile donc les perfs sont meilleures et il n'y a pas à se préoccuper de les désallouer, c'est fait automatiquement à la sortie de la fonction. Les variables gardent le même nom tout au long de l'algo.
Chaque étape est bien séparée des suivantes par un court commentaire qui indique à quelle étape on en est, ce qui permet de se référer à la description de l'algo dans un gros commentaire avant le début de la fonction.
Bref ça ce lit très bien et le code est facilement compréhensible.
La version qui découpe les différentes étapes dans différentes fonction est par contre beaucoup moin lisible, chaque fonction prend une dizaine de paramètres l'algo en lui même se retrouve explosé, de manière logique bien sur mais c'est plus dur à suivre.
Chaque fonction n'est appellée qu'une fois donc il n'y a pas de problème pour inliner le code mais ça reste moche.
Le grand nombre de paramètre des fonctions fait qu'il est facile de ce tromper.
Je vais pas détailler mais c'est beaucoup moins pratique et bien moins facile de comprendre ce qui ce passe vraiment.
Bien sur ont peut aussi faire une structure ou un objet qui contienne toutes les variables et tableaux temporaire, mais dans ce cas la soit on a langage ou il faut gérer explicitement la mémoire et il faut faire une allocation qui coute cher et ne pas oublier le free. Si on a un langage ou la memoire est gérée automatiquement on ne sait plus vraiment ce qui ce passe ni quel est l'impact de l'allocation.
2/ Le même genre de problème dans le calcul de l'espérance pour l'apprentissage d'un modele CRF. La aussi on a besoin de pas mal de tableaux intermédiaires qui sont chiant à faire passer d'une fonction à une autre alors que de simples variables locales sont tellement plus simple et regroupe toutes les étapes de l'algo au même endroit dans l'ordre ou elle sont éffectuées de manière logique et lisible.
Donc même si de manière générale, il faut éviter les fonctions ou indentations longues, ce n'est pas une véritée absolue et parfois un code peut être écrit de manière bien plus sûre, lisible et maintenable et violant les style de code.
Mon code pour l'éxemple deux est une fonction 175 lignes contenant notament une boucle for de 103 lignes. Une autre version du code qui est distribuée sur 5 fonctions fait au total 286 lignes.
Pour avoir discuté avec 3 personne qui ont du utiliser les deux versions, toutes on admis que la première est bien plus compréhensible, et pour l'une d'elle ce fut vraiment très difficile à admettre...
La seule chose avec ce genre de code c'est qu'il faut être très discipliné, avoir des noms pour toutes les variables qui soient parfaitement explicite et cohérent bien séparer toutes les étapes et avoir un gros pavé de commentaire avant la fonction expliquant ce qu'elle fait et comment elle le fait.
Et bien sûr il ne faut utiliser ce genre de chose que lorsque c'est nécéssaire.
[^] # Re: L'intérêt?
Posté par beagf (site web personnel) . En réponse au journal Portage de Qt sur iPhone. Évalué à 2.
Pour ce qui est de l'IHM et du XML, là encore, c'est possible de tout créer à la main, mais toujours pas de doc. Et pour ce qui est du constructeur d'interface, c'est pas encore au point. La méthode recomandée par Google c'est l'écriture directe de XML, et c'est ce qui est recomandé par tous les bouquins que j'ai pus trouver sur Android. Tous les commentaires que j'ai pus voir sur le constructeur d'interfaces était pour le critiquer ou parler de ses bugs.
Je ne connais pas les autres plateformes mobiles, donc je ne peut pas comparer les SDKs, j'ai éssayé Android car je viens de chaanger de portable et le miens est sous cete plateforme, mais je reste super mitigé. C'est peut-être une super plateforme pour certains, mais en tout cas pour moi, ça reste un truc lourding et bordelique à souhaits.
[^] # Re: L'intérêt?
Posté par beagf (site web personnel) . En réponse au journal Portage de Qt sur iPhone. Évalué à 4.
Par contre la ces personel et donc non, je ne vais pas me forcer a programmer dans un langage que je ne peut pas blairer avec une IDE que je trouve inutilisable.
Les dévelopement que je fait sur mon temps personel, je les fais pour mon plaisir, donc oui, j'ai abandonné cette plateforme en grande partie à cause de java, et non ce n'est pas une pale excuse pour de la flemme.
J'ai plein de projet qui me branchent et pas suffisament de temps pour tous, il me semble donc normal de choisir ceux qui me plaisent le plus.
[^] # Re: L'intérêt?
Posté par beagf (site web personnel) . En réponse au journal Portage de Qt sur iPhone. Évalué à 6.
C'est assez dur à décrire, mais en gros on se retrouve avoir un max de fichiers en bordel qui contiennent pas grand chose ou des infos sans vraiment de rapport enrtre elles, des fichiers générés automatiquement sans que l'on sache vraiment ce qu'il y a dedans, n'y quand ils ont été mis-à-jour, mais qu'il faut quand même réussir à utiliser d'une manière ou d'une autre.
Les widgets proposé sont plutôt pas mal, mais pour les utiliser il faut surcharger des méthodes aux noms parfois obscures avec des prototypes à ralonge. Et utiliser l'une d'elles implique parfois de surcharger telle autre sans que ce soit vraiment explicite.
Si on met de côter le fait que je trouve le java particulièrement illisible et eclipse imbitable ; avec un peu de patience il doit pas être trop difficile de ce mettre dans le SDK et de s'en sortir, si on y consacre le temps qu'il faut.
Pour d'en rajouter une couche, j'ai tendance à être alergique au XML, donc on peut dire que j'avais pas beaucoup de chance d'aprécier le SDK... J'asume, et je rééssayerais surement un de ces jours.
Histoire de ne pas être totalement négatif, si quelqu'un connait un bon tutoriel sur le developpement pour android sans passer par Eclipse, et la création des interface à l'aide de code sans les fichiers XML, je suis preneur.
PS: pour pas que le troll soit trop poilu, je tiens quand même à préciser que mes critiques à l'encontre de java ne sont pas du tout liées à des histoire de performance ou autre, mais bien à sa syntaxe et à des critères d'esthétique et d'ergonomie, qui sont des aspects relativement subjectif j'en conviens.
[^] # Re: Comparaison avec GCC
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de LLVM 2.6. Évalué à 1.
Je ne connaissait pas ce papier, j'ai regardé mais pas encore détaillé. En effet il y a des similaritées dans le sens ou c'est aussi une approche d'optimisation coordonées par coordonées, mais leur approche est stochastique. Il est maintenant dans ma liste de papiers à étudier en détails.
Pour ce qui est du hashing des features, la réponse est non. Le hashing à deux avantages :
-réduire la taille du modèle final en regroupant les features en paquets plus ou moins aléatoire, dans notre cas la régularization L1 permet déjà de réduire la taille du modèle en supprimant les features qui ne sont pas informative, donc au moins théoriquement c'est plus éfficace ;
- réduire la taille du modèle à l'apprentissage, et donc accélérer l'apprentissage. Ça pourrait accélérer l'apprentissage de notre modèle, mais ça peut aurrait des interaction avec la norme L1. Ces interaction ne sont pas forcément génantes en pratique mais il faudrait faire des expérimentation pour en être sur. Pour l'instant en tout cas, on reste sur une gestion classique pour pouvoir évaluer objectivement l'algo.
De plus le hashing n'accélère pas tant que ça l'apprentissage, aussi bien le mapping feature->id que la mise à jour des poids des features sont néligeables par rapport au temps passé au calcule des espérance pour chaque séquences (qui représente en gros 92% du temps d'aprentisage dans notre algo) et il à l'inconvénient que ça fait encore un paramètre de plus à regler. (le nombre de features final)
Il a l'avantage par contre d'être bien plus simple à coder.
J'ai noté ton mail, je te préviens dès que le code est libre.
[^] # Re: L'intérêt?
Posté par beagf (site web personnel) . En réponse au journal Portage de Qt sur iPhone. Évalué à 1.
Et, autant sur un ordi classique, ce qui me branche c'est la partie purement algorithmique d'un programe. Autant sur Android, j'avais envie de faire des éssais sur les aspects ergonomiques des interface que l'on peut faire sur ces petits machins.
Donc le NDK, c'est très bien pour coder le coeur d'un programme dont l'interface reste en java tout moche et bien bordelique. Donc pas pour moi...
[^] # Re: L'intérêt?
Posté par beagf (site web personnel) . En réponse au journal Portage de Qt sur iPhone. Évalué à 2.
[^] # Re: Comparaison avec GCC
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de LLVM 2.6. Évalué à 4.
Donc si ce modèle suffit il fait bien le boulot, mais ces pas notre cas... Et le problème c'est justement qu'il est très lié à son modèle ce qui rend difficile de le modifier pour en faire autre chose.
Mon objectif était d'implémenter un nouvel algorithme d'optimisation des CRFs qui optimise le modèle coordonées par coordonées. CRFSuite implémente le gradient classique à l'aide de LBFGS qui optimise tout le modèle à chaque itérations avec toutes les séquences d'entrées ainsi qui le SGD qui optimise tout le modèle avec une seule séquence. Notre approche est d'optimiser une seule coordonée à la fois mais avec toutes les séquence ou cette coordonée est active. On a soumit un papier sur l'algorithme, si le sujet t'intéresse tu peut trouver un preprint ici http://oniros.org/papers/sokolovska09jstsp.pdf .
Il optimise aussi les CRF linéaire mais à l'inverse de CRFSuite il permet d'utiliser des features bigrammes aussi riches que les features unigrammes, ce qui permet de construire des modèles bien plus performants. (mais aussi bien plus long à entrainer...)
La version du programme utilisée quand on à écrit le papier n'utilisait pas le sse, donc les comparaison de vitesse avec CRF++ et CRFsgd sont équitable.
Pour l'instant je travail au nettoyage du code car si l'algorithme en lui même en plutôt propre, c'est pas vraiment le cas de la partie lecture des données et génération des features... J'espère pouvoir le publier bientôt sous licence libre, je ferais un journal au moment ou ce sera près, mais s'il y en à que ça intéresse, n'hésitez pas à me contacter directement.
[^] # Re: Comparaison avec GCC
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de LLVM 2.6. Évalué à 4.
C'est même ce problème qui fait que j'ai codé à la fois une version sse2 et une version classique, le sse2 à des registres vectoriels sur 64bits par éléments. Le programme normal choisit, en fonction des conditions, s'il peut utiliser la version sse2 ou s'il doit se rabatre sur la version classique car il risque d'avoir des problèmes.
Qu'il soit compilé avec GCC ou CLang, le programme donne exactement le même résultat au bit près, donc à priori ils font bien le même calcul. Un accord aussi parfait entre les deux m'a même étonné... la preuve que le standard IEEE sur les flotants est pas mal foutu.
Pour ce qui est du code ASM, j'ai beaucop exploré celui de la version sse2 car 95% des séquences sont calculées avec, donc celui là j'ai passé pas mal de temps à l'optimiser, et donc à comprendre le code que me génerait chacun des compilos en fonction de ce que je leur donnait ; par contre la version classique représente trop peu du temps d'éxecution pour que ça vaille le coup de s'en préoccuper. J'ai juste vérifié que les deux compilos utilisait bien la pile flottante classique et pas le sse pour être sur mais c'est tout.
C'est un gros casse tête ces problèmes de précision et à mon avis ces ce qui limite l'utilisation des instruction SIMD dans le calcul scientifique. Avec 80bits de précision, on réussit souvent à s'en sortir sans utilisé de bibliothèque spécialisées. Avec 64 bits c'est un vrai casse-tête.
[^] # Re: Comparaison avec GCC
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de LLVM 2.6. Évalué à 8.
Sur mon programme de Go en C99 pur qui contient beaucoup de manipulation de tableaux d'entiers, CLang est environ 20% plus rapide.
Sur mes programme de calcul scientifique (apprentissage de modèle CRF) avec beaucoup de caculs en flotants double précision. La version qui utilise du code vectoriséen sse2 (intrinsics plus opération sur des __m128d du genre a + b * c) est 24% plus rapide avec CLang ; par contre la version en C99 pur sans utiliser sse2 (juste i686) est 29% plus rapide avec GCC.
Il semble que CLang à plus de mal avec l'unitée de calcul flotant des x86 mais s'en sort très bien quand on lui permet d'utiliser les sse.
Au niveau temps de compilation, je peut pas vraiment dire, même si ce sont des programme très complexes, ils ne dépassent pas les quelques miliers de lignes de code et sont donc très rapide à compiler même avec toutes les options au max.
J'ai dans ma TODO list de pousser un peu plus loin pour voir ce qui fait vraiment la différence ; mais ça reste une entrée de plus dans la liste.. donc je ne sais pas quand j'en aurais vraiment le temps.
Ce qu'il faut bien voir avec LLVM+CLang c'est pas vraiment les perfs actuelles mais surtout le fait que c'est est framework propre et moderne pour la compilation qui est très agréable à utiliser. Donc même si actuellement il n'est pas toujours plus rapide que GCC, il à de bonne chances de représenter l'avenir.
Implémenter de nouvelle passe d'optimisation dans LLVM est infiniment plus facile et plus agréable que dans GCC ; il est donc probable que, progressivement, les nouvelles techniques d'optimisation soient d'abord intégrées dans LLVM avant GCC.
[^] # Re: Craintes
Posté par beagf (site web personnel) . En réponse au journal La mort d'un troll : GCC supportera les plugins. Évalué à 8.
Il faut bien ce mettre dans le crane que ce sont deux licences différentes et que chacun choisit celle qu'il veut. Et le fait de choisir l'une ou l'autre n'implique pas que tu soit un gentil ou un connard.
[^] # Re: Craintes
Posté par beagf (site web personnel) . En réponse au journal La mort d'un troll : GCC supportera les plugins. Évalué à 8.
La GPL le force à partager ses modification avec toi même s'il n'en a pas envie. L'idée de la BSD c'est que techniquement la meilleure solution c'est de partager donc pas besoin de le forcer à partager, il finira bien par le faire, ou alors ta solution ouverte attirera d'autre personnes qui ferons la même chose en mieux.
En gros (attention passage à fort caractère trollogène) :
- La GPL c'est "rejoin ma religion et tu profiteras de mon savoir" ;
- La BSD c'est "profite de mon savoir, tu finiras bien par rejoindre ma religion".
J'ai toujours choisit la licence BSD pour mon code tout simplement car je m'en fout que quelqu'un éssaye de faire du proprio avec, par contre si un mec dans une boite pense que mon code peut lui servir et l'intègre dans son logiciel avec quelques améliorations, peut-être qu'il m'enverra un patch ; et ça c'est pas possible avec la GPL.
Et je reste convaincu qu'un jour il n'y aura plus besoin de licence sur les code source car il ne sera même pas envisageable qu'il ne soit pas partageable ou que l'on puisse garder des modifs pour soit. C'est mon côté idéaliste...
Mais en matière de licences, chacun ses goûts.
PS: Pour alimenter les trolls, je rajouterais que j'ai jamais été fichu de comprendre toute la GPL tellement elle est imbitable (comme à peu près tous les document juridiques) donc je préfère mettre mon code sous une licence que je comprend et que me utilisateurs comprendrons surement eux aussi...
[^] # Re: Craintes
Posté par beagf (site web personnel) . En réponse au journal La mort d'un troll : GCC supportera les plugins. Évalué à 9.
La licence BSD mise sur le fait que techniquement le code ouvert est superieur au code fermer car plus il y a de personnes à regarder, vérifier et contribuer à un code meilleur il sera. Donc il n'y a pas besoin d'utiliser une licence complexe pour assurer l'avenir, technique ceux qui ne jouent pas le jeu finiront par perdre.
Au contraire la GPL c'est n'avoir aucune confiance en l'avenir et être persuader qu'une boite qui reprend le code pour en faire quelque chose de fermé fera mieux que ceux qui y contribuent de manière ouverte, et donc on préfère metre une licence qui empêche cette possibilité.
Mon point de vue c'est que je n'ai pas envie de faire de la politique quand je donne du code, mais juste partager de la technique, donc mon code je le publie sous licence BSD ou équivalente.
[^] # Re: Attention au français
Posté par beagf (site web personnel) . En réponse à la dépêche Apple libère Grand Central Dispatch. Évalué à 3.
Ça me fait penser à un passage du livre «L'élégance du hérisson» de Muriel Barbery :
«Le chat dort.»
La lecture de cette petite phrase anodine n'a éveillé en vous aucun sentiment de douleur, aucun flamboiement de souffrance ? C'est légitime.
Maintenant :
«Le chat, dort.»
Je répète, pour qu'aucune ambiguïté ne demeure :
«Le chat virgule dort.»
D'un côté, nous avons ce prodigieux usage de la virgule qui, prenant des libertés avec la langue parce que d'ordinaire on n'en place point avant une conjonction de coordination, en magnifie la forme :
«M'a-t-on fait assez de reproches, et pour la guerre, et pour la paix...»
Et de l'autre, nous avons les bavouilleries sur vélin de Sabine Pallières transperçant la phrase d'une virgule devenue poignard.
[^] # Re: Script shell
Posté par beagf (site web personnel) . En réponse au journal Init-ng est encore vivant !. Évalué à 2.
Tu te retrouve à dépendre d'un logiciel compatible avec les scripts init-ng au lieu de dépendre d'un système ayant un shell compatible bourne.
Bien sûr, pour l'instant il y a plus de réimplémentations du bourne shell que de init-ng, mais est-ce une preuve que techniquement c'est mieux ?
[^] # Re: Intéressant
Posté par beagf (site web personnel) . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 5.
Pour corriger ce que dit l'auteru du journal, on ne peut pas vraiment dire que llvm soit encore vraiment expérimental. Il est relativement proche de ce que 'lon pourrait appeller un programme stable, et encore plus dans le cas de la 2.6 qui va bientot sortir, le freeze c'est produit il y a quelques jours.
Le code intermédiaire devrait être parfaitement compatible dans le sens ou un code actuel devrait rester executable par toutes les futures version de llvm, ce qui n'empeche pas à l'avenir d'ajouter de nouvelles instruction si celles-ci sont nécéssaire.
LLVM est même suffisament stable pour que Apple ait choisit de le mettre au coeur de son système, et contribu pas mal au passage. LLVM est une des brique éssentielle du fameux OpenCL.
Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
Vu le projet il y a relativement peut de chance que le dévellopement s'arrete, mais même si c'était le cas, c'est du logiciel libre et il est possible de reprendre le dev.
Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant
LLVM seul ne supporte absolument rien ;-)
C'est juste la spécification d'un code intermédiaire et tout un tas de bibliothèques et outils pour le manipuler et notament le copiler en code natif. Il y a pas mal de projet de compilateurs qui produisent ce code intermédiaire au lieu de produire directement du code natif.
C'est le cas par exemple de clang qui est un copilateur destiner à compiler du C ainsi que d'autre langage dérivés. Et pour CLang, en effet, il supporte actuellement très bien le C et produit du code très performant. L'objective-C est relativeent bien supporté, je sais pas le staus exacte mais là aussi c'est un truc ou apple contribue pas mal. Par contre pour le C++, pour l'instant c'est encore très expérimental et de nombreuse choses ne sont pas implémentée.
Par contre il existe aussi llvm-gcc qui est un bacend pour gcc. C'est-à-dire que c'est une modification de gcc qui lui permet de produire du code llvm au lieu de code pour un processeur. Donc ça permet d'avoir un copilateur qui supporte éxactement les même langages que gcc.
Et il y a différents autres compilos disponibles, même parfois pour des langages auquels on ne penserais as du style un compilateur pour lua.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non?
Comme tu le dis après, L'objectif de llvm c'est quand même de produire du code très performant, et les perfs du code interprété sont quand même pas térrible à côter de celle du binnaire. Et vu le coût du JIT autant ne pas s'en priver.
Et un dernier petit point pour l'auteur du journal. L'argument de ca prend moins de place est loin d'être pertinent, dans la grosse majoritée des pacquet, à mon avis, ce qui prend de la place c'est pas les binnaires mais les donnés. De plus les mesures sont à faire sur le code une foi compressé car à tous les formats de paquets que je connais compressent le tout.
Avant de penser à des optimisation sur la taille du code, il vaudrais mieux faire quelques stat pour savoir s'il y a quelque chose à gagner.
Voilà, j'éspère avoir clarifier quelques points sur llvm et le reste.
[^] # Re: Comparaison
Posté par beagf (site web personnel) . En réponse au journal Yum vs Apt. Évalué à 10.
C'est pénible.
En même temps c'est ton problème si tu utilise encore des outils obsolètes. Le gestionnaire de paquets officiel est aptitude et de ce que je comprend, en plus d'être celui conseillé par la distrib, corespondrait mieux à ce que tu aime.
Mais les gens n'aiment pas lire les release notes...