Citation
niorf
Bonjour,

j'ai une question, vous dites que le C n'est pas
un bon langage pour commencer à apprendre à
programmer. Mais comment expliquer vous que c'est
pourtant le premier langage enseigné en IUT,
Universitée, école d'ingé
et que les langages type ML eux ne sont pas ou
tres peu enseigné ?

Je n'ai pas l'impression que ce soit le cas, ou alors l'Université de Nantes est une exception (?), en ce qui me concerne je suis en licence (L3 comme on dit maintenant) et je n'ai fait pratiquement que du Pascal pendant mes deux premières années (et un peu de Caml-Light). Et le discours de la grande majorité des enseignants à propos des langages est globalement le même que celui de Basile STARYNKEVITCH, ce qui se vérifie puisque j'ai effectivement apris les bases du C rapidement et seul, juste avec un peu de documentation trouvée sur le net.

Poste le Wednesday 1 March 2006 04:21:25

Citation
abgech
Combien de fois ai-je dit que l'on devrait apprendre à programmer avec un cerveau, du papier, une gomme et un crayon (dans l'ordre d'importance décroissante).

C'est ce qu'essaient de faire les programmes de prépa, surtout au début : de la théorie pure ! Résultat : un cours parfois intéressant mais qui reste très abstrait. Heureusement qu'il y a les TP pour appliquer, sinon personne n'y comprendrait rien ... Bien sûr qu'à un moment il faut apprendre comme ça, mais avoir des bases expérimentales de ce qu'est une instruction, une boucle, une procédure, ça aide quand même beaucoup.
Un autre risque, c'est de ne pas comprendre que la théorie, c'est bien, mais assez loin de la pratique (un algorithme en n.ln(n) peut être plus efficace qu'un algorithme de complexité exponentielle sur certaines données, par exemple on ne résoud pas un voyageur de commerce à 4 villes avec un AG).

Au fait, j'aurais mis le crayon avant le papier et la gomme ... comment on fait pour écrire sinon #%b !

[catwell.info]

Poste le Friday 3 March 2006 20:26:16

Citation
AlSim
... Au fait, j'aurais mis le crayon avant le papier et la gomme ... comment on fait pour écrire sinon !...

C'est volontairement que j'ai mis la gomme avant le crayon, pour bien illustrer le fait que la qualité principale d'un développeur est son sens critique et sa capacité à se remettre en question ! Je suis surpris que tu ne l'aie pas compris.

Poste le Saturday 4 March 2006 08:42:58

Citation
abgech
Je suis surpris que tu ne l'aie pas compris.

C'est normal, je suis un peu lent à la détente ^o^ ...

[catwell.info]

Poste le Saturday 4 March 2006 10:06:36

Citation
AlSim
un algorithme en n.ln(n) peut être plus
efficace qu'un algorithme de complexité
exponentielle sur certaines données

C'est même toujours le cas, je dirais que tout est toujours préférable à une exponentielle.

Poste le Saturday 4 March 2006 21:18:40

Oups, oui, bien sûr je voulais écrire l'inverse (un algorithme de complexité exponentielle peut parfois être plus efficace qu'un algorithme en n.ln(n)), mais je pense que vous aviez compris ...

[catwell.info]

Poste le Saturday 4 March 2006 21:24:24

Je m'en doutais un peu oui, celà dit mettre en évidence ce genre de situation demande plutôt plus de théorie que moins, parce qu'en se fondant sur l'expérience, il est facile d'obtenir des résultats trompeurs.

Citation
AlSim
Bien sûr qu'à un moment il faut apprendre comme ça, mais avoir des bases expérimentales de ce qu'est une instruction, une boucle, une procédure, ça aide quand même beaucoup.

Pour celà le mieux reste de faire de la simulation d'algorithme sur papier, bien sur c'est long et pas franchement passionnant, mais je pense que c'est comme ça qu'on comprend le mieux ce que fait la machine : en le faisant à sa place.

Poste le Sunday 5 March 2006 02:48:31

Citation
menelrandir
C'est même toujours le cas, je dirais que tout est toujours préférable à une exponentielle.

Même la fonction d’Ackermann ?
Il y a des fonctions qui croissent encore plus vite que l’exponentielle.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Sunday 5 March 2006 06:58:54

Oui, mais c'est quand même rare de trouver des algorithmes de complexité supérieure à l'exponentielle (pour Ackermann il faut utiliser des hyper-opérateurs pour donner sa valeur explicite) ...
A propos d'Ackermann, et pour revenir (un peu) dans le sujet, j'ai comparé les résultats obtenus en Python (interprété) et en Pascal (compilé) pour son calcul (récursif) (oui j'aime beaucoup les parenthèses, pourtant je ne fais pas de LISP ^o^) et le résultat est sans appel : Pascal va beaucoup plus vite.

[catwell.info]

Poste le Sunday 5 March 2006 09:59:27

alors 2 tests pour rendre le tout comparable :
- as tu "compilé" le prog python ? (histoire d'utiliser le bytecode *.pyc généré par ex au premier run plutôt que l'interprétation qui sera nécessairement la plus lente des opérations)

-as tu essayé de freezer le code python ? (génération de code machine)

tu verras que les résultats changent énormément. Avec du python freezé, on atteint la vitesse d'execution du C++ (faut dire que l'opération transforme tout le code en C++ avant de le compiler). Après, ça dépend du compilateur pascal et du compilateur C++ utilisé. Mais comparer un langage de script avec un langage compilé, ça n'a -àmha- pas de sens.

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Poste le Sunday 5 March 2006 14:46:23

Citation
nicola
menelrandir a écrit :
C'est même toujours le cas, je dirais que tout est
toujours préférable à une exponentielle.

Même la fonction d’Ackermann ?
Il y a des fonctions qui croissent encore plus
vite que l’exponentielle.

Effectivement, c'est un oubli de ma part, mais si ma mémoire est bonne (ce qui n'est pas certain bien sur) la fonction d'Ackermann peut se voir comme une exponentielle itérée de base 2 (la simplification est peut être abusive), ne pourrait on donc pas considérer que la fonction d'Ackermann est une "forme d'exponentielle", même si ce n'est pas très rigoureux ?

Poste le Sunday 5 March 2006 17:05:19

Non, la fonction d'Ackermann est le cas (d'école) qui est bien pire qu'exponentielle.

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Sunday 5 March 2006 17:28:10

Une exponentielle est un hyper-opérateur de degré 3, la fonctin d'Ackermann fait varier le degré de l'hyper-opérateur (il est égal au premier paramètre) ! Ainsi, Ackermann(3,n) a une complexité exponentielle. En fait, la définition explicite d'Ackermann est (j'espère ne pas me tromper mais ça y ressemble) :

Ackermann(X,n)=Hyper2,(n+3)-3)

Que vous préférez peut-être comme ça :

Ackermann(X,n)=2 ^[^]X[/^] (n+3)-3

Pour tuxfanch : j'ai essayé avec freeze, mais il ne semble pas accepter setrecursionlimit, ce qui m'empêche de tester. Si tu as une solution ...

[catwell.info]

Poste le Sunday 5 March 2006 18:12:11

Citation
AlSim
En fait, la définition
explicite d'Ackermann est (j'espère ne pas me
tromper mais ça y ressemble) :

Ackermann(X,n)=Hyper2,(n+3)-3)

Que vous préférez peut-être comme ça :

Ackermann(X,n)=2 ^X (n+3)-3

Merci pour cette définition, je ne connaissais que la définition par cas.

Par contre n'y aurait-il pas une erreur de parenthèses dans la première expression, parce qu'ici le (n+3)-3 me semble strictement équivalent à un simple n ?

Poste le Sunday 5 March 2006 19:07:39

Oui, tu as raison, c'est plutôt ça :

Ackermann(X,n)=Hyper2,(n+3))-3

Et la seconde est fausse aussi d'ailleurs (j'ai du mal avec cette notation que je trouve moins pratique), c'est :


Ackermann(X,n)=2 ^[^](X-2)[/^] (n+3)-3 pour X>1
Ackermann(1,n)=2+n
Ackermann(2,n)=2n+3

[catwell.info]

Poste le Sunday 5 March 2006 19:26:30

Citation
AlSim
j'ai essayé avec freeze, mais il ne semble pas accepter setrecursionlimit, ce qui m'empêche de tester. Si tu as une solution ...

Oui, pis j'ai eu des soucis avec sur amd64. Le mieux est d'utiliser cx_Freeze :
[starship.python.net]

mais il continue à charger la lib python et du coup c'est franchement lent par rapport à du cpp.

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Poste le Sunday 5 March 2006 19:50:22

je veux compiler mon proger qui et une bibliotheque dans la quell
je doi
ajouter un livre
afficher les livre de la biblio
suprimer un emprunt de livre
ajouter un emprunt de livre
afficher pour chaque etudient qui donne le numero de sa carte les livre qui il a emprinter
verifiersi un livre a ete emprunter
trier les livre
.....
en utilison les fonction et les pointeur

..
.
.
.pour meder envoier un @ a mon adresse
fouratii@voila.fr

Poste le Tuesday 14 March 2006 21:59:04

je dirais qu'il te faudra ... des pointeurs, des fonctions, des structures ...

Ca sent comme une application directe du cours ton affaire ...

------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

Poste le Wednesday 15 March 2006 00:45:17

Bonjour ,


Vs ne me connaissez , je suis élève ingénieur , et je travaille sur un projet avec mon équipe . Mais ce projet piètine car on a pas encore trouvé de fonction en c , qui puisse générer un nombre aléatoire de 1 à 10 . Merci de m'aider .

J'espère que vs allez prendre mon mail en concidération ,si vs ne pouvez m'aider vs pouvez éventuellement me mettre en contact avec des personnes qui puissent faire qqc pr ns.

Cordialement.

Poste le Thursday 9 November 2006 23:01:54

Utilise la fonction lrand48() et reflechis à comment l'utiliser pour en faire un dé.

RTFM

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Friday 10 November 2006 07:35:55