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

\\Ouranos// · Le 22/02/2011, à 03:11

Pylades · Le 22/02/2011, à 04:01

'tain, j'ai glandé toute la journée et je n'ai même pas codé…

Кຼزດ · Le 22/02/2011, à 04:06

Points.

nesthib · Le 22/02/2011, à 04:15

plop

samυncle · Le 22/02/2011, à 05:24

.

Compteur du TdCCT · Le 22/02/2011, à 08:42

Scores totaux, depuis le début :

1) 2632    nesthib
2) 2487    samuncle
3) 2097    Pylade
4) 1708    Кຼزດ
5) 1388+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1271    cm-t
7) 888    Р☢w ! ✰ :mad: ✰ (эй !)
8) 829    helly
9) 787    \\Ouranos//
10) 659    gnuuat
11) 542    Lagierl
12) 426    tshirtman
13) 239    Rolinh
14) 225    The Uploader
15) 212    Kanor
16) 196    Askelon
17) 172    nathéo
18) 121    ǤƦƯƝƬ
19) 93    petifrancais
20) 82    kamui57
21) 78    edge_one
21) 78    pierguiard
23) 75    :!pakman
24) 70    gulp
25) 39    Le Rouge
26) 37    ilagas
27) 30    keny
28) 26    gustare
29) 25    GentooUser
29) 25    Morgiver
29) 25    xapantu
32) 24    ไ୦บเઢ'
32) 24    Steap
34) 20    CROWD
34) 20    d10g3n
36) 18    Ph3nix_
37) 15    timsy
38) 14    kouskous
39) 12    stratoboy
39) 12    sailing
39) 12    sakul
42) 11    alexises
42) 11    Crocoii
42) 11    :mad: ✰ :бешеный: ✰ :mad:
45) 10    Toineo
45) 10    NutMotion
45) 10    pseudovingtcinqcaracteres
45) 10    pfriedZ
45) 10    CasseTaTele
45) 10    Zeibux
51) 8    Mornagest
52) 7    Vista
53) 6    ubuntlin
53) 6    asma.geek
55) 5    tendances-tdct
55) 5    kinouchou
57) 4    danychou56
57) 4    Neros
57) 4    Biaise
57) 4    totoflute
57) 4    pinballyoda ㋛
57) 4    NLS le pingouin
63) 3    Revan26914
64) 2    SoJaS
64) 2    ceric
66) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 22/02/2011, à 08:42

Scores de la période en cours :

1) 178    samuncle
2) 176    nesthib
3) 158    grim7reaper
4) 117    Кຼزດ
5) 103    Pylade
6) 90    cm-t
7) 74    Р☢w ! ✰ :mad: ✰ (эй !)
8) 61    The Uploader
9) 54    :!pakman
10) 42    Rolinh
11) 35    tshirtman
12) 27    helly
13) 23    Kanor
14) 17    gustare
15) 11    :mad: ✰ :бешеный: ✰ :mad:
16) 9    gnuuat
17) 8    kamui57
18) 4    NLS le pingouin
18) 4    Lagierl
18) 4    Zeibux
18) 4    \\Ouranos//

Rolinh · Le 22/02/2011, à 12:31

tshirtman a écrit :

s'ils executent ton code sur leur machine, ils ont intérêts à être sur que tu soit incapable de faire quoi que ce soit…

ça c'est certain ^^.

En revanche, le but ici n'est pas de simplement fournir un résultat car en général il est facile à obtenir. Le but c'est de produire un algorithme qui soit le plus efficace possible. Donc ils prennent ton code, le compile, font une batterie de tests dessus et te donnent un résultat.

@grim7reaper: c'est bien ce que je me disais. Merci. Par curiosité, tu leur a soumis quoi comme code?

grim7reaper · Le 22/02/2011, à 13:39

Un truc fait à l'arrache (tu m'as interpellé avant que j'aille me pieuter en fait ^^) que j'ai supprimé juste après avoir testé 3-4 fois…

Mais c'était pas un truc fabuleux…
De mémoire ça ressemblait à ça

#include <stdio.h>

unsigned long collatz_length(unsigned int n)
{
    unsigned long sz = 1;

    while(n != 1)
    {
        n = (n & 1) ? 3 * n + 1 : n / 2;
        sz++;
    }
    return sz;
}

int main(void)
{
    while(42)
    {
        unsigned int i = 0;
        unsigned int j = 0;
        unsigned int k = 0;
        unsigned long max = 0;
        int reads = scanf("%u %u", &i, &j);

        if(reads != 2)
            break;

        for(k = i; k <= j; k++)
        {
            unsigned long sz = collatz_length(k);
            max = (max > sz) ? max : sz;
        }
        printf("%u %u %lu\n", i, j, max);
    }
    return 0;
}

Dernière modification par grim7reaper (Le 22/02/2011, à 13:39)

Rolinh · Le 22/02/2011, à 14:21

Ouep, un truc dégueu chez moi aussi ^^ (redondance)

#include <stdio.h>
#include <stdlib.h>

long algo(long n);

int
main(void)
{
    long i, j, k;
    long l = 0;
    long m = 0;

    while (scanf("%ld %ld", &j, &k) != EOF) {

        if (j > k){
            for (i = k; i < (j + 1); i++) {
                if ((m = algo(i)) > l)
                    l = m;
            }
        } else {
            for (i = j; i < (k + 1); i++) {
                if ((m = algo(i)) > l)
                    l = m;
            }
        }

        printf("%ld %ld %ld\n", j, k, l);

        l = 0;
    }

    return EXIT_SUCCESS;
    /* NOTREACHED */
}

long
algo(long n)
{
    long i = 1;


    while (n != 1){
        n = (n & 1) * (3 * n + 1) + (~n & 1) * (n >> 1);
        i++;
    }

    return i;
    /* NOTREACHED */
}

Mais à part ça, l'énoncé précise qu'on devrait arriver à 1'000'000 donc unsigned int ne marche pas. Et sinon, même erreur que moi la première fois: il peut très bien passé 200 100 dans le stdin et il faut check les valeurs de l'intervalle entre le plus petit et le plus grand.

grim7reaper · Le 22/02/2011, à 14:39

Rolinh a écrit :

Mais à part ça, l'énoncé précise qu'on devrait arriver à 1'000'000 donc unsigned int ne marche pas.

Si ça fonctionne.
Largement même (UINT_MAX vaut 4 294 967 295 pour une archi 32 bits, donc à moins qu'il compile ça sur du 16 bits ça va).
Même int ça passait (INT_MAX vaut 2 147 483 647 sur du 32 bits), mais j'ai mis unsigned vu qu'on bosse pas avec du négatif.
Et puis chez moi long == int, alors bon ^^

Rolinh a écrit :

Et sinon, même erreur que moi la première fois: il peut très bien passé 200 100 dans le stdin et il faut check les valeurs de l'intervalle entre le plus petit et le plus grand.

Je suis parti du principe qu'il ne t'envoyais pas de la merde (sinon oui, faut blinder les entrées et là ça devient chiant).

Sinon, ton >> ne sert à rien (à part pour se la péter , comme le test de parité sans utiliser %), car n'importe quel compilo un minimum bien foutu optimise ce genre d'expressions triviales.

Rolinh · Le 22/02/2011, à 14:46

Non pas besoin de blinder les entrées ni de faire des tests de retour de fonctions, ce n'est pas le but ici. C'est juste que les entiers ne sont pas forcément donné dans un ordre croissant.

grim7reaper a écrit :

Sinon, ton >> ne sert à rien (à part pour se la péter , comme le test de parité sans utiliser %), car n'importe quel compilo un minimum bien foutu optimise ce genre d'expressions triviales.

Bah... pour moi ça fait un test en moins donc oui, je pense que c'est quand même mieux optimisé et ne sachant pas comment le compilo gère la division par 2, bah j'ai trouvé >> plus mignon ^^

grim7reaper · Le 22/02/2011, à 14:54

Rolinh a écrit :

Non pas besoin de blinder les entrées ni de faire des tests de retour de fonctions, ce n'est pas le but ici. C'est juste que les entiers ne sont pas forcément donné dans un ordre croissant.

Ouais, le sujet est pas super clair sur ce que tu dois gérer ou pas (ou alors je l'ai mal lu, vu que j'était pressé d'en finir hier ^^).

Rolinh a écrit :

grim7reaper a écrit :
Sinon, ton >> ne sert à rien (à part pour se la péter , comme le test de parité sans utiliser %), car n'importe quel compilo un minimum bien foutu optimise ce genre d'expressions triviales.
Bah... pour moi ça fait un test en moins donc oui, je pense que c'est quand même mieux optimisé

Oui, dans ton cas le & évite un test (je parlais plus de mon cas pour le test de parité).

Dans le même genre de truc, je préfère Project Euler (mais tu dois déjà connaîtres).

Dernière modification par grim7reaper (Le 22/02/2011, à 14:54)

Rolinh · Le 22/02/2011, à 15:04

Non, je ne connais pas Project Euler.

C'est plus orienté maths ou bien ça reste très algorithmique?

grim7reaper · Le 22/02/2011, à 15:15

Il y a toujours un fond de maths bien sûr, mais le côté algo est très présent aussi. Comme le but est de trouver la solution en moins d'une minute il faut parfois faire des recherches pour trouver le bon algo et bien l'implémenter. En faisant ces recherches, j'ai pu apprendre 2-3 trucs et c'est toujours ça de pris

Il y en a pas mal qui font de l'assembleur, du C ou du C++ pour moins réfléchir et compter sur la vitesse d'exécution et l'optimisation des compilo. Ça peut fonctionner au début, mais au bout d'un moment c'est vraiment l'algo qui prime. Donc c'est ouvert à tout les langages (même papier-crayon-gomme si tu veux)

Niveau maths, même moi qui ne suis pas une brute (loin de là), j'ai réussi à atteindre le niveau 1 assez facilement.

Rolinh · Le 22/02/2011, à 16:47

Faudra que je m'amuse avec alors. J'avais un peu peur parce que... les maths c'est pas trop mon truc non-plus ^^
Bah c'est clair que ce qui est intéressant ici c'est de réfléchir sur l'optimisation de l'algorithme et non pas en fonction du langage utilisé.

grim7reaper · Le 22/02/2011, à 21:35

Tiens, je viens d'apprendre qu'il y a deux opérateurs de division en Python 3 (/ pour la division avec les flottants et // pour la division entière).
Ça m'a rappelé cette discussion sur les opérateurs de mise à la puissance. thsirtman m'avait expliqué que l'unicité de l'opérateur pour les différentes opérations venait de la philosophie Python (ce qui n'est pas si con que ça).

Mais là du coup, c'est pas un logical failure cette histoire d'opérateurs pour les divisions ?

Pylades · Le 22/02/2011, à 21:44

Non.
Il existe différentes mise à la puissance, avec des domaines de définition différents ; mais le résultat est le même. C'est donc un détail mathématique, on occulte. En revanche, la division flottante et la division entière sont deux opérations différentes, avec des résultats différents. Donc on a deux opérateurs.

C'est parfaitement cohérent, donc.

Dernière modification par Pylade (Le 22/02/2011, à 21:45)

tshirtman · Le 22/02/2011, à 22:04

et l'unicité de la division en python 2 posait pas mal de soucis de clareté de code et d'élégance, quand ce n'était pas de pièges mortels…

genre je veux une division flottante quelle que soit mes valeurs de X et Y, je fais X/float(Y) ou X/(1.0*Y) et genre je veux une division entière entre les deux, je dois passer les deux en int().

Et puis en python3, du coup on peut faire des trucs comme ça

>>> 32//2.1
15.0
>>> 32//2
16
>>> 32/2.1
15.238095238095237
>>>

(oui je peux vouloir savoir combien de fois exact il y a un nombre flottant dans un nombre )

grim7reaper · Le 22/02/2011, à 22:12

Pylade a écrit :

Non.
Il existe différentes mise à la puissance, avec des domaines de définition différents ; mais le résultat est le même. C'est donc un détail mathématique, on occulte. En revanche, la division flottante et la division entière sont deux opérations différentes, avec des résultats différents. Donc on a deux opérateurs.
C'est parfaitement cohérent, donc.

Bah j'ai du mal à voir où.
Tu dis que les mises à la puisance ont des domaines de définitions différents. Oui, mais c'est pareil pour la division : la division entière à un domaine de définitions différent de la division flottant.

En gros, le résultat de l'opération dépend, aussi bien pour la division que pour la mise à la puissance, du type des opérandes. Donc je ne vois pas pourquoi il y a une différence de traitement dans ce cas-là.
Pourquoi ne pas garder qu'un seul opérateur et faire le traitement approprié en fonction du type des opérandes ?
Sur ce coup, Python 2 est bien plus logique je trouve.

[HS]
En passant, j'imagine le bordel quand il va falloir migrer les bibliothèques comme numpy à Python3 ^^ => vérif à la main de tout le code pour choisir le bon opérateur (bah oui, le type des variable n'est pas indiqué donc je vois mal comment automatiser le procédé…)
[/HS]

tshirtman a écrit :

et l'unicité de la division en python 2 posait pas mal de soucis de clareté de code et d'élégance, quand ce n'était pas de pièges mortels…

Faut dire que le typage dynamique, c'est loin d'être la meilleure chose qui est vue le jour…

Sinon j'ai vraiment du mal avec la notion d'élégance by Python

Dernière modification par grim7reaper (Le 22/02/2011, à 22:15)

tshirtman · Le 22/02/2011, à 22:54

Tu dis que les mises à la puisance ont des domaines de définitions différents. Oui, mais c'est pareil pour la division : la division entière à un domaine de définitions différent de la division flottant.

ben oui, mais avec les mêmes nombres, les deux trouvent des valeurs différentes, un problème qui ne se pose pas avec l'opérateur puissance…

du coup faire X/(1.0*Y) c'est pas joli, pas plus que int(X)/int(Y), la division entière avec // est donc une alternative sympathique…

sinon numpy a été passé à python3 oui ça a pris un peu de temps, mais c'est fait

grim7reaper · Le 22/02/2011, à 22:58

Ok.

Sir Na Kraïou · Le 22/02/2011, à 23:17

.

Pylades · Le 22/02/2011, à 23:52

grim7reaper a écrit :

Pylade a écrit :
Non.
Il existe différentes mise à la puissance, avec des domaines de définition différents ; mais le résultat est le même. C'est donc un détail mathématique, on occulte. En revanche, la division flottante et la division entière sont deux opérations différentes, avec des résultats différents. Donc on a deux opérateurs.
C'est parfaitement cohérent, donc.
Bah j'ai du mal à voir où.
Tu dis que les mises à la puisance ont des domaines de définitions différents. Oui, mais c'est pareil pour la division : la division entière à un domaine de définitions différent de la division flottant.

Non.
Les divisions entières et flottantes sont définies sur le même domaine : l'ensemble des réels pour les deux opérandes. Et quand bien même cela ne serait pas le cas, il n'empêche que le résultat est complétement différent (16/3, ce n'est pas pareil que 16//3, vérifie ), donc il est évident qu'avoir deux opérateurs s'impose (car contrairement à ce qui se passe en C, ici on est en typage dynamique).

grim7reaper a écrit :

En gros, le résultat de l'opération dépend, aussi bien pour la division que pour la mise à la puissance, du type des opérandes.

Ben non. 2^3, 2^^3 et 2**3, c'est le même nombre, il n'y a que le type qui change.

grim7reaper a écrit :

Donc je ne vois pas pourquoi il y a une différence de traitement dans ce cas-là.

Ben dans un cas, il n'y qu'une différence d'implémentation ; dans l'autre, on a deux opérations qui ont un but différent.

grim7reaper a écrit :

Pourquoi ne pas garder qu'un seul opérateur et faire le traitement approprié en fonction du type des opérandes ?
Sur ce coup, Python 2 est bien plus logique je trouve.
[…]

Pour deux raisons : Python a un typage dynamique ; et Python est un langage de haut niveau.
Et puis, explicit is better than implicit…

En Python 2, il y avait bien moyen de forcer la division entière avec //, mais on avait cependant parfois le droit aux trucs moches dont a parlé Tshirtman ; donc c'était moins bien de toutes façons.

Dernière modification par Pylade (Le 22/02/2011, à 23:52)

:!pakman · Le 23/02/2011, à 00:20

/me viens de commencer un projet en parallèle de pakman : skriptux...
Just for the fun
Vous dessinez quelque chose sur un damier et cela vous lance le scripte correspondant au dessin du damier...
Une image pour illustrer ça :

Ici, par exemple, quand l'user dessinera un espèce de "L" sur ces cases, cela lancera Firefox ou n'importe quoi d'autre...
Le schéma présenté ici est une simple ébauche réalisée sous Gimp, sans doute loin du programme final qui sortira...

A utiliser avec compiz, cela promet d'être puissant :
L'utilisateur touche le bord du haut de son écran avec sa souris par exemple, cela lance automatiquement skriptux, et l'user n'a plus qu'a dessiner une forme simple avec sa souris pour lancer le programme de son choix, qu'il aura préalablement associé à une forme à dessiner...
Sans un clic, sans un appui sur une touche, juste avec un mouvement la souris !

Dernière modification par :!pakman (Le 23/02/2011, à 00:28)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2251 Le 22/02/2011, à 03:11

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

#2252 Le 22/02/2011, à 04:01

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

#2253 Le 22/02/2011, à 04:06

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

#2254 Le 22/02/2011, à 04:15

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

#2255 Le 22/02/2011, à 05:24

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

#2256 Le 22/02/2011, à 08:42

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

#2257 Le 22/02/2011, à 08:42

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

#2258 Le 22/02/2011, à 12:31

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

#2259 Le 22/02/2011, à 13:39

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

#2260 Le 22/02/2011, à 14:21

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

#2261 Le 22/02/2011, à 14:39

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

#2262 Le 22/02/2011, à 14:46

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

#2263 Le 22/02/2011, à 14:54

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

#2264 Le 22/02/2011, à 15:04

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

#2265 Le 22/02/2011, à 15:15

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

#2266 Le 22/02/2011, à 16:47

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

#2267 Le 22/02/2011, à 21:35

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

#2268 Le 22/02/2011, à 21:44

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

#2269 Le 22/02/2011, à 22:04

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

#2270 Le 22/02/2011, à 22:12

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

#2271 Le 22/02/2011, à 22:54

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

#2272 Le 22/02/2011, à 22:58

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

#2273 Le 22/02/2011, à 23:17

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

#2274 Le 22/02/2011, à 23:52

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

#2275 Le 23/02/2011, à 00:20

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

Pied de page des forums