Le bruteforce est la seule manière d'être sûr d'avoir un nombre premier. Les autres tests sont plus rapides mais donnent parfois des faux-positifs.
Caletlog :> En 2001, date de sortie de l'exercice, ça devait prendre «un peu» plus de temps j'crois. ![]()
Knakis > mais on serait pas passé de plusieurs heures à 0.08 secondes, quand même, si ?
Je sais pas, je l'avais fait en mode idiot, sans toutes les propriétés mathématiques pour réduire le temps que ça prends.
Faudrait que quelqu'un avec une épave tente de le faire, pour voir.
Toutes les propriétés mathématiques, c'est qu'une majoration hein
Bon sinon ça m'énerve ça fonctionne pas, ça fonctionne pour de petits nombre mais là il me renvoie que le plus grand diviseur premier est 137
Sinon c'est quoi votre record à Projet Euler ? Je suis dans la trentaine en Ruby ![]()
Je vois pas pourquoi ça fonctionne pas pour des nombres trop grands
isPrime :: (Integral a) => a -> Bool
isPrime 0 = error "0 not allowed"
isPrime x
| length [ n | n<-[2..max],x `mod` n == 0] == 0 = True
| otherwise = False
where max = truncate $ sqrt $ fromIntegral x
48 en Ruby pour moi.
Mais faut dire que le n°48 est franchement très simple, il aurait plus sa place dans les 20 premiers.
Ouais après j'ai des périodes, des fois je me fous une semaine dessus et j'en résouds 15 puis j'en fais plus pendant 4 mois
Mais là les faire en Haskell c'est un challenge intéressant, les faire en Ruby a très peu d'intérêt pour moi. Même si je les réussis j'en pas bien fier ![]()
suis*
Oui, en Haskell c'est très intéressant à faire.
Et puis y'a des cas où le Haskell permet vraiment de résoudre ça en une ligne, genre quand ça touche aux triangles ou aux triplets X ou Y.
Après je les fais souvent d'abord en Ruby pour penser uniquement à l'algo et pas la syntaxe, pour les refaire ensuite en C++. Généralement c'est la même chose, de toute façon. Les structures sont juste 'dépliées'.
" Ouais après j'ai des périodes, des fois je me fous une semaine dessus et j'en résouds 15 puis j'en fais plus pendant 4 mois"
Pareil. Parfois je bloque sur un problème pendant 3 semaines avant d'abandonner, et là 3 mois plus tard, illumination soudaine et on se demande comment on a pas pu voir ça
Et à côté je suis incapable de résoudre le problème 8 étonnement, ça fait un trou dans ma liste ![]()
Ouais c'est clair, mais là par exemple le problème 3 je me fais enculer sevèrement ![]()
Clairement Ruby avec ses fonctions built in le projet euler tu lui fais mal quoi.
Mais je pense avoir compris mon problème, depuis le début j'utilise ghci. J'ai pas encore écrit de vrai script, du coup comme Haskell n'est pas un vrai langage interprêté ça doit jouer énormément sur la lenteur. Du coup je fais le compiler dans un script à part.
Mais j'ai jamais fait ça, tu peux m'expliquer le soucis dans mon main
isPrime :: (Integral a) => a -> Bool
isPrime 0 = error "0 not allowed"
isPrime x
| length [ n | n<-[2..max],x `mod` n == 0] == 0 = True
| otherwise = False
where max = truncate $ sqrt $ fromIntegral x
divisorsOf :: (Integral a) => a -> [a]
divisorsOf 0 = error "Division by zero"
divisorsOf x = [ n | n<-[1..x], x `mod` n == 0]
main = putStrLn $ last $ filter (isPrime) $ divisorsOf 600851475143
Erreur:
prime_brute.hs:13:34:
No instance for (Integral String) arising from a use of ‘isPrime’
In the first argument of ‘filter’, namely ‘(isPrime)’
In the expression: filter (isPrime)
In the second argument of ‘($)’, namely
‘filter (isPrime) $ divisorsOf 600851475143’
prime_brute.hs:13:56:
No instance for (Num String)
arising from the literal ‘600851475143’
In the first argument of ‘divisorsOf’, namely ‘600851475143’
In the second argument of ‘($)’, namely ‘divisorsOf 600851475143’
In the second argument of ‘($)’, namely
‘filter (isPrime) $ divisorsOf 600851475143’
Sinon le problème 8 est pas trop dur en Ruby, mais j'ai mis un peu de temps à l'écrire. Peut être 1h ![]()
En fait il fallait appeler show avant de le passer à PutStrLn
Bon sinon je pense que que le bruteforce soit une option avec un langage paresseux, j'ai le même code qu'en Ruby là et j'ai toujours rien après une minute
(Sinon t'as réussi le 18 mais pas le 8 wtf?)
"Clairement Ruby avec ses fonctions built in le projet euler tu lui fais mal quoi."
Rooh, mais arrête avec ça ![]()
Les built-ins pour des tours mathématiques comme ceux proposés dans Euler, y'en a dans _tous_ les langages. Sauf que pour les problèmes, suffit de ne pas les utiliser. J'ai pas utilisé la bibliothèque de primes de Ruby qui génère des primes de façon optimisée, par exemple. Et c'est normal, c'est même inscrit dans les règles.
Tout ce que j'ai fait en Ruby se développe exactement de la même façon dans n'importe quel autre langage impératif, simplement en plus de lignes en général. Tout ce que la syntaxe du Ruby apporte dans ces cas-là, c'est 3 lignes économisées en faisant un each plutôt qu'un for. Tu penses vraiment que c'est ça qui gâche le jeu ou qui apporte un quelconque avantage ? ![]()
Le langage ne change pas l'algorithme ni même son implémentation tant qu'on reste dans le même paradigme. Et dans le projet euler, c'est l'algo qui compte, on se fout de savoir si on l'a fait avec un forEach ou un for, puisque c'est juste du sucre syntaxique. Quelqu'un qui sait utiliser un forEach sait utiliser un for, quand même.
C'est comme si tu grognais parce que quelqu'un utilise les += ou ++/-- parce qu'on a toujours moyen de le faire plus classiquement.
Pas dans ce cas là, je te parle de la majorité des problèmes requierant un algorithme bien foutu qui se fait en quelques fonctions de Ruby déjà built-in ![]()
Après je dis pas que c'est le cas de tout les problèmes mais bon utiliser des fonctions built-in ça aide énormément et ça m'étonnerait que tu n'en aies jamais utilisés (autres que les simples raccourcis)
C'est pas de la sorcellerie, ces fonctions ont bien du être écrite par un être humain, donc je vois pas pourquoi c'est si étonnant. ![]()
Dites, j'ai installé Gnome, et maintenant mon Grub est limite vert avec écrit "Debianedu SkoleLinux", et j'ai aussi ce fond d'écran, et en l'ouvrant ça m'a ouvert une page web vers un truc de l'éducation ou je ne sais quoi, si je vais dans Aptitude et que je supprime tout GNOME, tout rentrera dans l'ordre?
Merci! ![]()
Donne un exemple, parce que sérieusement je vois pas.
Je vois 2 choses à quoi tu peux penser : les fonctions wrappers qui ne sont que des _sucres syntaxiques_, comme les boucles et itérateurs (each, select, map, times, ...). C'est tellement mécanique qu'on peut tout à fait les convertir en boucles classiques avec un préprocesseur. Le seul avantage que ça apporte, c'est une diminution du nombre de lignes. Rien d'autre, et quiconque sait utiliser ces wrappers parfois obscurs sait utiliser les structures de base qu'il y a derrière. C'est exactement le même principe que les ++/-- ou +=/*=/... : ça permet de gagner du temps, mais n'importe quel idiot peut résoudre un problème sans s'en servir. Y'a pas besoin de sortir d'X pour implémenter un map ou un select, quand même.
L'autre option, ce sont les fonctions des bibliothèques standards ou utilisateur, type prime pour générer des nombres premiers, les fonctions de tri, ou celles qui bossent avec de l'aléatoire. Là, c'est plus compliqué à implémenter manuellement, forcément, et je suis d'accord, c'est de la triche si on s'en sert dans un problème Euler.
Mais ça, je me répète, c'est disponible dans n'importe quel langage. C++ les a, Python les a, Java les a, ... C'est stupide de s'en servir pour les problèmes Euler, mais ça c'est propre à l'utilisateur, pas au langage et sur ce point Ruby fait ni mieux ni moins bien que les autres.
Pour le reste, je vois pas. Ruby n'est pas un langage magique qui résout les problèmes pour toi. S'il est populaire, c'est surtout parce qu'il est bourré de sucres syntaxiques et de constructions souples (les if/while/whatever placables n'importe où dans une ligne, par exemple), ce qui permet de gagner du temps de développement parce qu'on a pas besoin de répéter 36k fois les mêmes choses.
Non mais sur ce point tu as parfaitement raison, Ruby est bourré de sucre syntaxiques qui font qu'on écrit qu'on écrit plus facilement ce qu'on pense. Toujours est-il que rien que ça c'est déjà un énorme avantage sur d'autres langages, mais nous ne leurrons pas 99% de ces choses peuvent être écrit avec des structures standards.
J'ai pas trop d'exemple ça fait longtemps le projet Euler et j'en suis qu'au problème 3 actuellement
Mais particulièrement je pense à ça (il y a en d'autres),
https://projecteuler.net/problem=19
C'est un problème qui algorithmiquement n'est pas trivial à mon sens, mais en 10 lignes de Ruby c'est fait. On crée un objet Time avec la date de départ on fait une boucle où on incrémente d'un jour à chaque itération et là magie la petite fonction Sunday? de Ruby (
) qui fait tout le boulot.
Quand je serais arrivé au point où j'en suis en Ruby actuellement avec Haskell je te donnerais d'autres exemples là je suis toujours au 3 ème ![]()
Et tu utilise un groupement non trivial de la bibliothèque standard.
Les objets Date/Time sont pas exclusifs au Ruby, t'en as dans la quasi totalité des langages de script, et C/C++ ont des utilitaires semblables avec le header <ctime>
C'est le même principe que les nombres premiers ou les algos de tri, là encore. Si on fait ce problème, on les utilise pas, mais c'est la même situation dans un nombre impressionnant de langages.
vava740 ( https://www.jeuxvideo.com/forums/1-38-7665853-2084-0-1-0-0.htm#message_7818638 )
« Lien du thème CSS GitHub pour GitWeb ?
»
https://github.com/kogakure/gitweb-theme il me semble.
Simple et efficace. Le seul truc qui "manque" à gitweb vanilla c'est l'affichage du réseau de commits mais je m'en fous, je fais ça en local avec gitg ![]()