enfet je doit preparer un programme de convertion pour passer d´un nombre decimale vers son expression hexadecimale sur qbasic! mais la je ne trouve pas et je bloque completement! si vous pouviez m´aider sa serait gentil de votre part!
![]()
ah le QB... ça me rappelle quand j´était jeune (enfin, plus que maintenant).
Bref, c´est marrant de voir que a sers encore comme langage. Perso, je pense que pour apprendre c´est très bien.
Pour ton problème, je te conseille de procéder de la manière suivante, qui va prendre partit de la manière super simple de gérer les chaines de caractère en QB
Si le nombre que tu veux convertir est dans la variable nb% (% c´est bien les entiers ? ça fait très longtemps que j´ai plus fait de QB).
l´idée est de construire caractère par caractère ta chaine héxadécimale. Là on va la construire à l´envers, mais il suffira de l´inverser après.
tu fait une boucle
do until nb=0
...
loop
Je crois que c´est ça la syntaxe.
Et dans le corps de la boucle (mais je te laisse l´écrire) tu utilise une variable temporaire pour stocker le caractère héxa suivant genre :
temp%=nb% mod 16 ´si c´est pas mod, c´est nb% \ 16
puis tu vire le dernier caractère de nb :
nb%=nb%/16
et là tu mets à la fin d´une chaines hexa$ (par exemple) le caractère qui correspond à la valeur dans temp% (qui est entre 0 et 15).
Quand la boucle se termine ta chaines est construite, il ne te reste plus qu´à la réécrire dans l´autre sens.
(pour toutes les manipulations de chaines de caractère, pense à la fonction mid$).
ah ok
beaucoup
Wah la chance de faire de la programmation en MPI... parce que les amplificatuers opérationnels ça commence à me prendre la tête.
Il serait quand même plus judicieux aujourd´hui de faire travailler les élèves sous ce merveilleux langage (pour sa simplicité et sa puissance) qu´est CAML ![]()
/fan
+1
Je en suis pas sûr.
J´ai beau être fan moi aussi du Caml, déjà en sup il y a la moitié de la classe qui galérait pour comprendre comment ça marchait. Alors en seconde où les bases de logique sont plus faible, ça me semble encore plus dur.
Alors que le QB, je suis vraiment convaincu que pour apprendre à programmer c´est génial. Ensuite, il faut savoir passer à autre chose (quelqu´un à dit VB ?) , mais pour débuter je pense que de l´impératif est nettement plus simple et intuitif pour des débutant (et là, je crois que le QB se défend bien par son produit simplicité*capacité face à d´autres langages, C y compris).
J´ai écrit ça hier soir ; je pense que t´as eu le temps de trouver (tueur du Val-d´Oise), considère ça comme une correction (même si ce n´est pas terrible, on peut faire plus court et plus rapide, mais là au moins c´est clair) :
http://wall.sectionpc.info/nombre_en_hexa.txt
je suis d´accord, CAML c´est bien, mais pour les matheux.
Parceque la notion de fonction en CAML est EXACTEMENT la notion de fonction en math. Et en seconde les fonctions en math, c´est pas gagné; c´est pas completement le meme sens que celui qu´on voit en seconde.
Le problème de CAML en sup, c´est qu´il faut apprendre le langage CAML + l´algorithmie fondamentale en 30-40 heures de cour...
Hors les structures fondamentales de CAML son très simples et bien moins déroutante que ce que l´on trouve en qbasic.
"je suis d´accord, CAML c´est bien, mais pour les matheux.
Parceque la notion de fonction en CAML est EXACTEMENT la notion de fonction en math."
C´est justement ca la merveille de la chose : une fonction CAML est une variable COMME UNE AUTRE. Pas d´histoire d´objet particulier, régit par des règles bizarres, voire de pointeur comme en C.
C´est cette architecture unifiée qui fait la puissance et la simplicité de CAML.
C´est vrai qu´aborder CAML après avoir fait du C par exemple, est déroutant : ou sont les pointeurs ? etc...
Mais il faut juste réapprendre à penser simplement.
En tout cas, CAML ça a l´air bien, je ne connais pas très bien encore, sachant que je suis en train de l´apprendre (quand j´ai un peu de temps par ci par là). Ca sera ça de moins à faire pour ma sup ![]()
le problème en l´occurence est que quand tu es en secondes, je ne suis pas bien sur que tu es bien a même de comprendre ce qu´est une fonction.
Apres, je suis bien d´accord que le CAML est un langage tres interessant auquel je me met activement. Mais je ne penses pas que c´est ce que tu cherches quand tu fais de l´informatique...
Il faut savoir que je ne cherche pas à faire des jeux vidéos ou tout autre chose de ce genre.
"je ne suis pas bien sur que tu es bien a même de comprendre ce qu´est une fonction. "
-> Non, la plupart des élèves ne le comprennant pas.
Mais tu fais pas MPI pour devenir boucher charcutier.
comprennant -> comprennent
Par contre pour ce qui est des jeux en Caml, on m´avait récemment prouvé le contraire. Et le prof d´Haskell de mon père était persuadé qu´ils "avaient 300 ans d´avance" (enfin je suis pas sûr du nombre d´années).
Alors faut bien les former les secondes, de toute façon.
ah, oui, c´est sur il faut les former, je ne dis pas le contraire...
Mais CAML ca me semble peu adapté a ce niveau d´étude. Basic et C, me semblent bien plus indiqué.
Personellement, je n´aurais pas aimé commencer l´informatique par du CAML.
Pour les jeux... je ne suis pas entierement convaincu par CAML, c´est de trop haut niveau, tu as vachment de mal a aller optimiser ton code de rendu...
Tu as moins la main sur ton code, tu ne peux pas dire, allouer tel objet a tel endroit du heap, mettre ces tableaux contigue en mémoire...
L´avantage de CAML, c´ets l´abstraction vis à vis du support matériel : pointeurs, allocation de mémoire etc...
C´est un lanage de haut niveau qui reste accessible : typage automatique, garbage collector : moins de bugs et plus de simplicité dans les manipulations d´objets (je ne parle pas en terme de POO ici)
Je pense moi que l´apprentissage de la prog serait plus facile avec CAML, mais bon ce ne sont que des spéculations ![]()
" Basic et C, me semblent bien plus indiqué. "
-> Parce qu´ils permettent d´oublier totalement que l´informatique c´est, à la base, des maths ? Si on veut en faire des bidouilleurs, c´est la meilleure voie à prendre.
(Les performances d´Ocaml sont excellentes. Il arrive même qu´elles n´aient pas grand chose à envier à celles de C++, en présentant un coût humain bien moindre. Il faudrait évoluer, un peu. Mais c´est toujours le même débat.)
lag-it: c´est ce que je pense, oui, c´est de plus haut niveau et c´est difficile je trouve de bien comprendre, "qu´est ce qui se passe?" quand j´ecris du code CAML. Je trouve que ce n´est pas bien clair, cela viendra probablement avec la pratique du CAML.
bigloo: "Parce qu´ils permettent d´oublier totalement que l´informatique c´est, à la base, des maths ?"
Premierement, ce n´est pas a un vieux singe que l´on apprend a faire la grimace.
Ensuite, J´ai pris l´exemple de Basic et C parceque ce sont des langages impératifs. Si tu veux, je prends JAVA, C# c´est pareil.
Quand j´explique comment fonctionne un code C, je peux clairement dire:
"il se passe ca, puis il se passe ca"
En CAML, tu te contrefout de l´ordre d´évaluation de tes opérations (tant qu´il n´y a pas d´effet de bord). Tu n´utilises pas l´ordinateur comme une machine a état. Pourtant c´est ce qu´elle est.
"Les performances d´Ocaml sont excellentes. Il arrive même qu´elles n´aient pas grand chose à envier à celles de C++, en présentant un coût humain bien moindre."
En l´occurence, je me contrefout du cout humain, je penses a du calcul haute performance dans lequel tu peux avoir besoin de placer explicitement des données différente a des zones mémoire proches. Le but est clairement d´éviter des défault de cache, d´éviter les phénomène de swap et cie.
Le gain en performance peut etre colossal sur un simple changmenet du placement mémoire de tes données.
Peut etre qu´un jour les compilateurs seront assez fort pour que la liberté que laisse CAML a son compilateur puisse lui permettre de faire un placement en mémoire plus intelligent que celui produit par le developeur. Actuellement, ce n´est clairement pas le cas.
"Il faudrait évoluer, un peu. Mais c´est toujours le même débat."
Je regarde le débat sous l´angle pédagogique. Des étudiants apres 2 ans de java trouve encore l´informatique magique. Pourtant ils ont écrit chaque ligne de code, ils peuvent prédire EXACTEMENT l´état dans lequel est leur application. Mais ils trouvent ca magique.
Je penses qu´un langage fonctionelle ne les aideraient vraiment pas.
message a dnob700: on s´éloigne fortement du sujet, déplace nous dans un topic blabla si tu le souhaites
oui, c´est plus le sujet, mais là, c´est irréversible (mais si les problème qbasic continu, ce topic est bien sûr toujours là pour killeurdu95).
Pour ce qui est du Caml, je suis assez d´accord avec ce qui a été dit, mais il y a un point qu´on peut voir différement :
Là on reproche au Caml d´être un peu "opaque" dans exécution. Mais ça ne nui pas forcément au performances : il y avait une étude faites je crois par HP (que je n´arrive pas à retrouver, mais si quelqu´un la connait et à un lien) où ils avaient écrit, pour un langage assez spécifique, un interpréteur de pseudo code qui réussissait à exécuter des programme plus rapidement que du code compilé.
Car le gros défaut d´un code compilé est que le compilo ne connait pas vraiment les données que le programme manipulera (et les erreurs de prédictions d´embrenchement coutent énormément de temps au processeur alors que les mécanisme pour éviter ça existent). Mais ce n´est pas le cas de l´interpréteur qui lui connait les données. L´idée était donc de faire optimiser le programme "à la volée".
Mais là, bien sûr c´est moins satisfaisant pour le programmeur car ce n´est plus lui qui optimise son code (et ça ne doit marcher que dans des cas assez particulier quand même).
Et en fait, même sans ça, on peut voir qu´un programme écrit en Caml peut être plus optimisé d´un point de vue de gestion de la mémoire qu´un même programme écrit en C++ (je veux dire que le "compilo" Caml optimise mieux qu´un compilo C++ pour certaines chose, ensuite,ce que peut faire le programmeur est un autre problème). Par exemple, le compilo Caml dérécursifie les fonction récursive terminale (VC++ le fait aussi mais je crois qu´il le fait dans une moindre mesure seulement) ça c´est la base.
Mais là où le Caml est "fort", c´est dans le passage et le retour de valeur. En C++ si on prend les exemples de la STL, il y a un problème qui revient souvent c´est celui des opérateur de recopie : si on renvoie une string par exemple qui est enregistré directement dans une autre même le meilleur compilo ne se contentera jamais "d´inverser" les variables (ou de copier le pointeur de l´encienne à la place de la nouvelle string) mais recopiera au moins une fois l´intégralité de la chaine (si c´est pas plusieurs dans les mauvais cas). Il ne le peut probablement pas (si les variables sont stocké dans la pile d´une fonction, etc. il faut les recopier.). Mais c´est ce que fait Caml, parce que c´est permis par le coté fonctionnel du langage (c´est pour ça que je pense qu´utiliser les fonctionnalités impératives du Caml est une hérésie) où l´on ne stocke jamais réellement des variables, mais uniquement des constantes. (bien sûr, il y a des cas où il est obligé de recopié des grosses structures et là c´est catastrophique (typiquement, on regardait ça en cours avec des arbres l´autre jour, et parfois il les recopie (ça se voit aux performances) lorsqu´un même arbre sers à plusieurs fonctions que l´on appel depuis une même fonction. Même s´il ne sont pas modifié : donc en C++ on aurait pu l´éviter, mais c´est des choses qui peuvent être évité en programmant mieux la même choses).
Enfin, après il faudrait peut-êre étudier l´interpréteur de Caml, pour voir comment il fait pour pouvoir atteindre réellement le bout de cette discution.
pour se raprocher du sujet, je commente juste cette phrase :
"C´est vrai qu´aborder CAML après avoir fait du C par exemple, est déroutant : ou sont les pointeurs ? etc...
Mais il faut juste réapprendre à penser simplement."
C´est justement ce que j´aime bien en QB et en basic en général : il n´y a pas de pointeur et on s´en passe très bien (entre autre). Tout s´écrit naturellement et simplement, sans utiliser les astuces qu´il y a partout en C (en fait je ne vois pas de situation en basique où l´on aurait besoin de "pointeurs", alors qu´en C, j´utilise parfois 3 (ou peut-être même 4) niveau d´indirection ; si quelqu´un a une idée pour me mettre en défaut). Ces langages n´ont vraiment pas la même philosophie et pour aprendre, le basic (par rapport au C, et probablement au Java (mais je ne connais pas) donne vraiment moins de concepts (d´ailleurs le Caml est bien plus proche du basique que du C (pour faire des rapprochements bizarres) et pas vraiment "déroutant" après du Basic).
"(c´est pour ça que je pense qu´utiliser les fonctionnalités impératives du Caml est une hérésie)"
-> Non, contrairement à Scheme où ça ne marche pas, en Caml c´est fait pour être utilisé.
"C´est justement ce que j´aime bien en QB et en basic en général : il n´y a pas de pointeur et on s´en passe très bien (entre autre)"
-> En même temps, c´est le cas de tellement de langages plus performants et intéressants que QB...
"Des étudiants apres 2 ans de java trouve encore l´informatique magique"
-> Soit ils sont mauvais, et ça, bah de les faire bosser sur n´importe quoi produira le même résultat
Soit on leur a mal expliqué
Soit Java est un langage compliqué, et franchement à voir sa tête je pense que c´est ça.
"En CAML, tu te contrefout de l´ordre d´évaluation de tes opérations (tant qu´il n´y a pas d´effet de bord). Tu n´utilises pas l´ordinateur comme une machine a état. Pourtant c´est ce qu´elle est. "
-> En Caml, tu te contrefous de tellement de choses, que tu peux te concentrer sur ton algorithme, et ton algorithme seul. Le C, le C++ et leurs détails pourris et préhistoriques t´obligent à penser à deux choses à la fois.