Surtout que Haskell sait inférer avec les types quoi il pourrait cogiter

JamyGourmand

Bien de te faire arnaquer?

Ton portable est neuf et tu l'as reçu il y a moins de 7 jours donc tu le retournes au marchand.

(si t'as acheté sur internet)

Si tu parles du délai de rétraction, depuis le 14 juillet il est passé à 14 jours

Ah je savais pas merci de l'info

Sinon Calet j'ai un gros soucis avec Haskell, dès que l'algorithme devient un peu trop complexe il s'y perds complétement et ne renvoie jamais de réponse. J'ai eu le même soucis avec le probleme 3 d'Euler, c'est un soucis qui vient de l'évaluation paresseuse? Comment y remédier?

Bon en fait c'est juste moi qui avait abusé sur le polynôme à résoudre Mais j'avais ce problème sur Euler.

Sinon comment rémédier à ça ?
ghci>solvePoly [1,-15,85,-225,274,-120]
<interactive>: out of memory (requested 1048576 bytes)

Faudrait lui autoriser a bouffer plus de mémoire mais comment

J'espère sincèrement qu'ils vont le me le changer oui. Car j'avais des économies exprès et j'ai payé le prix plein, pour avoir un ordinateur avec une dalle défaillante...

Aranyma c'est quoi ces conneries encore

Bien d'écorcher mon pseudo ?

JamyGourmand Regarde du côté de ulimit, mais si c'est une taille max pour ghc, ben regarde dans les options de ghc du coup

Ouais nan apparement d'après mes recherches google c'est pas possible

Je peux pas résoudre (x-1)(x-2)(x-3)(x-4)(x-5)

J'avais résolu (x-1)(x-2)(x-3)(x-4)(x-5)(x-6)(x-7) avec un algorithme similaire en Ruby c'est balot

T’as peut être fait de la merde en transposant impératif -> fonctionnel

Bah j'ai perdu l'algorithme en Ruby malheureusement mais j'ai juste utilisé les relations coefficient-racines à part ça, je pense que je peux l'optimiser grandement mais bon

http://pastebin.com/cj8c77LC

C'est surtout cette fonction qui bouffe énormément en fait

combinationsPoly :: Int -> PolyInt -> [[Integer]]
combinationsPoly x poly = uniq $ map (sort) $ replicateM x poly

Faut je trouve une alternative

Muse
Je suis resté beaucoup trop longtemps dans l'ignorance de ne pas m'être intéressé à ce groupe

J'aime bien Muse

Ma préférée c'est Madness

JamyGourmand Ça me rappelle ce code : http://pastebin.com/M7tT6zuF

Si python était bien garbage collecté et faisait ce qu'on lui demandait ça passerait crème, mais comme on a aucun contrôle sur la mémoire, la construction du suffixe array bouffe toute la mémoire (il faut croire que quand on fait : l.sort(key = f) python fait [ (f(l[i]),i) for i in range(len(l))].sort() et trie i suivant le mappage des i, parce que s'il appelait juste key à chaque fois, ça ferait pas autant de conso mémoire, ou alors les devs pythons se sont dit : « il y a O(n.log(n)) appels à key, si on stock map(key, l) dans une hashtable, on y a accès en O(1), ce qui fait n appels à une fonction de coût inconnu (mais un O(1) au total) au lieu de n.log(n) … C'est rentable ! »

Sauf que toi tu dis explicitement « duplique tout ! » alors que moi j'ai essayé d'éviter ça

Madness
Supremacy
Time is running out

Décidément Runny t'écoutes les mêmes groupes que mwa

Haskell ne fonctionne pas comme ça, c'est un langage paresseux. Ce que je fais dans ce code nous donnerait une complexité hors norme dans un langage comme Python ou C. Mais là avec Haskell ça passe, c'est le bienfait d'une évaluation paresseuse En gros quand tu écris du code que tu associes à une variable Haskell le retient et fait la promesse de délivrer le contenu quand la variable sera appelé du coup par exemple à ce moment là:

solvePoly :: PolyInt -> [Integer]
solvePoly poly = racines -- 4
where prob = racinesProbPoly poly -- 1
elim = eliminateRacines prob -- 2
racines = testRacines poly elim -- 3

1) Il retient que la variable prob est assimilé à racinesProbPoly poly, si on demande la variable prob c'est à ce moment là qu'il évalue racinesProbPoly
2) Il retient que elim est associé à eliminateRacines prob, il voit ce à quoi est associé prob et le retient mais n'évalue rien car personne n'a demandé elim
3) Même topo, personnes n'a encore demandé racines donc il retient juste les différents liens entre les variables
4) Là on lui demande de retourner racines et pour ça il faut l'évaluer, donc Haskell évalue prob puis évalue elim avant d'évaluer racines

Au final ce n'est pas si différent de simplement écrire testRacines poly ( eliminateRacines ( racineProbPoly poly ))

Intéressant n'est-ce pas

Ou bien je réponds à côté de la plaque

Toute la complexité et l'utilisation en mémoire réside dans la fonction plus haut (celle qui fait les combinaisons) car je demande de trier les sous-listes afin d'en éliminer les duplicata (l'addition et la multiplication sont commutatives) sauf que le tri nécessite d'évaluer toutes les combinaisons d'abord (dont le nombre s'exprime avec une factorielle mais je m'y connais pas trop je vais pas m'avancer ) du coup on surcharge la mémoire...

C'est con je vais essayer voir comment résoudre le problème

Sérieusement Haskell c'est vrai la Rolls des langages fonctionnels je comprends pas pourquoi c'est pas plus utilisé et pourquoi on persiste à enseigner de l'ocaml de merde

Le pire c'est mon programme du premier semestre qui arrive là, http://www.u-psud.fr/rof/fr/l2/ME7/ (PMMI)

"Introduction à la programmation objet"

Du java mais putain qu'est-ce que je m'en bat les reins, on peut pas avoir des trucs plus intéressants?

En Maths ça va quoi c'est le programme de MP un peu atrophié mais en Info

T'en penses quoi toi Chouhartem?

Je sais bien qu'Haskell utilise l'évaluation paresseuse, c'est un des arguments majeur avancé par les haskellers.

Du coup oui, tu as une sémantique identique pour une consommation mémoire réduite, mais tu as aussi tendance à oublier comment ça se passe en interne, puisque « c'est pas ton problème » en vrai

Du coup là tu as ce soucis que tu n'aurais pas eu avec un peu plus de contrôle. Par exemple en ocaml sans le module Lazy, tu as un langage où tu sais que le fonctionnement est le suivant :
let a = f x in g a
f est évaluée en x puis stocké en a dès let a = f x … Tu te dis : « ok », mais du coup ça te permet de garder un contrôle relatif sur tes effets de bords … puisqu'il y en a en ocaml comme ce n'est pas purement fonctionnel.

Sinon pourquoi on continue d'enseigner l'OCaml ? Pour la même raison qu'on continue d'enseigner Java : parce que c'est utilisé. Si tu veux faire de la preuve, tu vas devoir passer par coq … et si tu fais du coq, tu dois passer par OCaml.

Maintenant pourquoi c'est utilisé ? Parce que caml possède un cœur fonctionnel qui n'a rien à envier à Haskell (sauf sur 2~3 détails) … Et un système de modules (foncteurs <3 c'est pas la même chose qu'en Haskell) qui rend la chose vraiment puissante. Par dessus ça tu rajoutes une couche objet, mais je crois qu'elle est pas vraiment utilisée, et un peu d'impératif, parce que ça simplifie vachement la vie … Et tu as un langage pratique à utiliser.

Je pense que le choix d'Haskell d'être purement fonctionnel qui fait sa force … le marginalise un peu. Mais il n'en demeure pas moins utilisé à l'étranger vu que de toute façon chaque labo a ses habitudes. Mais pas dans les mêmes domaines du coup.

Du coup on t'apprends quand même le java parce que ça peut toujours servir. Par exemple on a fait un peu de java en système distribué parce que corba est utilisable en java rapidement. Du coup c'est toujours pratique à savoir suivant les utilisations.

C'est un problème d'ouverture d'esprit parce que tu ne sais jamais, un de mes profs m'a raconté qu'il galérait à trouver une méthode efficace pour résoudre un de ses problèmes … qui se traduisait facilement en programmation linéaire avec un nombre polynomial de variables et de contraintes \o/
Il ne connaissait pas la programmation linéaire à cette époque (c'était à ses débuts), du coup cette absence de connaissances lui a valu 5 mois de recherches infructueuses pour lui et son équipe.
Du coup pour prévenir ça, mieux vaut être prêt, imagine qu'il existe une bibliothèque magique en java qui résout un de tes problèmes … ben sans connaître java, tu ne penseras jamais à cette solution.

Ouais tu as raison m'enfin avec un langage impératif ou fonctionnel j'aurais eu le même problème, j'aurais du évaluer cette liste qui contient énormément d’éléments donc bon J'avais le même soucis en Ruby sauf qu'il apparaissait que je me frottais à des polynômes de degré 7 ou 8, là c'est juste la paresse qui se retourne contre moi mais je vais changer ça

Ouais j'avais j'ai un peu abusé, surtout que je m'y connais très peu en Ocaml. En gros je me demandais juste pourquoi Haskell n'était pas utilisé du tout, franchement j'ai bien eu du C l'année dernière comme introduction à l'informatique c'est pas le mieux pour débuter

Après ouais Java est utilisé mais ce que je voulais dire c'est que si je suis un tutorial d'apprentissage du Java j'aurais sensiblement le même contenu que ce cours quoi, après j'imagine que s'assurer d'avoir une bonne connaissance du Java c'est une bonne chose. Mais moi je veux juste me frotter à l'informatique théorique le plus tôt possible quoi

Haskell est dit purement fonctionnel mais tu peux faire de l'impératif en utilisant les blocs do, biensûr l'objectif est simplement de pouvoir communiquer et manipuler les entrées et sorties. Pour le reste on recommande fortement de se cantonner au code fonctionnel dît pur.

Du coup okay c'est cool quand même d'avoir des connaissances sur les langages les plus utilisés quand même, c'est un petit plus comme tu dis on ne sait jamais ce qui peut arriver. Mais j'aurais préféré à la place de l'ocaml par exemple, ce n'est pas pour rien que c'est ce langage qui est utilisé en option info. C'est le paradigme fonctionnel qui colle le plus à tout ce qu'on a pu faire depuis le début en Maths, et quand je vois qu'en un an et demi de fac j'aurais toujours pas eu de cours sur les langages fonctionnels je me dis merde quoi

Haskell est utilisé en université, mais pas en France quoi.

Oui, mais est-ce que tu serais aller te frotter à Java de toi même ? Moi perso non

Et faut pas oublier que t'es en tronc commun avec des gens qui veulent peut être faire de l'info pratique, si tu donnes que des cours théoriques dès la L1 ça devient bonbon pour se réorienter

Mais bon, de toute façon ya pas à chipoter, OCaml ≫ *