Astro et programmation

['Bruno]

ATTENTION ATTENTION : J'AI REMONTÉ CE SUJET VIEUX DE QUATRE ANS POUR DONNER DES NOUVELLES. INUTILE DE RÉPONDRE À MA QUESTION DE DÉPART ! LA DISCUSSION DOIT SE POURSUIVRE EN BAS DE LA PAGE (là on est le 16/09/2015).

 

Je ne sais pas trop où le poster alors je le poste ici...

 

Ça fait des années que je voudrais créer deux ou trois choses en rapport avec l'astro et nécessitant de la programmation. Le peu que j'ai fait jusqu'à présent ne me satisfait pas.

 

Exemple 1 : ça --> http://astrosurf.com/bsalque/cartes.htm . Ce sont des cartes à imprimer pour repérer les objets, faites comme les cartes d'étoiles variables en plusieurs échelles. Pour moi c'est l'idéal : on choisit les cartes utiles, on les met dans sa poche (moins encombrant qu'un atlas) et une seule carte suffit grâce aux échelles différentes.

 

J'ai fait ça en Fortran, parce que j'ai le GNU Fortran sur l'ordinateur, mais le programme génère d'abord un fichier en Postscript (j'ai dû apprendre les bases du Postscript, pas évident...) que je traduis ensuite en PDF via l'utilitaire ps2pdf. Ouf ! Franchement, c'est quand même tordu...

 

Un autre problème, c'est que je ne sais pas paramétrer la taille du dessin en Postscript. Apparemment c'est bloqué à une certaine valeur... Or un autre projet, c'est de générer des cartes détaillées en PDF au format A1 pour éventuellement en faire des espèces de cartes routières (j'imagine une carte de l'amas Virgo...)

 

J'aimerais faire ça de façon plus "naturelle" (je prévois aussi d'automatiser le processus : le programme lirait un fichier contenant les coordonnées de tous les NGC et générerait automatiquement les cartes en rafale...). Il me faudrait donc un langage de programmation qui crée des graphiques vectoriels en PDF (ou, au pire, en Postscript). D'autant que quand je prétendais connaître la base du Postscript, c'est vraiment pas grand chose...

 

Exemple 2 : ça --> http://astrosurf.com/bsalque/Atlas/002.pdf . Je me suis fait un petit atlas complet avec la même technique poussive. Mais j'aimerais bien placer la Voie Lactée ou diverses nébuleuses, mettre de la couleur, sortir du cadre restreint du format A4, bref, peaufiner tout ça, et je n'en ai pas les moyens.

 

Quand j'étais étudiant, j'avais appris à utiliser une bibliothèque graphique qui faisait ça très bien : on devait d'abord ouvrir le mode graphique, et à l'ouverture on entrait un paramètre qui indiquait où s'écrivait le dessin : à l'écran - auquel cas il affichait le dessin - ou dans un fichier - auquel cas il générait un fichier Postscript. C'est ça qu'il me faudrait ! (Il y a longtemps, j'avais utilisé une bibliothèque graphique pour le GNU Fortran, mais elle faisait juste de l'affichage à l'écran, or ma finalité est le dessin sur papier - l'écran servant juste à contrôler (quoique, si je pouvais également utiliser le dessin à l'écran pour déplacer les noms des objets avant l'impression, un peu comme le fait Coelix, ce serait pratique)).

 

Une autre chose qui me serait utile, c'est de lire et de créer des images, par exemple des fichiers BMP. J'aimerais bien une fonction "lire-bmp" qui prendrait en entrée un nom de fichier et retournerait en sortie un tableau de taille adéquate contenant les valeurs des pixels de l'image, ce qui permettrait de la manipuler. Inversement, il faudrait ensuite disposer d'un "écrire-bmp".

 

Ces derniers jours j'ai essayé de voir du côté des langages de programmation connus, mais je crois que ce sont des usines à gaz. J'ai essayé courageusement d'apprendre le Visual Basic, mais c'est complètement hors sujet, et ça a une logique trop différente de la mienne. La base, ce sont des explications en long et en large de comment manipuler les fenêtres, les champs à remplir, les bouton "OK", fouyouyouye... Et puis au lieu de taper des lignes de code, on clique partout, fouyouyouye... De plus je n'ai pas l'impression que ma fonction "lire-bmp" existe ou que la création de fichier PDF (ou Postscript) soit possible (je suppose que si, mais je n'ai pas trouvé, donc ça doit être coton). J'avais acheté un gros bouquin sur Visual C++ il y a pas mal d'années et en le feuilletant je n'ai pas non plus trouvé ce que je cherche. Et puis il s'agit de programmation objet et je n'en ai jamais fait.

 

Bref, est-ce que l'un de vous pourrait me donner des idées, par exemple m'indiquer si une bibliothèque graphique complète + un langage GNU tout bête existent, sans être une usine à gaz et sans être trop compliqué ? Ou bien est-ce que je cherche le beurre et l'argent du beurre ?

Modifié 16 septembre 2015 par 'Bruno

[PZAWA]

Salut,

 

Selon moi l’idéal pour toi serai d'apprendre un langage de programmation populaire avec lequel tu auras le plus de chance de trouver des bibliothèques qui te permettrons de générer "facilement" ce que tu veux (images vectoriels/brutes, postscript, création pdf etc).

Il y a bien sur le C++ avec lequel tu sera certain de trouver des bibliothèques appropriées mais sa complexité (relative) pourrait peut-être te rebuter.

Dans ce cas, Java ou C# sont des langages objets populaires plus "naturel" que le C/C++ et avec lesquelles tu trouveras également des bibliothèques qui répondrons a tes besoins.

 

Mes dans tout les cas, il te faudra faire un petit effort d'apprentissage du langage que tu auras choisit.

Mais Il me semble que tu as manipulée l'Amstrad CPC avec du BASIC ? Dans ce cas je te rassure: ce sera plus facile

[gerard33]

Salut Bruno

Coelix pour ses impressions de cartes se sert des bibliothèques ghostscript

cela se présente sous forme d'une imprimante virtuelle avec son interface visuelle Gsview

c'est là

si tu as pratiqué le basic Amstrad, tu devrais t'acclimater à Delphi ou son clone libre Lazarus

ensuite c'est tout bêtement la méthode print qui est utilisée sur le canvas de GS, comme une imprimante normale

bon, maintenant, est-ce que cela vaut le coup de passer des mois à acquérir un langage alors que pour 20 ou 25 $ tu as Coelix (qui contient GSview) et dont les impressions vont du A4 au A0?

langage GNU tout bête existent, sans être une usine à gaz

ah! sais-tu que le papa Noël...c'est délicat à dire...ah...

['Bruno]

J'ai connu pas mal de langages de programmation, notamment durant mes études, mais des langages un peu "brutes", disons (liés à MS-DOS ou Unix, en mode console, adaptés à des calculs mais pas forcément à des graphiques, à part la bibliothèque dont je parlais plus haut - mais c'était sur les ordinateurs de la fac., pas sur le mien...) Donc ce n'est pas un problème de langage - à condition qu'il soit simple, genre Fortran, Pascal ou C, mais pas un langage objet ou un langage spécifique à Windows comme Visual Basic - mais plutôt de bibliothèque graphique (forcément liée à un langage évidemment...)

 

Je ne savais pas que Coelix faisait de l'impression A0 (pourtant je le possède, celui-là), ça pourrait effectivement simplifier les choses. Cela dit j'aime bien programmer, en particulier pour faire les choses à ma façon. (Un peu comme les astrophotographes qui feraient mieux de télécharger les photos du site d'Hubble plutôt que dépenser 5000 € en matos... )

 

Je vais regarder ce qu'est la bibliothèque Ghostscript, cette histoire d'imprimante virtuelle semble aller dans le sens que je recherche, merci Gérard pour l'info !

 

--------

Je viens de faire une recherche sur Ghostscript, c'est sans doute ce que je recherche : « A set of C procedures (the Ghostscript library) that implement the graphics and filtering (data compression / decompression / conversion) capabilities that appear as primitive operations in the PostScript language and in PDF. » : voilà, c'est ça ! Et puis le langage C, même si je n'y ai plus touché depuis pas loin de dix ans, j'avais quand même appris la base (le C, pas le C++). Il y a de la documentation ici : http://pages.cs.wisc.edu/~ghost/ , je vais regarder attentivement...

Modifié 4 mai 2011 par 'Bruno

[Sendell]

Je m'étais lancé dans la création d'un mashup mélangeant GoogleEarth, Flickr, ... mais les limitations de GoogleEarth étaient trop importantes pour ce que je voulais... je m'étais quand même bien amusé ! http://sky.sendell.com/page.php

Sinon comme biblio graphique pas trop lourde et qui devrait répondre à tes besoins j'avais utilisé la LibSDL pour des développements en C, ça tenait pas mal la route.

 

Sinon apprendre l'objet ce n'est qu'un mauvais moment à passer.. si tu fais du C t'as déjà vécu ça avec les pointeurs : on galère un peu au début le temps de bien saisir le principe, après on y pense plus et on ne sait pas s'en passer !

[jgricourt]

Je trouve pas mal ce que tu avais fait en Fortran, je ne sais pas si il est simple à produire mais le résultat est de qualité. Pour moi la difficulté n'est pas tant de maîtriser les langages (j'en ai appris un paquet par mon métier) mais plutôt les techniques pour obtenir des cartes lisibles et exploitables comme les différentes projections d'une sphère sur un plan, la labélisation harmonieuse des objets, l'exploitation de bases de donnée cohérentes d'objets etc ... Sinon si une solution prête à l'emploi existe je préfère l'exploiter plutôt que de me lancer dans un nième projet de cartographie stellaire.

 

D'ailleurs ta démarche pour produire tes cartes est assé similaire à celle de PP3 le logiciel de carto entièrement personnalisable utilisé dans Wikipédia qui produit du LaTeX pour ensuite être transformé en PDF avec n'importe quel processeur LaTeX.

[Leimury]

Je ne sais pas trop où le poster alors je le poste ici...

 

Ça fait des années que je voudrais créer deux ou trois choses en rapport avec l'astro et nécessitant de la programmation. Le peu que j'ai fait jusqu'à présent ne me satisfait pas.

 

Bref' date=' est-ce que l'un de vous pourrait me donner des idées, par exemple m'indiquer si une bibliothèque graphique complète + un langage GNU tout bête existent, sans être une usine à gaz et sans être trop compliqué ? Ou bien est-ce que je cherche le beurre et l'argent du beurre ?[/quote']

 

Si tu as su te démerder avec postscript, ce sera de la gnognotte à côté.

 

M'est avis qu'on peut écrire de bons softs avec n'importe quel langage et sur n'importe quel OS (même sur Mac).

Par contre la difficulté c'est de produire un machin dont tout le monde puisse tirer partie.

 

Tu veux un truc interplateforme qui permette de s'afficher et s'imprimer autant sur du tux, du windows que sur du Mac ?

 

Jettes voir un oeil à SVG.

C'est ouvert, tu as la notion d'objets, de paramètres et c'est du dessin vectoriel avec gradients et gestion avancée du texte.

Une sorte de postscript ou PDF en plus ouvert.

 

Là tu fais ton truc en Fortran, sous forme d'applet java si tu veux l'intégrer dans un site...

Peu importe.

 

Jettes voir aussi un oeil à java (avec Netbeans comme environnement de dev).

Y'a pas plus gentil avec les machines.

Le même machin qui tourne autant sur PC , sous Tux, sur windows et même sur phones sans avoir à recompiler ou fournir plusieurs versions.

Ty li veut dans la page web ? Les applet sont faites pour ça (c'est pas du flash, ça tourne partout).

Le SVG peut s'afficher et se traiter de plein de façons différentes et il a l'avantage d'être très ouvert et bien documenté.

Tu produis du texte, ça s'affiche, ça s'imprime, ça se voit direct dans le navigateur...

 

Java et SVG c'est mignon tout plein

Là tu pars sur un truc executable et visualisable sur n'importe quelle plateforme

 

T'as aussi le C# et autres machins# en théorie mais là c'est le bazar côté implémentation inter-plateformes dès que tu cherches à afficher des boutons ou gérer une quelconque interface.

Swing de java c'est pas joli mais c'est poli.

 

Bon ciel

Modifié 4 mai 2011 par Leimury

[Eric S]

Jettes voir un oeil à SVG.

 

+1. Quand je veux exporter en vectoriel depuis mes programmes écrits en Delphi, j'utilise le SVG. Ensuite, j'ouvre les fichiers avec InkScape (ou Illustrator en commercial) pour les modifier, les imprimer ou les passer en pdf.

['Bruno]

Si tu as su te démerder avec postscript, ce sera de la gnognotte à côté.

Sauf que c'était vraiment la base : faire des traits, des ronds, les remplir, etc. Mais je ne sais même pas sortir du format A4... Mais bon, le problème est surtout que je n'arrive pas à trouver sur Internet de cours de Postscript qui me convienne. (Par exemple je suis sûr qu'il existe une commande pour tracer une ellipse, je ne l'ai pas trouvée, du coup j'ai tracé les ellipses segment par segment...)

 

Tu veux un truc interplateforme qui permette de s'afficher et s'imprimer autant sur du tux, du windows que sur du Mac ?

En fait ce n'est pas mon souci. La finalité, c'est le document papier. Le programme n'est qu'un outil pour le fabriquer. (Cela dit, l'idée de générer automatiquement une carte à partir de ma page Web m'intéresserait, mais pour l'instant je n'ai aucune idée de comment on fait, donc ce n'est pas vraiment un souci, c'est la cerise sur le gâteau mais je souhaite surtout faire le gâteau). Le but n'est pas d'écrire un logiciel final mais un petit programme qui générera l'atlas final.

 

Bon, je regarderai SVG, on verra...

 

----

Je viens de regarder rapidement : SVG est un format, comme Postscript ou PDF, donc je devrais écrire un programme qui génère un fichier SVG comme je faisais en Postscript. OK, ça me convient, ça a l'avantage de me laisser libre d'utiliser le langage que je préfère. Par contre j'aimerais bien au final du PDF, parce que c'est le format standard, or ça a l'air assez compliqué de faire la conversion (la documentation que j'ai lue préconise de faire une copie d'écran...) Sinon, est-ce que vous connaissez un site avec une documentation complète (heu..., et en français...) ? (C'est pour me faire gagner du temps, parce que j'ai vraiment du mal à trouver les documentations de ces machins là...)

 

----

Ah, j'ai trouvé une documentation complète de SDL ( http://www.libsdl.org/docs.php ), du coup c'est lui qui tient la corde. Reste à voir comment l'intégrer à GNU C. Quelqu'un l'a déjà fait ?

 

----

Ça se complique. Ce que je connaissais, c'était les bibliothèques qu'on ajoutait dans le répertoire des bibliothèques du langage et qu'il suffisait d'appeler par un #include. Là, la documentation parle d'environnement et cite des machins que je ne connais pas... Ça n'a pas l'air si simple...

Modifié 4 mai 2011 par 'Bruno

[gerard33]

Par contre j'aimerais bien au final du PDF, parce que c'est le format standard, or ça a l'air assez compliqué de faire la conversion (la documentation que j'ai lue préconise de faire une copie d'écran...)

tu installe un pilote virtuel gratos "Primopdf" et tu fais directement tes impressions dessus

c'est lui qui fera les conversions

['Bruno]

Pour moi la difficulté n'est pas tant de maîtriser les langages (j'en ai appris un paquet par mon métier) mais plutôt les techniques pour obtenir des cartes lisibles et exploitables

Ben pour moi c'est tout le contraire !

 

Je n'ai toujours pas trouvé si on peut intégrer SDL à GNU C (et comment - c'est ça l'aide dont j'ai besoin : si vous l'avez fait, racontez-moi...). Dommage, pour une fois j'avais une documentation complète (par exemple, vous allez rire, et pourtant j'ai cherché : je n'ai jamais trouvé sur Internet la documentation de la bibliothèque standard du C, c'est-à-dire la liste des fonctions avec les types d'arguments, où les #includer et ce qu'elles réalisent (*), et de même je n'ai jamais trouvé la liste complète des fonctions en Postscript - par exemple je ne sais tracer une ellipse qu'en la faisant segment par segment, alors que je suis sûr qu'il doit exister une fonction pour ça).

 

(Aujourd'hui, je crois qu'il vaut mieux que je reste sur le Postscript, parce que tout le reste m'a l'air compliqué. Finalement le challenge va être de trouver sa documentation complète...)

 

-----

(*) Je n'ai peut-être pas assez bien cherché, mais par contre j'ai trouvé sur plusieurs sites la liste des fonctions intrinsèques du Fortran (c'est analogue). Comme si pour le C c'était top secret... (ou plutôt comme si personne ne l'utilisait ?)

Modifié 7 mai 2011 par 'Bruno

[gerard33]

un truc auquel je n'avais pas pensé: le PHP!

c'est simple (pour toi qui as codé en Pascal), multiplateforme, beaucoup d'aide en ligne

et il gère complètement le PostScript

il me semble même qu'il y a des extensions pour le PDF

[Leimury]

(*) Je n'ai peut-être pas assez bien cherché' date=' mais par contre j'ai trouvé sur plusieurs sites la liste des fonctions intrinsèques du Fortran (c'est analogue). Comme si pour le C c'était top secret... (ou plutôt comme si personne ne l'utilisait ?)[/quote']

 

T'as jamais consulté les MSDN ?

http://msdn.microsoft.com/en-us/library/aa983533%28v=VS.71%29.aspx

Tu as tout là dedans

Je cause bien des trucs de base des libs standard du C.

Sous Windows c'est Microsoft qui implémente les librairies de base, normal qu'ils documentent.

Librairie standard C++: http://msdn.microsoft.com/en-us/library/cscc687y%28v=VS.71%29.aspx

 

Sous Tux tu as les Man.

Quelquefois quant tu tapes Man bidule tu te retrouves avec une commande au lieu d'une fonction C.

Avec Man 3 Bidule tu tombes en général sur la fonction C, pas sur autre chose.

Là malheureusement pas de système d'index, tu te sers des différents includes d'un répertoire.

 

Sur Mac... je suis pas encore sorti de la 178e référence après je sais plus quelle recherche (Vivent les CF machin qui ont besoin de CFTruc et qui font appel aux CFBidules... une horreur !).

Je sais plus comment je suis arrivé là ni pour quoi faire

Les docs Apple sont une ignominie datant des années 80 avec des liens qui causent à des liens qui causent à des liens pour faire un ptit truc de rien.

Sous MacOS, tu préfères encore lire les include et leurs commentaires aux docs

 

Bon ciel

['Bruno]

un truc auquel je n'avais pas pensé: le PHP!

Ah, encore une idée... Et on trouve facilement de la documentation dessus. Bon, encore quelque chose à explorer... (Ça répond bien aux besoins indiqués ci-dessus, hein ? Par exemple ça contient des fonctions pour tracer des ellipses, lire des fichiers BMP, créer des fichiers PDF... ?)

 

T'as jamais consulté les MSDN ?

http://msdn.microsoft.com/en-us/libr...=VS.71%29.aspx

Tu as tout là dedans

Je cause bien des trucs de base des libs standard du C.

En fait j'ai cherché avec Google. Bon, je regarderai ça. Tu fais bien de signaler que ce sont les bibliothèques standards du C parce que ça a l'air lié au C de Microsoft. (La blbliothèque standard du C++ contient celle du C ? J'espère, parce programmer en C++, c'est d'un autre niveau, je ne dépasserai pas le C non ++.)

['Bruno]

(SUITE DE LA DISCUSSION ─ LES NOUVELLES)

 

Donc il s'agissait de trouver des outils pour programmer des cartes célestes. Eh bien j'ai trouvé mon bonheur.

 

─ J'ai trouvé Allegro : c'est une bibliothèque pour faire du graphisme, notamment des jeux. Elle existe depuis quinze ans et vous ne la connaissiez donc pas ! Elle est simple à utiliser, ce sont juste des fonctions en C, il n'y a pas besoin de programmation objet ou ce genre de chose trop compliquées pour moi. Fin août, j'ai commencé à écrire un programme qui affiche le ciel à l'écran, puis j'ai fait des ajouts successifs. C'est un vrai bazar, le but est pour l'instant de valider les algorithmes (j'ai dû trouver des astuces pour que l'animation soit fluide malgré le catalogue de 18 millions d'étoiles que j'utilise ─ c'est le PPMX, mais l'UCAC et ses 113 millions d'étoiles me tente...) (*) mais ça marche ! Le programme final aura pour but de simuler le pointage manuel, de mémoriser les cheminements (je me suis un peu entraîné avec, je trouve que c'est une bonne idée). Ainsi les objets du ciel profond ne sont pas représentés par des symboles mais par des taches floues à peine visibles. Si j'arrive au bout du projet, je le mettrai sur ma page Web, mais je ne sais pas comment je ferai pour les données : ça prend plus de 500 Mo qu'il faudra héberger quelque part...

 

─ J'ai trouvé de la doc sur le postscript, et en français (ici http://pierre.blanc38.free.fr/doc/psessen1.pdf et là http://pierre.blanc38.free.fr/doc/psessen2.pdf ). Je sais maintenant comment tracer des ellipses, et j'ai même compris comment faire de l'encapsulated postscript (pour produire des cartes plus petites que le A4, par exemple à insérer dans un document LaTeX). Je prévois de refaire mes cartes, mais plus belles. (Ce langage a des possibilités extraordinaires, il enfonce complètement Allegro et tout ce que j'ai connu avant, mais ce n'est pas la même finalité bien sûr.)

 

Bref, j'ai maintenant tous les outils que je cherchais. (Mais je suis surpris que personne n'ait mentionné Allegro. En fait ça n'a pas l'air très connu, comme si tout le monde préférait les grosses usines à gaz...)

 

-----

(*) Pour donner une idée, une astuce que j'ai prévue (les fichiers .c et .h sont prêts (**)) mais pas encore mise en oeuvre : calculer les fonctions trigo en utilisant des tables, par interpolation linéaire. Ce sont les calculs de cosinus, sinus et compagnie qui génèrent les calculs les plus longs. J'ai fait des tests : avec l'interpolation à partir de tables (calculées une fois pour toutes et mémorisées dans des fichiers), je gagne un facteur 6 (à condition ne pas avoir à m'occuper des quadrants). Par contre je n'ai qu'environ 6 décimales exactes (en degrés). Pour afficher des étoiles à l'écran, c'est amplement suffisant ! C'est quand même marrant : utiliser des tables, comme au temps jadis...

 

(**) En fait je dois les refaire : j'ai voulu finasser avec les quadrants et exploiter les formules trigo, du coup ça m'a rajouté des tests et je ne gagne plus qu'un facteur 2.

Modifié 16 septembre 2015 par 'Bruno

[pascal_meheut]

comme si tout le monde préférait les grosses usines à gaz...

 

Beaucoup de gens, en fait pratiquement tous les étudiants et l'industrie ont fait l'effort d'apprendre ce que tu appelles "les usines à gaz".

 

La raison est qu'une fois qu'on a compris les concepts, c'est très facile et surtout que cela permet de ne plus se préoccuper de toutes les choses que tu vas coder à la main, de faire en 10 min ce qui va te prendre des jours et j'en passe...

 

Comme Leimury l'a déjà dit, il est étonnant de s'émerveiller devant postscript et de rejeter tout que la programmation a produit de puissant et efficace depuis 30 ans. C'est un peu comme si tu étais bloqué en 1985.

 

(*) et (**) : je me demande si tu n'est pas en train de réinventer la roue sur ce point.

[Leimury]

Bonjour,

 

Si c'est pour l'impression, Postscript est tout de même pas mal du tout.

C'est une techno qui a survécu a 26 modes et qui continue de fonctionner sans être partie à la poubelle.

 

Quand à tenir à rester en C sans objets, pourquoi pas ?

Tu as tout à fait raison de tenter l'aventure dans un langage que tu connais bien plutôt qu'en changer sans réelle nécessité.

 

Par contre n'oublies pas que les procs actuels sont en 64 bits, plus en 32.

Même en C de base prends l'habitude de travailler plutôt en 64 bits dans les options de compil.

 

Bruno, si tu veux gagner beaucoup en calcul il faudrait remplacer tous tes réels par des entiers.

Profites des 32 bits(stockage) ou 64 bits(résultats) !

0x7FFFFFFF pour PI en AD et DEC.

Là du coup tes recherches et comparaisons pour les quadrants se feront beaucoup, beaucoup plus vite.

 

Un gros merde pour la suite !

Modifié 16 septembre 2015 par Leimury

['Bruno]

pascal_meheut : quand j'employais le terme "usine à gaz", c'était à prendre avec humour, je ne porte aucun jugement sur ceux qui apprennent ces outils (c'était une façon de dire que c'est trop difficile pour moi). Quant à réinventer la roue, ce n'est pas un problème dans le cadre d'un loisir, c'est la même chose que ceux qui photographient la nébuleuse d'Orion.

 

Leimury : j'ai un peu réfléchi en effet à coder les angles par des entiers. Comme ils vont de -2 milliards et quelques à +2 milliards et quelques, il suffit de tout compter en degrés et de considérer que les 7 derniers chiffres sont des décimales. On aurait alors deux types de nombres : les angles, représentés ainsi, mais aussi les nombres entre -1 et 1 représentés de façon similaire au milliardième (pour arc cosinus et arc sinus). Mais il reste l'arc tangente qui m'embête pas mal (s'il sait fournir un résultat entre 0° et 45°, il fournira les autres, mais avec des considérations de quadrants qui rajouteront des tests). En tout cas ça m'intéresse de réécrire le truc.

 

Pour le 64 bits, ça a l'air d'être le cas par défaut sous Linux (j'ai fait afficher la taille de tous les types, par exemple les pointeurs prennent 8 octets) mais pas sous WIndows 7 (pointeurs de 4 octets), je n'avais pas pensé qu'il pouvait y avoir une option de compilation pour ça, il faudra que je regarde...

 

------

Re. Le coup des tables, c'est subtil : là je viens de refaire les fonctions trigo avec des tables dix fois plus grandes, pour plus de précision. J'ai maintenant une erreur maxi de 2.10^-9 pour le cosinus et le sinus (ce qui est beaucoup trop précis !) mais c'est presque dix fois plus lent qu'avec mes petits tableaux du début (du coup c'est plus lent que le calcul classique), qui étaient dix fois plus petits. Moralité : c'est l'accès au tableau qui prend du temps ! Le problème de ma première version, c'est que les fonctions inverses étaient vraiment imprécises près de 0° ou 90° (selon le cosinus ou le sinus). Il faut donc (pour que ça vaille le coup) n'utiliser les tables que pour les fonctions directes, avec de petites tables. Pas grave, dans les calculs de coordonnées on a une floppée de sinus et cosinus à manipuler, et seulement tout à la fin on appelle une fonction inverse, donc ce sont les sinus et cosinus qu'il faut optimiser. Donc adieu l'idée de tout modéliser par des entiers, et finalement je crois que je vais laisser tomber l'idée des tables tant que j'y suis, c'est trop compliqué.

Modifié 17 septembre 2015 par 'Bruno

[Tannhauser]

Je n'ai rien compris , mais hâte de voir le résultat (même si apparemment, ça va demander des mois de travail au préalable).

 

Bon courage!

[Leimury]

j'ai un peu réfléchi en effet à coder les angles par des entiers. Comme ils vont de -2 milliards et quelques à +2 milliards et quelques' date=' il suffit de tout compter en degrés et de considérer que les 7 derniers chiffres sont des décimales. On aurait alors deux types de nombres : les angles, représentés ainsi, mais aussi les nombres entre -1 et 1 représentés de façon similaire au milliardième (pour arc cosinus et arc sinus). Mais il reste l'arc tangente qui m'embête pas mal (s'il sait fournir un résultat entre 0° et 45°, il fournira les autres, mais avec des considérations de quadrants qui rajouteront des tests). En tout cas ça m'intéresse de réécrire le truc.

 

Pour le 64 bits, ça a l'air d'être le cas par défaut sous Linux (j'ai fait afficher la taille de tous les types, par exemple les pointeurs prennent 8 octets) mais pas sous WIndows 7 (pointeurs de 4 octets), je n'avais pas pensé qu'il pouvait y avoir une option de compilation pour ça, il faudra que je regarde...

[/quote']

 

Bonjour,

 

Si l'idée des entiers te tente pars sur PI=> 0x7FFFFF avec des angles en signé sur 24 bits.

Là, 0x1000000<<2 ça te donne 67Mo pour une table cos/sin avec des valeurs sur 32 bits sans interpolation linéaire.

Dégager l'interpolation linéaire ça fait un paquet de divisions en moins

 

Avec trois octets par angle ça te fait 6 octets pour un couple AD/DEC, tu gagneras pas mal de place en traitant les catalogues.

 

360 / 0x1000000 = 0,000021 degré de précision

['Bruno]

En fait, les essais d'hier soir m'ont montré que la plus grande partie du temps de calcul, c'était le parcours des tableaux. La version 2, qui utilise pourtant uniquement des opérations sur les entiers (dans la version 1 je calculais un coefficient décimal), est devenue six ou sept fois plus lente (j'ai exagéré en parlant de dix ce matin), mais elle utilise des tableaux dix fois plus gros. En fait, d'après mes tests :

─ le calcul d'interpolation proprement dit (sans prendre en compte l'accès au tableau) est 6 fois plus rapide que le calcul d'un sinus ou d'un cosinus avec les fonctions du langage ;

─ avec des tableaux de 18.000 valeurs (angles de 0° à 180° avec pas de 0,01) c'est seulement 2/3 fois plus rapide (j'avais rajouté une gestion des quadrants qui nécessitait des instructions conditionnelles, mais en fait ces instructions sont plus rapides que les calculs) ;

─ avec des tableaux de 180.000 valeurs (angles de 0° à 180° avec pas de 0,001) c'est devenu 3/4 fois plus lent ! (Dommage parce que j'avais une excellente précision.)

 

J'ai fait des tests avec plein d'opérations, il me semble à présent qu'il faut éviter de parcourir des gros tableaux, c'est ça qui prend le plus de temps je crois.

 

Donc là, les tableaux de 16 millions de valeurs que tu proposes, je ne vais pas les tenter. En fait je préfère laisser tomber cette idée. De toute façon ça marche bien. Disons que j'aurais bien aimé avoir plus de marge.

[Leimury]

Quel parcours de tableau ?

Quand tu as tabCos[angle] c'est immédiat, il n'y a aucun parcours.

 

Que ton tableau fasse 126 valeurs ou 16000000 c'est pareil.

C'est de l'accès direct dans une mémoire déjà chargée, pas du séquentiel dans un fichier.

[Eric S]

Là tu arrives sur les problèmes de gestion de base de données. Si tu parcours le tableau contenant toutes les étoiles pour extraire celles qui sont dans ton champ de vision, tu meurs. C'est là qu'interviennent les outils de gestions de base de données. En utilisant des indexes sur les grandeurs qui t'intéressent (RA, Dec et éventuellement la magnitude), ils vont plus facilement extraire les bons éléments sans parcourir tout le catalogue.

 

Ça, c'est la théorie. Pour la pratique, j'avais fait quelques essais avec SpatiaLite (variante de SQLite gérant les coordonnées géographiques) en injectant un catalogue d'étoile (Tycho-2 de mémoire). Et en fait, c'était mauvais. Il faisait toujours un premier tri sur RA puis passait en revue la première sélection et éliminait les étoiles n'ayant pas la bonne Dec ou pas la bonne magnitude. Donc si tu faisais une requête vers le pôle céleste, il conservait tout le catalogue au premier tri et passer toutes les étoiles en revue à l'étape suivante.

 

J'ai alors bricolé mon propre système sachant qu'on travaille sur un catalogue statique. J'ai fixé un nombre maximum d'étoiles qu'on pouvait afficher à la fois. À partir de ça, j'ai fait:

- un index par magnitude croissante des étoiles les plus lumineuses. Cet index est incomplet et ne sert que pour les vues en champ large.

- un index par RA, incomplet aussi car il ne va pas jusqu'au pôle. Cet index est utilisé pour les requêtes en champ serré proches de l'équateur car dans ce cas là, le tri sur la RA est ce qui permet d'éliminer le plus facilement un grand nombre de candidats.

- un index par Dec, incomplet aussi car il part des pôles mais ne va pas jusqu'à l'équateur. Cet index est utilisé pour les requêtes en champ serré proches des pôles car dans ce cas là, le tri sur la Dec est le plus sélectif.

 

La magnitude limite de l'index en magnitude dépend du nombre maximum d'étoile qu'on s'autorise à afficher. Les indexes en RA et Dec ont une zone de recouvrement. La taille de cette zone dépend de la magnitude limite précédente.

 

J'ai programmé ça pour afficher de la carte du ciel sur un PDA. Ça marche pas mal même s'il reste du bug dans certains cas. Voir ici.

 

Sinon, les astronomes professionnels commencent par découper la sphère en un tas de triangles à peu près réguliers et indexent les étoiles et autres objets dans ces triangles.

['Bruno]

(Suite de la discussion technique sur l'optimisation des calculs de coordonées)

 

Leimury : je vais faire des essais en remplaçant les lectures de tableau par des affectations bidon, pour voir la différence.

 

Eric S : je pense en effet que c'est ce genre d'idée qui doit permettre d'améliorer la rapidité. Avec le PPMX, j'ai utilisé des bandes de déclinaison et j'examine d'abord l'AD et la DEC pour savoir si on est dans le champ. Près des pôles, le test d'AD oblige en effet à conserver tout le monde, mais la bande de déclinaison du pôle est très pauvre, donc ça compense.

 

-----

Re. Voici quelques tests :

─ 10 milliards de calcul de cosinus(123.456789°) avec les tables : 1m36.225s.

─ idem en remplaçant l'accès aux tables par des affectations : 1m19.192s.

Donc nous avions tous les deux tort et raison à la fois. Il y a bien un gain, mais pas si important (c'est normal que l'accès à un tableau prenne du temps puisqu'il faut d'abord calculer l'adresse de l'élément, ce qui nécessite une addition, ce n'est pas négligeable à côté d'un calcul qui compte seulement 2 soustractions, 2 multiplications et 2 divisions).

 

Je recommence les tests, je viens de me rendre compte d'un truc qui change tout et que je n'avais pas prévu :

─ Si je calcule 10 milliard de fois cos(x) avec le cos du langage, où x a été initialisé à 2,154727452 radians (c'est 123,456789°), ça lui prend 3m56,295 s. C'est avec ce calcul que j'avais comparé la 1ère version des calculs par table, qui étaient alors plus rapides.

─ Par contre si je calcule 10 milliard de fois cos(2,154727452) directement, ça lui prend seulement 0m27,505 s ! Étonnant ! J'avoue ne pas comprendre. Je me suis dit qu'il a dû stocker la constante 2,154727452 dans le registre, qui est bien plus rapide d'accès, mais ça n'explique pas la rapidité des calculs. À mon avis le compilateur est très malin (j'utilise GNU C) et s'est rendu compte qu'il faisait toujours les mêmes calculs. Bref, comme c'est ce calcul qui m'avait servi de comparaison hier avec la deuxième version, forcément la v2 paraissait bien lente.

 

En faisant attention à ce genre de détail, j'ai à présent les valeurs suivantes (j'ai fait deux tests pour être sûr que ça ne fluctue pas) :

─ calcul de cos(x) pour x = 2,154727452 radians avec le cos du langage : 3m56,295s / 3m56,185 s

─ calcul du tablecos(x) pour x = 123,456789° (c'est le même angle) avec les tables v1 : 2m25,701 s / 2m25,621 s

─ idem avec les tables, mais de la v2 (que des entiers) : 1m36,249s (hier) / 1m36,225s / 1m36,253s.

 

Donc je rechange d'avis : je garde la v2 (sans chercher à raccourcir les tableaux, ça me ferait encore gagner un petit poil mais bof).

 

-----

Et je re-rechange d'avis ! Une autre idée : stocker tan(AD/2) et tan(DEC/2) directement, à la place de AD et DEC (il suffit de les calculer une fois pour toutes lors de la création des fichiers de données). Ainsi le calcul de cos et sin et simplifié, par exemple cos x = (1-t²)/(1+t²) où t = tan(x/2).

─ 10 milliards de calculs de cos(x) avec cette formule : 52,204 s. Yes !

 

Du coup autant aller plus loin : les fichiers de données fournissent directement cos(AD), sin(AD), cos(DEC) et sin(DEC) (c'est eux qui servent en permanence dans les calculs de conversion de coordonnées, et on refait des millions de fois les mêmes calculs en fin de compte).

─ 10 milliards d'affectations : 27,858 s. Je ne pense pas qu'on puisse faire mieux !

Par contre ça va doubler la taille des fichiers de données...

Modifié 17 septembre 2015 par 'Bruno

[Eric S]

Problème classique d'optimisation. Soit on économise la mémoire (ou la bande passante suivant les problèmes) et il faut beaucoup de calcul, soit on économise les calculs et il faut plus de mémoire.

 

─ Par contre si je calcule 10 milliard de fois cos(2,154727452) directement, ça lui prend seulement 0m27,505 s !

 

Le compilateur a du voir que 2,154727452 était une constante et a directement calculé cos(2,154727452) à la compilation.

 

Il existe souvent (suivant compilateur/processeur) une instruction sincos qui calcule à la fois le sinus et le cosinus d'un angle aussi vite que le sinus ou le cosinus seul.

 

Regarde aussi si la fonction atan2 peut t'intéresser (voir autre topic).

 

Si tu précalcules des choses, ça peut aussi valoir le coup de stocker les x, y et z projetés sur la sphère unitaire. Par exemple, si tu veux savoir rapidement si une étoile est à moins de alpha radians du centre de ta vue, tu fais:

x(étoile)*x(centre) + y(étoile)*y(centre) + z(étoile)*z(centre) > cos(alpha)

avec

x(centre), y(centre), z(centre) et cos(alpha) calculés une fois pour tout ton test

et

x(étoile), y(étoile) et z(étoile) stockés dans ton tableau.

['Bruno]

Il existe souvent (suivant compilateur/processeur) une instruction sincos qui calcule à la fois le sinus et le cosinus d'un angle aussi vite que le sinus ou le cosinus seul.

Tout à fait : la bibliothèque mathématique du GNU C est plus fournie que la bibliothèque standard et contient ces fonctions, que je compte utiliser.

 

Regarde aussi si la fonction atan2 peut t'intéresser ( voir autre topic).

Elle est fondamentale. En fait, il n'y a que cinq fonctions trigo d'utiles : cos, sin (dans les formules de trigo sphérique, tan n'intervient jamais), arcsin peut-être, arccos, et arctan2 indispensable.

 

L'astuce des coordonnées x, y, z sur la sphère ne me convainc pas. Déjà parce que ça fait encore des choses à stocker (pour l'instant le tableau complet fait 500 Mo et je dois le stocker en mémoire vive pour éviter de ralentir le programme par des accès au disque dur). Mais aussi parce que je calcule la distance angulaire avec :

cos(distance) = sin b x sin b0 + ( cos b x cos b0 x cos(l - l0))

Si sin b et cos b sont déjà stockés, et sachant que sin b0 et cos b0 ne se calculent qu'une fois, j'ai juste à calculer cos(l - l0) et à faire 4 multiplications et 1 addition. Économiser le calcul de cos(l - l0) ne me paraît pas justifier de doubler les données à stocker. (D'autant que pour la vue à l'oculaire, avec les 18 millions d'étoiles, je fais d'abord un test en AD et DEC, c'est qui élimine la grosse majorité des étoiles).

 

En fait, la vue à l'oculaire utilise très peu de fonctions trigo puisque je fais une projection rectangulaire, donc je pense qu'optimiser les calculs trigo n'apporterait pas grand chose. J'en avais parlé pour illustrer une astuce afin d'accélérer les calculs, mais j'aurais dû donner un autre exemple. Tiens, par exemple pour tenir compte de l'absorption de magnitude en fonction de la hauteur, je dois calculer un log(sin(h)). Comme on n'a pas besoin de faire ce calcul au millionième de magnitude près, et que ce calcul ralentit bien le programme (quand je testais la magnitude avant de tester si l'étoile est dans le champ, le fait de calculer log(sin(h)) pour toutes les étoiles de la bande de déclinaison ralentissait l'animation de façon très nette, donc à présent je teste d'abord si l'étoile est dans le champ avant de tester sa magnitude), autant calculer une fois pour totues log(sin(h)) tous les centièmes de radians de 0,00 à 1,57 et mettre ça dans un tableau de 158 éléments.

[Eric S]

Dans le cas particulier, je me demandais si on ne pouvait pas carrément ne stocker que les x, y et z et pas les sin/cos.

 

Après, ça peut être intéressant d'utiliser un outil de profilage qui va mesurer le temps passé aux différents endroits et peut permettre de déterminer les points durs.

 

Si le champ de vue est réduit, on peut aussi faire pas mal d'approximations linéaires, genre un calcul de sin/cos au centre et développement au premier ordre à proximité (en faisant quand même attention vers les pôles) ou un modèle linéaire de l'atténuation sur la zone.

[Leimury]

Bonjour,

 

Est ce que tu as terminé ton soft ?

 

Méfies toi de l'optimisation trop en amont.

D'abord tu crées tout ton truc et ensuite tu optimises.

['Bruno]

Leimury : j'ai fini de tester et valider les algorithmes. Le programme est moche, il manque les nébuleuses, mais il tourne. Donc je sais ce qui prend du temps. Je suis tout à fait d'accord avec toi qu'il faut optimiser à la fin. En fait, je voudrais le refaire en plus propre, donc je veux optimiser d'abord pour savoir précisément comment le refaire en plus propre.

 

Eric S : à l'oeil nu j'utilise une projection dont j'ignore le nom mais qui utilise la trigo (je calcule la distance angulaire, qui se fait avec un arc cosinus, et l'angle de position, avec un arctan2). Je me suis amusé à les remplacer par des développements limités (dans le but d'utiliser ces développements pour accélérer la vue à l'oculaire), eh bien à l'ordre 2 ça redonne le théorème de Pythagore, c'est-à-dire une projection rectangulaire. J'aurais dû m'en douter...

 

Là où le champ est réduit, l'astuce consiste à calculer uniquement l'azimut et la hauteur du centre de la carte, ainsi que l'angle de position entre la direction du pôle céleste et la direction du zénith. Ainsi, je ne calcule jamais l'azimut et la hauteur des 18 millions d'étoiles : je me contente d'ajouter le delta d'AD et le delta de DEC par rapport au centre de la carte, et de faire une rotation pour compenser l'angle de position. Puis je fais une projection rectangulaire. Sur un petit champ c'est suffisant, et ça permet de ne pas calculer grand chose (il faut calculer des racines carrées, mais c'est très rapide). Mais comme tu le dis, c'est assez problématique près des pôles où je ne peux pas utiliser la projection rectangulaire.

[jgricourt]

Beaucoup de gens, en fait pratiquement tous les étudiants et l'industrie ont fait l'effort d'apprendre ce que tu appelles "les usines à gaz".

 

La raison est qu'une fois qu'on a compris les concepts, c'est très facile et surtout que cela permet de ne plus se préoccuper de toutes les choses que tu vas coder à la main, de faire en 10 min ce qui va te prendre des jours et j'en passe...

 

Comme Leimury l'a déjà dit, il est étonnant de s'émerveiller devant postscript et de rejeter tout que la programmation a produit de puissant et efficace depuis 30 ans. C'est un peu comme si tu étais bloqué en 1985.

 

(*) et (**) : je me demande si tu n'est pas en train de réinventer la roue sur ce point.

 

Tout à fait d'accord Pascal. Sinon le terme "usines à gaz" je le trouve inadéquat concernant les langages objets modernes surtout ceux qui pré-compilent le code pour le rendre presque aussi efficace que du code natif.

 

L'objet reste selon moi l'étape indispensable pour poursuivre des projets d'ampleurs très structurés. Et lorsqu'on a mis le doigt dedans on se demande ensuite comment on faisait avant, que de temps et d’énergie gagné par la suite ... Evidemment pour ne pas faire du procédurale pure avec un langage objet (réflexe du débutant) il faut rapidement intégrer quelques schémas de conception standard (le bouquin Design Pattern est LA référence).

 

Allegro je connaissais, c'est dans les années 90 lorsque j'étais étudiant et que je me perfectionnais dans la programmation C que j'avais récupéré mon premier compilateur C/C++ : le fameux DJGPP pour MSDOS !

 

Une librairie graphique était fournie avec et je me rappel que je m'amusais pas mal avec le mode "VESA" de ma carte graphique (si ça parle aux anciens) ...