Encore une fois NON.spotlessmind1975 a écrit : ↑18 juil. 2022 09:11Traduire un algorithme de récursif en itératif est toujours possible, sinon "IMPOSSIBLE". Il suffit de remplacer l'appel récursif en insérant et en récupérant des éléments d'une pile implémentée dans n'importe laquelle des structures de données fournies par le langage.
Lisez cet article qui vous contredit en ce qu concerne les performances. Et vous n'avez pas pris le soin de me lire sur les algorithme de tris quick sort, de résolution de labyrinthe, ou même la fonction "remplissage couleur" des logiciels de retouche photo, les algorithme ne peuvent qu'utilser que le récursif. Et pour ce qui est des performance, c'est plus rapide d'utiliser des piles (pour le récursif) que des variables tableaux (ça prend moins de cycle d'horloge).. enfin tout dépend si le processeur prend en charge les instruction de pile (comme c'est le cas du 6809 et sans doutes des proicesseurs 16 ou 32 bits).
Comme je l'ai écrit dans le message précédent, j'avais écrit en Basic avec justement des itération et surtout des tableaux de puiles (on ne peut PAS faire autrement) pour l'algorithme de tri Quick Sort en Basic des Thomson et ça a été très long à développer comparé à la programmation récursive.
Evidemment ces cas sont extrême et dans d'autres cas on préfèrera la méthode itérative (comme par exemple, calculer le résultat d'une suite numérique au rang N, ici on connait les étapes intermédiaires donc on peut utiliser l'itératif (sans les piles donc).
La réponse n'est pas en rapport avec ce que j'ai écrit mais passons...spotlessmind1975 a écrit : ↑18 juil. 2022 09:11J'affirme que les langages génériques (tels que C) fournissent des primitives pour utiliser la mémoire de tas ("heap") au lieu de la pile ("stack"), c'est exactement ce type d'abstraction qui réduit les performances sur les ordinateurs 8 bits, mais pas sur les ordinateurs modernes, qui ont été conçus pour donner des primitives pour la pile ("stack").
Evidemment que j'ai étudié l'itératif et le récursif mais visiblement vous n'avez pas compris l'intérêt de cette programmation et avez décidé de l'occulter... J'ai expliqué ses intérêts plus haut (performance et faciliter de résoudre des problèmes complexe (qui ne peuvent pas être écrit en itératif... Encore une fois le tri "Quick sort" est impossible à résoudre en itératif seul (et sans pile donc).spotlessmind1975 a écrit : ↑18 juil. 2022 09:11Oui c'est vrai, je n'ai pas étudié dans cette école. Je suis allé dans une université plus modeste mais où on m'a appris à utiliser deux outils (itération et récursivité) au lieu d'un, expliquant également les différences. Donc, au final, je pense que ça a marché pour moi.
Je le dis, pour moi quand on utilise des "piles" en itérant c'est identique à du récursif au niveau algorithmique, puisque les fonctions récursives sont basées sur des piles. Mais c'est beaucoup plus difficile à écrire des algorithmes avec piles en itératif qu'en fonction récursive (cf exemple de l'aogorithme de Quick Sort)..
Eh bien je vous met au défi d'écrire ce code en Itératif (et sans Pile donc!). Il est impossible d'écrire un tel algorithme sans piles (sans sauver les états intermédiaires) hors les piles sont justement sur quoi sont basées les fonction récursives. Si dans votre code, vous utilisez des "piles" ça utilise le même principe de codage que les fonctions récursive mais en bcp plus difficile à écrire!.spotlessmind1975 a écrit : ↑18 juil. 2022 09:11Si vous l'écrivez sous une forme itérative, c'est encore plus rapide.
Eh oui, dans"Pascal Base" (sur les thomson), il y a 2 limitations:spotlessmind1975 a écrit : ↑18 juil. 2022 09:11Le langage Pascal (mais aussi C !) Partez de quelques axiomes pris pour acquis. Dans les ordinateurs 8 bits, les développeurs ont littéralement sauté des étapes pour implémenter les contraintes que ces langages imposent, et parfois ils ont compromis sur les performances ou les ressources utilisées, voir la pile ("stack"). Parfois, ils ont décidé de déléguer certaines fonctionnalités à des bibliothèques externes, et parfois ces bibliothèques ("libraries") sont implémentées différemment ou ne sont même pas implémentées. Ils sont partis de vos considérations.
- Pas de variable de type réel
- Zone RAM limité de l'éditeur (quelques dizaines de lignes seulement) du fait de l'implémntation dans la zone Utilisateur du code Pascal pour les Thomson (sans doute pour garder la compatibilité avec les MO5 et TO7/70) alors qu'en Bsic on peut écrire des centaines de lignes de code sur MO6/TO8...
Mais au moins ces compilo Pascal existaient en 8 bits (6 différents pour le C64) et c'est quand même mieux pour produire rapidement des binaires pour chaque machine que l'assembleur.
Eh non vous avez tort! Si l'abstraction est ce qui est donné dans cette définition, je vous donne au moins un exemple, c'est le Basic Microsoft qui a été adopté sur Thomson (6809), MSX (Z80), BBC (6502), Oic (6502) et PC (8088). Mais évidemment chaque machine avait ses propres développeurs mais pour UG Basic êtes vous seul à le développer ?spotlessmind1975 a écrit : ↑18 juil. 2022 09:11Comme vous pouvez l'imaginer, il n'est pas possible d'adopter cette approche à moins de vouloir reproduire les erreurs (en termes de performances et d'utilisation des ressources) de Pascal et C. C'est une approche qui introduit des abstractions, et rend sceptique quant à la possibilité d'un port valide entre différents ordinateurs.
[/qote]
Là ça rejoint les questionnements de Daniel... C'est comme si vous essayez de travailler sur 10 chantier en même temps en appliquant les mêmes normes partout.. Hors c'est pas toujoursn possible parce que chaque terrain est différent. Mais je persiste dans mon raisonnement! Quand vous avez créé et validé une fonction Basic pour une machine, chacun des comuilateur devrait l'adopter pour chaque machine... D'ailleurs vous l'avez partiellement fait entre les MO5 (pas de gate array) et les MO5 (avec Gate Array, donc si vous avez pu le faire pour les architectures matérielles différentes, vous pouvez le faire pour les ROM non ?
Pour la nème fois, je le répère, c'est simplement pour économiser de la RAM! Quand vous réécrivez (à l'identique) des fonctions existant en ROM dans la RAM en assembleur c'est de la place en moins pour le logiciel lui même. Et quand j'ai soumis le petit algorithme pour les animations de Ken et Blanka et quen ça a été confronté à ce probème de RAM (et qu'il fallait déjà utiliser d'autre bank)... Vous dites que les 8 bits sont limités en RAM mais si vous la gaspiller à réécrire des procédure existante dans la ROM. L'écriture complète des caractères et des fonction en mode bm16 est parfaitement justufiée, mais dans les autres modes ? Oui c'est complexe à écrire mais on n'a jamais dit que l'informatque était simple.spotlessmind1975 a écrit : ↑18 juil. 2022 09:11
Je ne comprends pas votre fixation sur les ROM d'origine. Il n'y a pas de norme dans leur fabrication, vous ne pouvez donc pas espérer en trouver beaucoup de réutilisables. Ou qu'il est logique de réutiliser, si vous voulez faire quelque chose de professionnel.
Et pour ce qui est de l'abstraction, on a smeble-t-il pas la même définition de ce c'est, du moins en POO, le noiveau d'abstration fat référence à des niveaux hiérarchique dans des classes. Mais je suppose qu'ici, vous voulez parler du fait qu'une grammaire de langage doit rester la même quelle que soit la machine à compiler... Et justement vous avez dit que certaines des fonction Basic n'exciste pas sur certaines machines donc ça signifie quand même que vous travaillez au cas par cas non ?
Vous essayez de faire valoir que les abstractions ont un sens sur un ordinateur 8 bits, mais hélas, les preuves sont contre.
J'ai suffisamment d'expérience en C pour en connaitre les problématique et limites (j'ai commencé dans les années 90 et j'utilise des langages de types PHP qui ont la mêmes syntaxe que le C mais sans les inconvénients de RAM)... Vous pouvez considérer que j'ai au moins 5 ans d'expérience en C (dans l'étude). Et le C est très limité quant aux possibilité des librairies comparé au Pascal (il n'y a PAS d'équivalent, de bases, aux Unités Graph et CRT par exemple). Eh non il n'y a PAS de base les problèmes de gestion de RAM en Pascal. Les poinyeur en Pascal ont été intriduit tardivement et l'Objet également, mais peut de développeur Delphi utilisent les Objet et de nos jours, les ingénieurs commence enfin à comprendre que le concept objet est un énorme problème à plein de pont de vue! Et que finalement ça a couté des milliard d'euros à des enytreprises d'avoir opté pour cette tecno pour des résultats bien en dessous des attentes comparé à l'ippératif (alors que quand j'ai appris l'objet au début des années 2000 je n'y voyais pas di'ntérêt comparé justement aux pointeurs des langages C et Pascal (pointeurs de variables et de fonctions), c'était exactement la même chose. Les poinyteurs sont un énorme problème dans ces langage s'il n'y a pas de système de gestion de RAM... Le Pascal a un système de ramasse miette (que ça soit pour les pointeurs que pour les objets) qui n'existe pas en C.spotlessmind1975 a écrit : ↑18 juil. 2022 09:11Je ne sais pas combien d'expérience vous avez en C (ça ne semble pas beaucoup) mais le problème de la gestion de la mémoire dynamique est aussi en Pascal, du moins si vous l'utilisez. Si vous utilisez de la mémoire statique, C et Pascal sont équivalents. Comparé au temps qu'il faut pour écrire un logiciel, ce n'est pas une mesure très significative pour les ordinateurs 8 bits. Les outils qui existent aujourd'hui sont des dizaines de fois plus productifs que ceux de l'époque, et Pascal n'est pas une "solution miracle" en ce sens.
Alors certes certaines études montrent que la compilation C donne les binaires les plus rapides existant, mais cela dépend en grande partie de la qualité du compilateur... Un exemple, pour le PHP5 et PHP7, j'avais créé un algorithmede création de permutation (10 éléments) et la version 7 de PHO s'avère être 5 fois plus rapide (eyh oui!!) que la version 5. Peut-être que Free Pascal pêche un peu à ce niveau actuellemement (donnant des binaires 2.5 fois plus lent apparemment) mais Pascal est le langage usant le moins d'espace RAM pour un même algorithme et surtout demandant beaucoup moins de temps de développement parce que c'est justement un langage orthogonal (c'est à dire avec une synthaxe atomique pour une même fonction ce que ne fait pas le C).
En Pascal on peut croire que les tableaux soient limité à 256 éléments mais en fait NON!! puisqu'on peut avoir plusieurs dimensions à un tableau, on peut déclarer, par exemple, un Tableau (voiture[4][255]) pour déclarer un tableau de 4090 éléments et j'ai créé des algorithme capable de gérer ça avec un index de type entier. (on peut avoir un élément en indiquant l'élément :
voiture)
spotlessmind1975 a écrit : ↑18 juil. 2022 09:11
À mon avis, c'est vous qui n'avez pas bien compris de quoi nous parlons. Si vous me dites que vous voulez faire un produit éducatif pour expliquer ce qu'est la 3D, ce que vous écrivez me convient. Si on parle d'un jeu vidéo où il y a des attentes à respecter en termes de qualité et de jouabilité, cela n'a plus beaucoup de sens: Minotaure 3D ne semble jamais dépasser les 10 nœuds, soit l'équivalent de deux tétraèdres, ce qui me semble un peu éloigné de ce dont je parle.
En plus des noeuds des ennemis. Je pense qu'ici (minotaure 3D), ils calcule vraient les position des "sommets" (ou noeud) en trigonométrie (ou en perspective ?). Samuel m'a expliqué le principe de la virgule fixe, en vérité c'est peu différent de l'IEEE754 mais il est vrai que la gestion de la position de la virgule en IEEE754 doit être complexe. C'est une quetsion intéressante à étudier. Voir s'il est possible de directement tracer les sommets d'un labyrinthe 2D vers la 3D, d'ailleurs, ce sont juste des translation de points (verticaux et horizontaux) après tout! Ca reprend le principe de la 3D isomorphique mais en 3D réel...
Comme je l'ai écrit précédemment, il y a certains jeux 3D sur Atari ST qui sont très lent (idem sur Atari Falcon)
On peut faire du "ray casting" en algorithmique parce qu'il y a des contraintes, mais je pense que pour un tétraèdre ou un cube dont on veut faire interragir avec l'utilisateur suivant les 2 angles, là la trigonométrie me parait incontournable.
Quappelez vous de la fausse 3D ? Parce que le Doom avec les Wad sur Atari Falcon est très très lent (moins d'1 image par seconde) qui est pourtant avec un prçocesseur 68030 à 16 MHz et un DSP à 32. Je pense quand même que,les sommet des polygones sont donné via des calculs trigonométrique (ou, peut-être, par des calculs de perspectives, ce qui rejoint le MODE 7 des Super Nintendo et ce que permet le mode Perspective des CSS3). Pour le reste (mapping de texture) c'est entièrement des calculs de perspective comme indiqué ici.