/* Topic des codeurs couche-tard [2] */

grim7reaper · Le 12/12/2010, à 00:01

Pylade a écrit :

grim7reaper a écrit :
[…]
Sinon, j'en profite pour signaler qu'il y a 3 opérateurs de mise à la puissance en Haskell
** : Takes two floating point numbers and uses logarithms to compute the power.
^^ : Takes a fractional number (i.e. a floating point or a ratio, of which more later) and raises it to a positive or negative integer power.
^ : Takes any numerical type and raises it to a positive integer power.
Normal. L'élévation à la puissance est définie à trois niveau en mathématiques.

Certes, mais je connais pas beaucoup d'autres langages qui en propose 3 (mais je me suis jamais penché sur la question non plus).
À ma connaissance le Fortran ne le fait pas. Et Python ?

grim7reaper a écrit :
On est 3 Haskellers maintenant :]
Bientôt tout le TdCCT ?

L'avenir nous le dira ^_^.
Tu veux nous rejoindre ?

grim7reaper a écrit :
Oui clairement. Ça évite de mettre un route un « gros » algo pour rien (même pas un gain de caractère alors…)
Ben justement, le fait que Haskell sépare les différentes élévations à la puissance évite de faire tourner de gros algos pour rien. Je peut me tromper, mais j'ai comme l'intuition que a*a et a^2, ça revient au même. Il faudrait compiler avec les optimisations et comparer pour se faire une idée.

Pas si j'en crois le code source qui semble utiliser un algo moins naïf (probablement plus optimisé)

-- | raise a number to a non-negative integral power
{-# SPECIALISE (^) ::
        Integer -> Integer -> Integer,
        Integer -> Int -> Integer,
        Int -> Int -> Int #-}
(^) :: (Num a, Integral b) => a -> b -> a
x0 ^ y0 | y0 < 0    = error "Negative exponent"
        | y0 == 0   = 1
        | otherwise = f x0 y0
    where -- f : x0 ^ y0 = x ^ y
          f x y | even y    = f (x * x) (y `quot` 2)
                | y == 1    = x
                | otherwise = g (x * x) ((y - 1) `quot` 2) x
          -- g : x0 ^ y0 = (x ^ y) * z
          g x y z | even y = g (x * x) (y `quot` 2) z
                  | y == 1 = x * z
                  | otherwise = g (x * x) ((y - 1) `quot` 2) (x * z)

Dernière modification par grim7reaper (Le 12/12/2010, à 00:03)

Pylades · Le 12/12/2010, à 00:21

Bon, je ne comprends pas grand-chose, mais en effet, ça a l'air moins naïf. Mais bon, contrairement à ce qui se passe en C ou dans d'autre langage, c'est peut-être optimisable par le compilateur…

Et pour Python, il n'a pas plusieurs opérateurs, à ma connaissance…

grim7reaper · Le 12/12/2010, à 00:30

Pylade a écrit :

Bon, je ne comprends pas grand-chose

Moi non plus si ça peut te rassurer ^_^.

Édit : après analyse du code, il semblerait que pour une mise au carré le surcoût n'est pas trop cher (on se bouffe juste 3 tests + un calcul de quotient en plus de la multiplication x*x).
Bon après on a aussi le coup d'appel…

Mais bon, c'est moins pire que ce que j'imaginais au départ (cela dit, j'avais raison car * est meilleur, de peu certes mais il l'est )

mais en effet, ça a l'air moins naïf. Mais bon, contrairement à ce qui se passe en C ou dans d'autre langage, c'est peut-être optimisable par le compilateur…

Je ne pense pas. Pour le coup c'est vraiment une optimisation en fonction des arguments donc ça me semble tendu (après je suis pas non plus un spécialiste…). Genre l'algo naïf est meilleur jusqu'a tel puissance sachant que l'argument vaut ça (dans le cas où on connait la valeur à la compilation !) faut utiliser tel code…
Ça ne me semble pas très viable.

J'ai tenté d'analyser une sortie assembleur mais il y a trop de bruits pour que je puisse en tirer quelque chose (en tout cas le code n'est pas le même).

Et pour Python, il n'a pas plusieurs opérateurs, à ma connaissance…

Peut-être pour Python 3.*

Dernière modification par grim7reaper (Le 12/12/2010, à 00:37)

tshirtman · Le 12/12/2010, à 00:39

c'est pas franchement dans la logique de python de proposer trois opérateurs pour faire la même chose…

import this a écrit :

The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

grim7reaper · Le 12/12/2010, à 00:47

C'est dommage, parce que d'après Pylade (si j'ai bien compris ce qu'il a dit) ce n'est pas la même chose au niveau mathématique…
D'ailleurs, Wikipédia parle bien DES fonctions puissances, et non pas de LA fonction puissance.

Dernière modification par grim7reaper (Le 12/12/2010, à 00:56)

tshirtman · Le 12/12/2010, à 00:54

ben pour moi y'a une fonction puissance n par réel n…

(après oui, d'après wikipedia, on peut en trouver des pour n complexe… mais bon, je me sent pas concerné…)

Dernière modification par tshirtman (Le 12/12/2010, à 00:55)

grim7reaper · Le 12/12/2010, à 00:56

Nan mais c'est pas stupide non plus, c'est une idée qui se défend s'il utilise l'algo adapté à chaque situation en interne.
Par contre, s'il utilise l'algo pour les exposant réels même pour les exposant entiers, bah c'est de la merde (parce c'est pas le même coût derrière).

Dernière modification par grim7reaper (Le 12/12/2010, à 00:58)

tshirtman · Le 12/12/2010, à 00:58

je pense en effet que l'algo utilisé dépends de la situation ils ont des contraintes de perfs quand même hein

grim7reaper · Le 12/12/2010, à 00:59

Je pense aussi, sinon ça mériterait un sacré rapport de bug .

tshirtman · Le 12/12/2010, à 01:14

et un sacré patch ^^

Pylades · Le 12/12/2010, à 01:15

grim7reaper a écrit :

J'ai tenté d'analyser une sortie assembleur mais il y a trop de bruits pour que je puisse en tirer quelque chose (en tout cas le code n'est pas le même).

Bon, je m'incline alors, ça ne doit pas revenir au même…

grim7reaper a écrit :

Pylade a écrit :
Et pour Python, il n'a pas plusieurs opérateurs, à ma connaissance…
Peut-être pour Python 3.*

Je parle toujours de Python 3 ; avant le langage n'était pas assez bon pour que je m'y intéresse.

tshirtman a écrit :

je pense en effet que l'algo utilisé dépends de la situation ils ont des contraintes de perfs quand même hein

Et puis c'est bien dans l'esprit de Python, du point de vue de l'utilisateur, un même opérateur ou fonction, et c'est en interne que les différences de traitement apparaissent. Tu peux donner à manger n'importe quel type à certaines fonctions ; elle travailleront en fonction du type passé.

Enfin bref, ça ne m'étonnerait pas du tout (d'autant plus que ce serait assez dommage que ce ne soit pas le cas).

grim7reaper · Le 12/12/2010, à 01:18

@tshirtman : Oui également, mais bon si c'est tellement évident pour qu'on s'en rende compte c'est quasiment sûr que c'est fait depuis Python 2.0 (voir avant) ^_^.

Pylade a écrit :

grim7reaper a écrit :
J'ai tenté d'analyser une sortie assembleur mais il y a trop de bruits pour que je puisse en tirer quelque chose (en tout cas le code n'est pas le même).
Bon, je m'incline alors, ça ne doit pas revenir au même…

J'ai fait une analyse plus fine par la suite (mon édit en fait), ce n'est pas pareil mais ce n'est pas si différent au final.

grim7reaper a écrit :
Pylade a écrit :
Et pour Python, il n'a pas plusieurs opérateurs, à ma connaissance…
Peut-être pour Python 3.*
Je parle toujours de Python 3 ; avant le langage n'était pas assez bon pour que je m'y intéresse.

J'ai mis * pour parler des versions à venir

Tu peux donner à manger n'importe quel type à certaines fonctions ; elle travailleront en fonction du type passé.

Ouais, enfin ça on l'a aussi en Haskell et avec un typage statique s'il vous plaît

Dernière modification par grim7reaper (Le 12/12/2010, à 01:19)

gnuuat · Le 12/12/2010, à 01:37

Ce matin, exam de cpp \o/ .
Le sujet :
1) faire une interface et une classe abstraite de robots
2) faire 4 classes robots qui les implémentent ;
3) transformer en lib les classes finales, les compiler avec un code obfusqué... Pour générer le sujet de l'exo 4 !
4) ... "Robots can't enter".
J'ai fail sur le 3, mais c'était bien marrant ^^ .

grim7reaper · Le 12/12/2010, à 01:38

gnuuat a écrit :

les compiler avec un code obfusqué...

C'est à dire ?

Elzen · Le 12/12/2010, à 01:57

Hmm, p'tit soucis en CGTK[add]+[/add]…

Pour limiter un peu le nombre de lignes de code de la calculette, j'essaye de faire une fonction qui crée automatiquement les boutons. Elle prend en paramètre un pointeur sur le GtkContainer parent, le label du bouton, et la fonction à laquelle connecter lors d'un clic (vous savez, le truc en G_CALLBACK(nom_de_la_fonction))

C'est ce dernier paramètre qui me pose problème : je ne sais pas avec quel type le déclarer. J'suis allé voir dans le code de gsignal.h au cas où, mais je n'ai pas trouvé. Quelqu'un a une idée ?

compte supprimé · Le 12/12/2010, à 02:01

Bn2;

nesthib · Le 12/12/2010, à 02:02

plop

grim7reaper · Le 12/12/2010, à 02:03

@ArkSeth : Un GCallback ça passe pas ?

Sinon, c'est plutôt le code de gtksignal.h (ou la doc en ligne aussi) qui aurait pu t'aider

Dernière modification par grim7reaper (Le 12/12/2010, à 02:04)

Elzen · Le 12/12/2010, à 02:08

C'était bien GCallback ^^

Et les fonctions en gtk_signal sont dépréciées, et il est conseillé d'aller voir à la place les équivalents en g_signal, donc là je suivais la doc

grim7reaper · Le 12/12/2010, à 02:09

Ha, ça je ne le savais pas.

Merci pour l'info.

Dernière modification par grim7reaper (Le 12/12/2010, à 03:01)

Elzen · Le 12/12/2010, à 02:10

De rien, pour une fois que c'est moi qui t'apprends un truc ^^

samυncle · Le 12/12/2010, à 03:00

nesthib · Le 12/12/2010, à 03:14

plop

Rolinh · Le 12/12/2010, à 03:19

.

Compteur du TdCCT · Le 12/12/2010, à 07:42

Scores totaux, depuis le début :

1) 2062    nesthib
2) 1965    samuncle
3) 1640    Pylade
4) 1281    Кຼزດ
5) 1048    cm-t
6) 958+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 710    \\Ouranos//
8) 702    Р☢w ! ✰ :mad: ✰ (эй !)
9) 682    helly
10) 454    gnuuat
11) 436    Lagierl
12) 314    tshirtman
13) 196    Askelon
14) 172    nathéo
15) 167    Kanor
16) 121    ǤƦƯƝƬ
17) 93    petifrancais
18) 78    edge_one
18) 78    pierguiard
20) 70    gulp
21) 62    The Uploader
22) 59    kamui57
23) 37    ilagas
24) 32    Le Rouge
25) 30    keny
26) 25    GentooUser
27) 24    ไ୦บเઢ'
28) 20    Morgiver
28) 20    CROWD
28) 20    xapantu
31) 18    Ph3nix_
32) 15    timsy
33) 14    kouskous
33) 14    Steap
33) 14    Rolinh
36) 12    stratoboy
36) 12    sailing
36) 12    Sherwood51
36) 12    sakul
40) 11    alexises
40) 11    Crocoii
42) 10    Toineo
42) 10    NutMotion
42) 10    pseudovingtcinqcaracteres
42) 10    pfriedZ
46) 8    Mornagest
47) 7    Vista
48) 6    Zeibux
48) 6    ubuntlin
48) 6    asma.geek
51) 5    tendances-tdct
51) 5    kinouchou
53) 4    danychou56
53) 4    Neros
53) 4    Biaise
53) 4    totoflute
53) 4    pinballyoda ㋛
58) 2    SoJaS
58) 2    ceric
60) 1    geenux

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2176 Le 12/12/2010, à 00:01

Re : /* Topic des codeurs couche-tard [2] */

#2177 Le 12/12/2010, à 00:21

Re : /* Topic des codeurs couche-tard [2] */

#2178 Le 12/12/2010, à 00:30

Re : /* Topic des codeurs couche-tard [2] */

#2179 Le 12/12/2010, à 00:39

Re : /* Topic des codeurs couche-tard [2] */

#2180 Le 12/12/2010, à 00:47

Re : /* Topic des codeurs couche-tard [2] */

#2181 Le 12/12/2010, à 00:54

Re : /* Topic des codeurs couche-tard [2] */

#2182 Le 12/12/2010, à 00:56

Re : /* Topic des codeurs couche-tard [2] */

#2183 Le 12/12/2010, à 00:58

Re : /* Topic des codeurs couche-tard [2] */

#2184 Le 12/12/2010, à 00:59

Re : /* Topic des codeurs couche-tard [2] */

#2185 Le 12/12/2010, à 01:14

Re : /* Topic des codeurs couche-tard [2] */

#2186 Le 12/12/2010, à 01:15

Re : /* Topic des codeurs couche-tard [2] */

#2187 Le 12/12/2010, à 01:18

Re : /* Topic des codeurs couche-tard [2] */

#2188 Le 12/12/2010, à 01:37

Re : /* Topic des codeurs couche-tard [2] */

#2189 Le 12/12/2010, à 01:38

Re : /* Topic des codeurs couche-tard [2] */

#2190 Le 12/12/2010, à 01:57

Re : /* Topic des codeurs couche-tard [2] */

#2191 Le 12/12/2010, à 02:01

Re : /* Topic des codeurs couche-tard [2] */

#2192 Le 12/12/2010, à 02:02

Re : /* Topic des codeurs couche-tard [2] */

#2193 Le 12/12/2010, à 02:03

Re : /* Topic des codeurs couche-tard [2] */

#2194 Le 12/12/2010, à 02:08

Re : /* Topic des codeurs couche-tard [2] */

#2195 Le 12/12/2010, à 02:09

Re : /* Topic des codeurs couche-tard [2] */

#2196 Le 12/12/2010, à 02:10

Re : /* Topic des codeurs couche-tard [2] */

#2197 Le 12/12/2010, à 03:00

Re : /* Topic des codeurs couche-tard [2] */

#2198 Le 12/12/2010, à 03:14

Re : /* Topic des codeurs couche-tard [2] */

#2199 Le 12/12/2010, à 03:19

Re : /* Topic des codeurs couche-tard [2] */

#2200 Le 12/12/2010, à 07:42

Re : /* Topic des codeurs couche-tard [2] */

Pied de page des forums