[ Précédent :: 1 2 3 4 5 6 7 :: Suivant ]
Re: Lisibilité et produit de matrices
Tout à fait d'accord !
D'ailleurs, je trouve rigolo de constater que ce qui rend son code beaucoup plus lisible que le mien là haut, c'est qu'il colle plus aux méthodes usuelles en mathématique; par exemple, la fonction sigma qui me paraît au premier abord le mélange obscur d'un init et d'un fold_left, est en fait plus naturelle à utiliser dans ce contexte que les init et les fold_left qui vont bien, parce qu'elle reflète l'écriture mathématique.
Ma deuxième erreur a été de ne pas extraire le principe du double init : lui donner un nom (ici init_matrix) aide indéniablement à la compréhension.
[ Répondre ]
Re: Dommage...
À mon humble avis, si la syntaxe était vraiment ce qui change la donne en programmation, ça se saurait...
Pour ma part, je trouve la syntaxe du Basic repoussante de loin, et pourtant, ce sont des langages assez utilisés. Avec Perl c'est encore plus vrai.
La syntaxe, avec un peu d'habitude ça s'apprivoise, et après il n'y a plus de problème.
Le problème à mon avis ce n'est pas OCaml ou Haskell ou Ruby ou je ne sais quel langage à la syntaxe "trop différente", c'est l'habitude qu'on pris les programmeurs C/C++/PHP/Java de n'utiliser essentiellement qu'une seule syntaxe (avec des variations), au point de leur faire pousser des cris parce qu'il y a un _ dans le langage !
Si le plus dur quand on apprend la programmation fonctionnelle, c'était de s'habituer à voir des _ dans les fichiers sources, ça se saurait....
Par ailleurs, pour info, le @@ n'existe pas dans la librairie standard OCaml, c'est juste un truc défini ici pour la composition de fonctions. Si tu as une autre suggestion plus mainstream-friendly, sachant que ° n'est pas accepté, ça peut toujours se changer.
[ Répondre ]
Re: Dommage...
Et oui en effet il n'y aura JAMAIS de surcharge des opérateurs (oui, je sais, il ne faut jamais dire jamais) parce que sinon on ne permet pas l'inférence de type, et le polymorphisme paramétrique. J'ai étudié dans un cours l'algorithme de typage, et il apparaît clairement que la surcharge ne permettrait plus de résoudre le système des contraintes, et de typer une expression.
C'est marrant parce que justement pour l'occasion de la 3.10 je suis allé farfouiller un peu sur le site de l'INRIA, et sur la page perso du type qui a refait camlp4 on trouve :
http://gallium.inria.fr/~pouillar/talks/overloading-searchin(...)
Par ailleurs, on peut aussi parler du Haskell qui a des moyens de surcharge assez poussés, et qui conserve bon an mal an une partie de son inférence de type. Par ailleurs, ils ont plein de trucs encore plus affreux comme le polymorphisme de second ordre et compagnie (mais il me semble qu'on l'a aussi en OCaml à quelques endroits, je l'ai juste jamais utilisé) qui doivent bien mettre à mal l'inférence des types. Mais elle a survécu : elle est pas totale, mais elle a survécu.
[ Répondre ]
Re: Beurk, un langage impératif
Turing complete ça veut dire qu'on peut faire les même chose dedans, mais pas forcément avec la même efficacité.
Brainfuck est Turing complete (me semble-t-il), et pourtant il sera moins efficace algorithmiquement (par exemple mettre un nombre N dans une case mémoire a une complexité plus grande que O(1), ce qui n'est pas le cas avec des nombres pas trop grands dans la plupart des autres langages).
Le papier qui indique une borne inférieure de complexité moins intéressante avec un algo fonctionnel pur qu'un algo impératif tient donc toujours.
Évidemment, ça ne concerne pas Haskell, qui n'est pas un langage fonctionnel pur, comme tu dis :p
(par contre je suis pas sûr que le hack de l'UnsafePerformIO suffise pour échapper à la preuve de l'autre, mais on sait jamais ce qu'on peut faire avec ces trucs tordus...)
[ Répondre ]
Re: Beurk, un langage impératif
On peut aussi, pour faire plus sérieux, citer un papier ( http://citeseer.ist.psu.edu/pippenger96pure.html ) où il est montré qu'il existe (au moins) un algorithme pour lequel un algo fonctionnel pur est au mieux en O(n log n), alors qu'il existe une version impérative en O(n).
(après, ça n'enlève rien au mérite du Haskell, ni aux langages fonctionnels purs, mais là il faut défendre OCaml, alors tous les coups sont permis, voilà tout)
[ Répondre ]
Re: Beurk, un langage impératif
http://haskell.org/ghc/docs/latest/html/libraries/base/Syste(...)
import System.IO.Unsafe
import Data.IORef
cast :: a -> b
cast x = unsafePerformIO $ writeIORef r x >> readIORef r
..........where r = unsafePerformIO $ newIORef $ error "pwned le puriste"
[ Répondre ]
Re: Dommage...
écrire un produit de matrice de façon fonctionnelle, c'est ridicule
open Array
let ( @@ ) f g x = f (g x)
let produit mata matb =
....let coeff li col =
........fold_left ( + ) 0
............(init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)))
....in
....init (length mata) (init (try length matb.(0) with _ -> 0) @@ coeff)
100% tableaux non mutables (non mutés, en tout cas).
[ Répondre ]
Re: bloups
Je suis pas d'accord, et je trouve ça super douteux.
Le libre pour moi c'est de la connaissance. Alors que ça tourne sur X systèmes libres c'est très bien, mais si on sait pas comment ça marche, ça sera toujours moins bien qu'un truc codé avec des machins douteux, mais ouvert, et modifiable, etc...
En plus C#/.NET c'est Microsoft, c'est le démon, bien sûr, mais ça a peut-être des qualités aussi, c'est pas comme si tu nous parlait d'un programme dans un vieux Visual Basic ou autres. Il y a sûrement de la connaissance dedans.
Franchement, je comprend pas trop ce qui peut pousser quelqu'un à trouver un programme closed source portable plus libre qu'un programme open source.
[ Répondre ]
Re: Ruby
Dans le cas d'un parcour d'un tableau (une liste, un vecteur, ...) on ne devrait jamais à mon sens utiliser de for mais utiliser des constructions du type
montab.each()
Une liste, c'est un tableau ? hérétique ! :p
Je suis pas vraiment convaincu par l'utilisation des each() à tout vent :
- quand on une liste, on fait souvent des manipulations un peu complexes (récursives, toussa), qui sont bien représentées par les map, fold_left et fold_right, mais pas vraiment par each. Évidemment, il y a toujours des cas d'itération simple, mais je pense qu'ils sont largement minoritaires et que ça ne vaut pas le coup de mettre l'emphase dessus
- quand on a un tableau, on fait plus que juste le parcourir linéairement (sinon, on utiliserait une liste) : on a souvent besoin de l'indice, et on se retrouve souvent à modifier la case en question. Donc ça demande déjà pour avoir un truc un peu utile de passer deux argument au each : l'indice et la valeur. À ce moment là, le each est déjà assez lourd pour qu'un for soit syntaxiquement au moins aussi agréable
Par exemple :
tab.each { |i,v| tab[i] <- v + tab[(i + 1) % len] }
for i from 0 to len - 1 do { tab[i] <- tab[i] + tab[(i+1) % len] }
Dans ce cas très simple, je suis pas convaincu que le each soit plus simple à écrire et à lire (j'ai pris une syntaxe pseudo-ruby au pif, mais ça ne change pas grand chose je pense), il n'apporte pas grand chose, à part une gestion implicite des indices (c'est bien) et un paramètre supplémentaire contenant la valeur de la case actuelle (je suis pas convaincu que le rapport réflexion_supplémentaire/gain_lisibilité soit intéressant).
L'avantage principal des itérateurs, si j'ai bien compris, c'est qu'on peut les utiliser de manière plus ou moins transparente sur plusieurs type de données différent (tableaux, tables de hachage, listes à la rigueur). Dans l'idée c'est bien, mais en pratique je trouve que les structures de données que l'on manipule en même temps sont suffisamment différentes pour ne pas avoir besoin de méthodes de manipulations communes : si on commence à implémenter each sur un arbre binaire, c'est qu'il y a un petit problème de conception en général.
Dans le cas d'itération (et donc là il y a une certaine disymétrie), écrire 1.to(10) ne me choque pas vraiment mais on peut très bien remplacer par une écriture du type : (1..10).each
L'asymétrie n'est pas tant syntaxique que sémantique (hum, je connais pas assez la sémantique pour parler de ça, mais là je pense que c'est vrai ^^) : dans son exemple l'objet auquel on envoie un message, c'est 1, et 10 n'est qu'un argument. C'est fondamentalement asymétrique.
À mon avis, l'écriture (1..10).each bloc suggère plus une fonction curryfiée où (each 1 10) est une fonction prenant un bloc et lui appliquant l'itération, qu'un appel objet.
[ Répondre ]
Re: Ruby
Lisaac*. Tout y est objet, comme en ruby, même le booléen.
En lisaac, le for est un message de INTEGER
1.to 10 do { i.print;};
Justement, je trouve pas ça si génial que ça moi. Avec ta méthode, du point de vue du sens, le for est un truc qui concerne la première borne : c'est sa méthode qu'on utilise, et à laquelle on donne la deuxième borne et le bloc en arguments (c'est pas forcément la bonne terminologie, mais c'est pas grave).
Moi, je trouve ça laid. Je vois pas pourquoi dans un for, il y aurait une asymétrie entre la première et la deuxième borne.
Dans l'idée, je trouve beaucoup plus joli d'exprimer le for comme une fonction qui dépend des bornes et du bloc :
let for debut fin bloc = ...
En Ocaml/Haskell par exemple, on peut faire ça pour pas cher. Si on ne fait pas d'effet de bords, le "for" n'a à priori pas grand sens, mais imaginons que le for fonctionnel renvoie la liste des valeurs générées par le bloc à chaque itération :
let rec for low up bloc =
if low = up then []
else bloc low :: for (low + 1) up bloc
En Haskell, si on crée un alias de for nommé "to", on peut même faire des contorsions syntaxique amusantes, par exemple
1 `to` 10 $ bloc
(On peut faire pareil en OCaml si on donne un nom d'opérateur à for : 1 >> 10 $ bloc, par exemple)
Je pense que cette asymétrie forcée est un des grands problèmes de l'objet.
[ Répondre ]
Re: Ruby
prend le cas du lambda calcul. si tu dit que
f (x) = x + x (x etant un reel par exemple)
ce n'ai pas pour faire quelque test que ce soit, mais juste pour definir la fonction f (de type R -> R ).
Oui mais justement, en maths "f(x) = x + x" c'est pas une déclaration de fonction, c'est pas grand chose. Pour déclarer une fonction on fait ça proprement (Soit f : x -> x + x) ou avec une équation (Soit f telle que pour tout x, f(x) = x + x), mais on balance jamais "f(x) = x + x", c'est pas rigoureux.
Heu, je serais plutot en desaccord, ou je ne connais pas de langage retournant plusieur valeur. Peux tu m'eclairer la dessus car en reflechissant a quoi cela pourrait ressembler, je ne m'en fait pas du tout une idée possitive.
Il parle sans doute des tuples (let proches x = (x + 1, x - 1)) qui permettent de renvoyer des aggrégats d'objets de types potentiellement distincts, et alors ce n'est pas vraiment "plusieurs valeurs en même temps", c'est juste une valeur qui en contient plusieurs autres, et qui est légère (syntaxiquement) à manipuler (pas comme un struct ou un tableau ou...).
[ Répondre ]
Re: Python ...
en haskell, en utilisant des compréhensions de liste :
[o3 | o2 <- listeo1 o1, o3 <- listeo3 o2, predicat o3]
On peut faire la même chose en ocaml, mais il n'y a pas de sucre syntaxique pour ça (bien qu'il soit possible de le rajouter avec une extension camlp4) :
filter predicat (concat (map liste3 (liste2 objet1)))
Dans les deux cas, on considère liste2 et liste3 comme des fonctions qui renvoient les listes quand tu leur donne l'objet.
[ Répondre ]
Re: Site vachement bien foutu
Mouaif... Ça est et ça va être de moins en moins vrai. Si une distribution sort sans driver proprio ou mp3, ça fait un "scandale". Les distributions 100 % libre sont rares et leur succès assez limité.
Je crois que t'exagères un peu, là. Regarde, sur un bureau linux moyen, combien des logiciels sont libres ? Je dirais 99% au feeling, après ça dépend de si tu prends en compte leur importance (par exemple un driver graphique ça compte pour pas beaucoup de logiciels mais c'est assez important), mais dans tous les cas ça reste largement au dessus des 95%
Et sur Windows ? J'ai du utiliser un Windows récemment, et j'ai eu besoin de deux logiciels : un graveur de CDs (un truc qui sache graver une iso bootable de distribution linux), et un lecteur de PDF. J'ai cherché pendant un temps non négligeable à chaque fois, mais j'ai rien trouvé.
Là-bas (du côté obscur, quoi), c'est le monde du Shareware avec version d'évaluation, voire du freeware.
Alors non, tu es peut-être très en colère à cause des drivers proprios et du mp3 inclus dans les distros, mais les distributions Linux/BSD et cie restent un paradis pour les amateurs de logiciel libre.
Je ne dis pas que ça rend les pratiques douteuses tolérables, les drivers proprios c'est mal et il faut les combattre, mais il ne faut pas faire dans le pessimisme à outrance non plus.
[ Répondre ]
Re: Logiciels maisons vs logiciels multi-plateforme
Il me semble que ni Gimp ni Gaim ne sont des logiciels gnomes : même sans aller jusqu'à "il n'y a pas de dépendances gnome donc c'est pas gnome", il me semble que gimp est antérieur à gnome, et aucun de ces deux logiciels ne revendique un lien avec ce bureau sur leur site web.
[ Répondre ]
lui proposer ?
Pourquoi ne pas contacter l'auteur du bench pour lui soumettre ton hypothèse ? Rien n'indique le changement serait significatif, mais ça vaudrait le coup d'essayer.
Ta remarque paraît pertinente, et jusqu'à présent il s'est montré tout à fait prêt à tester d'autres configurations pour améliorer son benchmark. S'il n'est pas déjà au courant, ton hypothèse l'intéressera sûrement.
[ Répondre ]
Re: Re:
Sauf si on dit que les objectifs de la GPL sont la liberté. D'ailleurs c'est pas de la mauvaise foi, j'en suis convaincu :)
L'obligation de conserver la licence pour les travaux dérivés est expliquée (par Stallman lui-même) comme une obligation de faire profiter à la communauté de ses travaux.
Elle peut donc être vue comme une marque de communautarisme (ce qui ne change pas le fait que la GPL est tournée vers la liberté : il y a des obligations qui vont avec, voilà tout); d'ailleurs à une époque je ne sais plus qui parlait de "commonism".
Pour continuer le lien obligations<->communauté (mais attention, ça devient vaseux et je ne garantis plus rien), on pourrait dire que la BSD raisonne à l'échelle de l'indivu (tu es libre de faire un peu tout ce que tu veux avec, tant que tu respectes les auteurs du code), et que la GPL raisonne à l'échelle d'une communauté (tu es libre de faire ce que tu veux tant que respecte les auteurs du code, mais aussi les membres de la communauté en les rendant libre de profiter de *ton* code).
D'où, peut-être, le lien avec le communisme. Mais il ne faut pas oublier que le libéralisme aussi est basé sur une approche globale : si tout le monde raisonne selon son intérêt personnel, et n'est pas entravé dans sa démarche, alors globalement on aura une solution optimale. C'est le "et n'est pas entravé dans sa démarche" qui montre qu'il y a là aussi des obligations à respecter (libre concurrence toussa) qui proviennent d'un point de vue global.
[ Répondre ]
Cette page a été générée par Templeet en 0.088s (dont 0.0096 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
« pour revenir à mon bureau KDE »
Tu sais qu'il est possible d'utiliser un WM personnalisé avec KDE ? Ce n'est pas parce que Kwin est utilisé par défaut que c'est le seul !
Il suffit de renseigner la variable $KDEWM. J'ai testé avec e16 et wmaker, ça marche très bien (kicker est pas bien intégré, mais à la rigueur osef).
Je ne sais pas si c'est aussi rose sous les WM euh non conventionnels à la Ion, mais à mon avis ça vaut le coup d'essayer, quitte à tripoter un peu KDE et/ou le WM pour que ça cohabite pas trop mal
[ Répondre ]