comment avoir l'esprit de programmation?

[Jack]

Soit.

Pour ma part, je continue à penser que le sdz permet par la variété de ses articles de savoir si on est fait pour faire de l'info et avoir envie d'aller plus loin.
-----

[ansset]

je rejoins tous ceux qui ont mis l'algorithmique en avant.
le langage vient après evidemment.
quand à dire/résumer que l'algorithme c'est une histoire d'équation , donc simplissime , je grimace.
j'ai fait au moins 10 ans de programmation pour les effets spéciaux et les images de synthèse.
je vous assure qu'il faut quand même aligner quelques lignes et que la modélisation fine pour avoir une image réaliste n'est pas chose aisée.
et qu'ensuite il faut être "malin" pour éviter que chaque image ne demande 4H de calcul.

mais le point de départ c'est toujours l'algorithme, quel soit le but.
j'oserai presque dire, avant de vous jeter sur le clavier, commencer par écrire votre raisonnement sur le papier.

[invite14cd8b03]

En ce qui me concerne, je pense avoir pondéré mon point de vue en disant qu'un algo est "toujours simple relativement au problème à traiter".

Le mot "toujours" est peut-être un peu trop catégorique certes... dans un post que l'on essaye de faire court pour que sa lecture ne décourage pas le profane il est parfois difficile d'exprimer les détails de sa pensée...

Mais dans ma phrase, la partie "relativement au problème à traiter" a son importance !

Tu nous parles de programmation dans le domaine de l'image de synthèse... donc, comme tu le soulignes, avec des contraintes de temps de calcul et de réalisme du rendu qui sont, comme tous ceux qui s'intéressent un peu au domaine le savent, deux choses difficiles à concilier entre elles, donc il s'agit d'un problème complexe !

L'algorithme qui en découle sera donc nécessairement complexe... mais du coup la question est : est-il complexe plus à cause de la problématique à traiter ou plus parce-que tu utilises des ruses d'algorithmique pure hors du commun ?
(Question ouverte bien entendu... je ne suis pas un spécialiste du domaine!)

[Garion]

Vous vous êtes déjà arraché les cheveux avec un algorithme ?

Oh oui ! Je suis régulièrement confronté à des problèmes compliqués, je suis même souvent obligé de trouver des heuristiques.

Bon, je suppose que vous avez compris aussi bien que moi ce que veut dire Vost, c'est l'algorithmie donc la logique qui est important, le langage, ce n'est que du domaine de la traduction.

Bien entendu.

[Dlzlogic]

Bonjour,
C'est ce qui fait l'intérêt de notre spécialité.
Mais, moi, j'ai pitié pour ma chevelure, je ne l'agresse que lorsque je n'arrive pas à comprendre pourquoi la machine ne comprend pas exactement ce que j'ai écrit en suivant scrupuleusement le style et la syntaxe du langage que l'utilise.(exemple avec les langages de haut niveau)

[Garion]

Et voila... Encore un particularisateur ...

Possible

Et pourquoi tout de suite (et seulement) la rapidité ?

Parce que c'est ce qu'attendent mes clients. Ce que je veux dire par là, c'est que, par exemple, je me suis retrouvé un jour avec un problème géométrique compliqué : trouver toutes les facettes résultantes de l'intersection de deux polygones quelconques. A l'époque, où j'ai du résoudre cela, internet était très vide. J'ai donc conçu un algorithme à base de trigonométrie qui fonctionnait.
Mais depuis, j'ai trouvé des travaux effectués par des mathématiciens qui résolvaient ça de manière matricielle, et le résultat est des milliers de fois plus rapide que ma méthode.
Au final, mes utilisateurs passent quelques secondes à attendre au lieu de plusieurs minutes (voire plusieurs heures pour les cas les plus gros). Il faut dire que je pouvais avoir des des centaines de milliers d'intersections à calculer.

La sécurité du code, sa portabilité, sa légèreté (au sens utilisation de mémoire vive et/ou d'espace de stockage), sa "réutilisabilité"... peuvent être des critères tout aussi importants...

Oui, mais quand des opérations durent des heures, c'est la vitesse qui est privilégiée. Il faut augmenter la productivité de mes utilisateurs.

Certes certains algos (cryptage, compression, tris divers et variés...) peuvent aboutir à quelque chose d'un peu complexe je le reconnais...
Mais quand on a compris la formule à appliquer, l'algorithme qui la représente est toujours assez simple relativement au problème à traiter... non ?

Non, ce n'est pas toujours si simple. Je travaille dans la simulation thermique dynamique des bâtiments.
Imagine toi, par exemple, une modélisation 3D détaillée complexe d'un quartier entier (des millions de facettes), et que tu dois calculer, pour chaque facette, le pourcentage de soleil et d'ombre que reçoit cette facette pour une position donnée du soleil. Si tu t'y prend mal ça peut durer des heures, si tu t'y prends bien, juste quelques secondes.
J'en suis à réécrire certaines procédures en assembleur pour accélérer la chose (mais ça, il ne faut le faire que quand on est sûr qu'on n'améliore plus l'algo).

Ce qui nous amène à une des citations préférées de mon ancien tuteur : "Ce que l'on conçoit bien s'énonce clairement et les mots pour le dire arrivent aisément."

Oui, mais il y a des choses tellement complexes, que tu ne peux pas arriver à concevoir intégralement, tu ne peux concevoir que le comportement des certaines parties à un instant T, et il est totalement impossible de prévoir ce qui va se passer à grande échelle.
Le problème sur lequel je planche actuellement, c'est à partir d'un modèle 3D censé représenter un quartier (c'est saisi avec le logiciel Sketchup), je dois arriver à reconstituer une série de plan 2D,
de chaque niveau de chaque bâtiment, sachant que les modèles que je récupère ont été saisi avec les pieds par des architectes , et que les volumes ne sont pas forcément bien fermés, que les planchers ne sont pas forcément plats et horizontaux, que les parois verticales, ne le sont pas forcément non plus. C'est une pure heuristique, où je dois jouer continuellement avec des marges d'erreur et faire au mieux pour obtenir ces plans.

[Garion]

C'est ce qui fait l'intérêt de notre spécialité.

Ah oui, c'est super compliqué, mais je prend mon pied à le faire

Mais, moi, j'ai pitié pour ma chevelure, je ne l'agresse que lorsque je n'arrive pas à comprendre pourquoi la machine ne comprend pas exactement ce que j'ai écrit en suivant scrupuleusement le style et la syntaxe du langage que l'utilise.(exemple avec les langages de haut niveau)

Ça arrive aussi, ce sont les bugs que je qualifie de "magiques". Il faut dire que je travaille dans un environnement qui est loin d'être le plus stable (Delphi).
La question est toujours, c'est moi qui déconne ou bien le compilateur. Dans 99.9% des cas, c'est moi, mais dans 0.1%, c'est bien le compilateur, et là, il faut trouver une solution pour contourner.

[Dlzlogic]

Tiens, ce problème de facettes éclairée par le soleil, je l'ai approché un peu il y a quelques années dans le cadre d'une étude faite par un étudiant de la fac d'Aix. Il ne s'agissait que des faces extérieures (murs et toitures), c'est à dire celles éclairées par le soleil.
Les documents de base étaient constitués de 2 fichiers, l'un vectoriel représentant les limites de bâtiment au sol, l'autre raster, qui représentait les altitudes. Il est bien évident que certains obstacles, comme les arbres, constituait une difficulté intéressante, puisqu'il était nécessaire d'obtenir dans tous les cas, l'altitude du terrain, hors végétation et hors construction, d'une part, et une numérisation des toitures, d'autre part.

[Garion]

Pour les arbres, j'ai un scénario de coefficient de transparence mensuels (pour prendre en compte les feuilles caduques).
Cela me complexifie l'algorithme, puisque je dois calculer justement le cumul des différents arbres superposés.
Cela me donne des algos capilotractés qui ont eu raison de ma chevelure avec le temps
(Je suis le développeur principal et le chef de projet du logiciel Pleiades+Comfie, si tu connais).

[Dlzlogic]

Oh, moi je suis en retraite depuis en bout de temps.
Ce truc m'avait intéressé parce qu'il utilisait des techniques que j'avais mises au point début 2000 et qui utilisaient les notions de triangles qui avaient fait l'objet du stage de fin d'étude d'un binôme d'étudiants en 86.
Ce qui est intéressant dans cette spécialité, c'est que rien n'est jamais réellement acquit, il faut chercher, trouver et apprendre tous les jours. En ce qui me concerne, j'approche un domaine tout à fait inconnu pour moi, les réseaux et tout ce qui en découle : je viens de charger un nouveau compilateurs pour avoir des chances que ça marche, beaucoup de choses à apprendre.

[ansset]

bonjour Garion,
pourquoi dois tu ecrires un logiciel "from scratch", alors que les soft 3D actuels font ça très bien.
mais je n'ai certainement pas compris ta problématique.
cordialement.

[Garion]

Mon logiciel est un soft de simulation thermique dynamique de bâtiment. Il y a un grand nombre de données à saisir pour effectuer une simulation.
Nous avons opté (c'était il y a 12 ans), pour une saisie en plan avec affichage en fond des plans originaux au format DWG (Autocad) ou scannés, il n'y a plus alors qu'a redessiner par dessus pour saisir la géométrie mais aussi tous les paramètres de la simulation (caractéristiques thermiques, fenêtres, ventilation, scénarios de fonctionnement, couleur des murs, etc..).
Puis à partir de ces plans, le logiciel reconstruit une 3D pour pouvoir effectuer les calculs qui concernent l'ensoleillement (et bientôt le vent). Nous envoyons ensuite tout ça au moteur de calcul.
Les vrais logiciels de 3D ne permettent que de saisir la géométrie, mais pas le reste, ils sont en plus assez complexe à utiliser et gourmand en temps. Pour finir, ils sont plus cher que notre suite logicielle complète.
Avec notre solution, la saisie est incomparablement plus rapide. Mais maintenant, nos clients nous demandent de pouvoir importer des formats 3D. Nous développons donc des imports vers notre saisie en plan.
Certains formats sont faciles à importer, mais d'autres (comme ceux réalisés avec Sketchup) sont "sales" et difficile à interpréter.

[Dlzlogic]

Bonjour,
Je rebondis juste sur la notion de 3D.
Si on étudie une pièce mécanique, la notion de verticale n'existe pas vraiment, ou même pas du tout. Par contre pour tout ce qui est en relation plus ou moins directe avec la terre, la notion de verticale est partout présente.
Considérant cela, il me parait beaucoup plus intéressant et certainement plus économique de travailler en 2.5D, c'est à dire en 2D avec l'information du Z.
Il n'y a aucune limitation, tant que pour tous les éléments étudiés, la notion de verticale existe et a une signification.
On approche la notion de "surface". On peut définir une surface comme une zone ne pouvant être traversée par une droite verticale qu'un un seul point. Si on doit faire un volume, on crée 2 surfaces superposées. Les surfaces verticales, comme les murs, sont un cas particulier. Il suffit, pour résoudre le problème, de fixer une convention de sens : le côté intérieur et le côté extérieur. En fait, toute surface est munie d'un sens conventionnel qui permet de savoir de quel côté on se trouve.

[ansset]

je ne comprend pas, 3D c'est une réprésentation euclidiènne donc 3 dimensions.
je ne vois pas pourquoi les surfaces verticales pose un problème.
( en fait je ne t'ai pas compris )
cordialement.

[Garion]

je ne comprend pas, 3D c'est une réprésentation euclidiènne donc 3 dimensions.
je ne vois pas pourquoi les surfaces verticales pose un problème.
( en fait je ne t'ai pas compris )
cordialement.

Ben tout dépend de l'utilisateur de Sketchup, d'une part, le logiciel est imprécis (si je demande des coordonnées des différents points d'un plan que je viens de créer, il arrive qu'ils ne soient pas tous strictement égaux (ils doivent stocker avec des réels en single à mon avis), d'autre part, les utilisateurs (des architectes en général) peuvent accidentellement déplacer des points sans s'en rendre compte.
Ca m'a surpris moi aussi quand j'ai commencé à faire l'import, mais c'est comme ça, et je dois faire avec.

[Garion]

Considérant cela, il me parait beaucoup plus intéressant et certainement plus économique de travailler en 2.5D, c'est à dire en 2D avec l'information du Z.

C'est ce qu'on fait, on saisit des plans, et on indique des élévations pour les pans de toiture.

Il n'y a aucune limitation, tant que pour tous les éléments étudiés, la notion de verticale existe et a une signification.

Pour des bâtiments, ça a bien un sens

On approche la notion de "surface". On peut définir une surface comme une zone ne pouvant être traversée par une droite verticale qu'un un seul point. Si on doit faire un volume, on crée 2 surfaces superposées. Les surfaces verticales, comme les murs, sont un cas particulier. Il suffit, pour résoudre le problème, de fixer une convention de sens : le côté intérieur et le côté extérieur. En fait, toute surface est munie d'un sens conventionnel qui permet de savoir de quel côté on se trouve.

C'est comme ça qu'on travaille.

[Dlzlogic]

je ne comprend pas, 3D c'est une réprésentation euclidiènne donc 3 dimensions.
je ne vois pas pourquoi les surfaces verticales pose un problème.
( en fait je ne t'ai pas compris )
cordialement.

Cette distinction entre 2.5D et 3D est un de mes vieux chevaux de bataille.
Il existe une géométrie qui s'appelle la "géométrie cotée".
Le principe est simple, on travaille sur un plan horizontal et les points ont un attribut Z. En fait, on appelle ça une cote Z.
Toutes les distances calculées le sont suivant l'horizontale. En simplifiant, si on veut calculer un volume, on multiplie une superficie (horizontale) par une hauteur.
Cela a des avantages considérables en traitement informatique. Et en plus, on est conforme à la manière officielle de représenter le terrain.
Un certain logiciel que je connais, pour contourner ce problème de surfaces verticales, prévoyait un très léger fruit. Pour mon applicatif, j'ai préféré faire ce que j'ai décrit. Par ailleurs, j'ai lu des thèses sur ce sujet, ils travaillent en 3D. De toute façon c'est un choix et les arguments qu'on m'a donnés ne n'ont pas convaincus (en fait, y'avait pas d'argument).
Avec cette méthode, je génère des objets 3D (lotissement en particulier) réel et sans tricher.
Si ce sujet t'intéresse, je peux développer, mais là on déborde largement le [HS].

PS Donc je suis pas le seul.

[ansset]

je ne me suis absolument pas spécialisé dans l'architecture.
donc je raisonne forcement globalement.
cordialement.