Il s'aligne totalement sur les discours politiques : réduction des droits, chasse aux profiteurs qui vivent des allocations plutôt que d'aller bosser ces fainéants, radiation automatique et sans recours conforme au choc de simplification et à la suppression des postes de fonctionnaires en charge de traiter les dossiers.
On utilise des programmes souvent très optimisés, multithreadés par construction, la transmission des données est bufferisée dans les pipes, on travaille par flux (capacité à traiter de gros volumes de données avec une empreinte mémoire réduite). Tout ça "gratuitement".
Les pipes, c'est quand même une tuerie comme paradigme de programmation (en vrai la notion de coroutine, qui est donc un des éléments importants du langage).
Et avec ça tu mets dans ton rétro pas mal de langages, y compris compilés, en terme de perf.
Ça reste de la banque en ligne. Je suis chez Bourso parce que un conseiller Banque postale essayait de me refiler tout et n'importe quoi. C'est de pire en pire, EdF m'a fait le même coup. D'un autre côté c'est grâce à un autre conseiller que j'ai pu avoir un compte courant sans frais pour des opérations exceptionnelles.
En attendant pour les banques en ligne il faut être totalement autonome et donc avoir des besoins trèèèès basiques. Pour moi, commence à se poser la question inverse, celle d'un vrai conseiller qui puisse orienter dans la gestion des sous…
Vous me faites marrer à discuter de détails informatiques plutôt que de la qualité des services rendus (conseils, disponibilité, offres, etc.)
Ça dépend de ton profil. Si tu t'amuses à sortir des 10k tous les mois en petits coupures tu peux être certain que tous les voyants rouges vont s'allumer. Si tu es une personnalité politique, un dirigeant d'entreprise important, etc. tu seras aussi repéré et traité différemment.
À minima y'a les obligations auprès deS administrationS fiscaleS, les interdits bancaires, etc.
Pourquoi la criminalité organisée et Musk adorent les crypto ?
L'affichage temps réel n'indique pas les transactions réelles. Ça peut être trompeur, selon les cas, car ça ne correspond pas à l'état réel du compte en banque.
Toutes les banques sont temps réel. C'est juste que la date de paiement n'est pas celle que tu crois.
La recherche des fichiers n’est pas si consommatrice. La structure des répertoires est très légères et, sauf le premier accès, va être pauvre en IO. Ce qui va se jouer c’est le syscall (permutation user-kernel mode), et les différents algo. en œuvre pour la résolution du chemin, la vérification des droits, etc. Par défaut, par exemple, la liste des fichiers est très souvent triée dans le monde Unix, au lieu d’être restituée dans l’ordre présent sur le disque (± l’ordre dans lequel ça a été écrit). Il y a de quoi accélérer tout ça, ne pas constamment demander au kernel une résolution de chemin encore faut-il y avoir accès (donc probablement qu’en C ?) et les connaître. Ça demande une compréhension fine du système, un profiler n’est qu’une aide qui ne répond que, très mal, qu’à une partie du problème. Au mieux du mieux, il te donne une piste sur les bouts de code à optimiser. Mais rien ne garantit que ce bout de code n’est pas tout simplement bon à jeter à la poubelle, au lieu de passer du temps dessus pour grapiller quelques pourcents. Ton truc de modifier la structure de tes répertoires, c’est typique d’une fausse bonne idée : un répertoire c’est juste une liste de fichiers, et une liste de 10k éléments (×255 octets / noms de fichiers = 2,55Mo) c’est que dalle à l’heure actuelle. Si t’es limité par une aussi petite liste, c’est clairement que y’a une couille dans ton programme (ie. si t’as un problème d’IOs, c’est parce que tu fais des IOs à tort). Quand t’as 16Go de données, oui là tu peux mettre en place une stratégie de segmentation pour traiter par partie…
Pour SQL c’est encore pire. Dans tous les cas il ne faut pas préjuger du facteur limitant d’une application. Dans ma vie, j’ai connu exactement le contraire. Faut dire que j’ai travaillé sur des applis scientifiques (donc totalement limitées par le calcul) et du traitement batch de données dans la banque/assurance (donc masse de SQL en ce qui me concerne), où un problème d’IO a toujours relevé, très clairement, d’une mauvaise conception : car le principe de base dans mon domaine, c’est un accès/traitement/mise-à-jour totalement séquentiel et linéaire des données (l’enjeu sera de dimensionner correctement capacité de calcul et débits, et dans ce cas cela relève des choix de production). Si tu demandes un accès random, tu vas être à la ramasse sur les IOs, mais ton problème n’est absolument pas un problème d'IOs, le problème c’est l’accès random sur xGo de données…
Dans 99% des cas que je rencontre en pratique, c’est codé avec les pieds, avec un modèle physique de données inadapté (je plaide coupable : je normalise systématiquement pour privilégier la maintenance, ce qui multiplie les jointures…) et le compilateur, CPU, n’y peuvent absolument rien. Remet tes données à plat, maintien un journal des mouvements, traités en batch à postériori, comme on peut le faire dans le monde bancaire, tu va voir que les IOs ne seront plus ton (seul) problème. Ouah t’as optimisé un code sous-optimal ? La bonne affaire ! et si je le vire pour faire la même chose de manière autrement plus efficace ?
Si ton optimisation n'est pas celle du compilo. y'a des chances pour que tu te sois foiré quelque part.
Pour avoir appris sur mon temps libre l'assembleur, je peux dire qu'il n'est pas si difficile d'optimiser un code. La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU (y compris les questions de latence sur les IO car ces accès sont explicites - et on distingue bien un accès en lecture et en écriture).
À partir de là :
L'exercice consiste à étudier la sortie d'un compilo sur du code simple.
Par obligation on est amené à réimplémenter des fonctionnalités très simple. Autre exercice : étudier comment la libc ou autres fait ça.
Spoiler alert : il y'a quantité d'optimisations qui ne sont pas déléguées au compilo. Alors à moins de considérer que les devs de la libc sont des branques…
Trois trucs avec le compilo :
Tu ne le maîtrises pas ni le contrôle. Alors à moins de délivrer qu'un binaire final, tu ne peux préjuger des optimisations appliquées. Les compilos modernes sont devenus horriblement complexes… et LENTS !
À force de déléguer on finit par avoir des CPUs complètement troués parce qu'on pense que la prédiction de branche automatique c'est bien plutôt que de prendre 5s pour signifier au CPU que ce code-ci sera l'exception et l'autre la règle (donc non optimiser un code nécessite pas d'avoir forcément un bagage technique de fou). Sur ce point la causalité est inversée : si c'est le foutoir dans les CPU à tel point qu'un dev n'est pas capable de prédire à l'avance quel code sera performant sur telle machine (manque de prédictibilité du matériel et absence de modèle simple du comportement d'un CPU), c'est bien parce que les concepteurs de CPU y vont chacun de leur petites trouvailles pour obtenir les meilleures perf. malgré du code claqué au sol. On retrouve la même blague sur le nombre de cycle horloge par instructions. Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que… "c'est trop compliqué un CPU".
Ce qui nous amène au dernier point : le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait. Seul l'usager sait ce qu'il va en faire et le boulot d'un dev. c'est aussi d'optimiser son temps, savoir quand et où il a intérêt à lever les automatismes et prendre en charge lui-même les micro-optimisations (car faut-il encore le rappeler une énième fois la micro-optimisation c'est que dalle en terme de gain de performance face aux choix de conception - sélection des algorithmes, arbitrage entre le besoin et les moyens, etc.) C'est pas la compilo qui va te dire si ton algo de tri doit être économe en espace ou en temps, si t'es données sont presque triées ou totalement aléatoire, etc. Il pourra toujours essayer de le deviner mais cela impliquera une surcharge qui ne sera pertinente que sur de gros volumes (information que le compilo ne connaît pas…).
Moi j'aime bien la mise en abîme. Le papier qui est objectivement un torchon finit par être contre-productif tellement il prouve par les faits que ce journal est de la merde en barre.
Quoi les gouvernants achètent la paix sociale par l'exploitation de population étrangères tout en excitant la xénophobie et le racisme des indigènes ! J'étais pas au courant. On me dit jamais rien à moi !
Flemme de tout lire. Y'a eu un gugusse pour parler de la main d'œuvre payée au lance-pierre à l'autre bout du monde ou bien comme d'habitude on continue d'être totalement hors-sol sur ce site ?
et ensuite utiliser des outils de conversion du format LAS (plutôt nuage de points…) en OBJ (surfaces 3D).
C'est tout l'enjeu. Et ce n'est pas une simple conversion de format :
--- transformer les coordonnées cartographiques en coordonnées cartésiennes ;
--- trouver les plus proches voisins de chaque point (ou utiliser un modèle de terrain qui est une grille construite à partir du nuage de points) ;
--- dans le cas de mon algo. estimer le tenseur de courbure, le "diagonaliser", filtrer les points en utilisant valeurs et vecteurs propres comme critères (car ils décrivent localement la surface) ;
--- tesselation pour transformer un nuage de point en un ensemble de surface (c'est très loin d'être trivial) ;
--- sortie finale (renormalisation des coordonnées, conversion dans le format voulu, etc).
Chaque étape fait appel à des algorithmes bien couillus. L'originalité de mon code était la capacité à limiter drastiquement le nombre de faces sans pour autant trop perdre en précision du modèle. C'était déjà critique à l'époque étant donné le volume des données. Avec la résolution atteinte par cette nouvelle campagne Lidar je pense que ça va devenir impossible de faire sans, sauf à se contenter de tuiles ridiculement petites. Ça me donne presque envie de m'y remettre.
Un institut qui produit des cartes de très grandes qualité (les top25 en particulier), un portail grand public (geoportail), plusieurs (?) applications smartphone, tout un tas de données de carto. mis à disposition gratuitement… j'avais utilisé les données Lidar dans un petit projet perso et la précision dans certaines régions était déjà bluffante mais là ça promet du lourd. J'ai malheureusement perdu mon travail mais je ne résiste pas à l'envie de montrer ce qu'on peut faire avec des données de l'ordre du mètre, un "export" dans Blender après optimisation adaptative du modèle :
On est clairement dans de l'écologie de bonne conscience. Tous les cas d'usage présentent de très gros consommateurs. À fortiori car une consommation raisonnée rend inepte ce genre《 d'optimisation 》.
On peut prendre le cas des normes hygiéniques dans l'alimentaire. L'État a face à lui de multiples acteurs. Un《 petit 》n'aura pas les moyens de normes extrêmement strictes. Cependant les conséquences d'une intoxication seront très localisées, le volume de marchandises frelatées étant réduit. De plus si la situation persiste sa réputation sera faite et il fera faillite. Un《 gros 》 lui ne connaîtra pas tout ces mécanismes sociaux de régulation. D'ailleurs dans le temps ce n'était pas naturel de se fournir ainsi, de là l'invention des marques. Par contre il a les moyens de mettre en place des règles strictes. Remarque qu'avec tous les scandales sanitaires et autres rappels de produits, on observe bien que ça ne les empêche pas de tirer les coûts par le bas autant que possible.
Vous exposez une vision libérale des choses. C'est-à-dire une conception économique où les choix des agents sont indépendants les uns des autres. C'est une idéologie. Dans la réalité les échanges génèrent des externalités.
De plus dans le cas d'espèce, il est question d'une entreprise idéologique parfaitement élaborée par un néo-fasciste dont les intentions sont revendiquées, et les moyens d'action à la hauteur. De fait Bolloré intègre toute la chaîne du livre, conception, édition, commercialisation, diffusion et promotion.
À ce sujet règne une grande confusion dans toute cette discussion. Si Bolloré obtient tant de pouvoir avec la bienveillance des pouvoirs publics malgré l'atteinte évidente à la démocratie c'est aussi parce qu'il peut se présenter comme rempart fasse aux Gafam… alors qu'il n'en est que la déclinaison national(ist)e.
Au demeurant, c'est la logique même du portail unique qui est discutable. C'est une logique de concentration.
J'aime pour ma part glaner dans les rayons, ou encore pour les essais me baser sur les citations et creuser de fil en aiguille. Ça permet de diversifier ses références, de travailler le pluralisme des idées. Ça évite le renfermement et l'étroitesse d'esprit…
Il fait vraiment aimer être soumis et détester la liberté pour suivre les algorithmes de recommandation des plates-formes (bulle de filtre, uniformisation des fois, tout ça…). Et ne parlons pas du projet idéologique de Bolloré &co. dont le contenu intellectuel avant même d'être moralement discutable frappe par sa médiocrité. Ça pue quand même beaucoup cette concentration des éditeurs et à terme le but sera de tuer les petites maisons malheureusement… ce sera d'autant plus facile si les libraires perdent le contrôle de leur proposition. Même en physique, dans les grandes chaînes style Fnac le rayon sciences fait peur à voir… (j'habite Paris pourtant)
[^] # Re: Agilité dévoyée épisode xxxxxx ?
Posté par Nicolas . En réponse au lien "Il faut tout reprendre manuellement", le fiasco du nouveau logiciel de la Sécu.... Évalué à 9.
Le logiciel est parfaitement fonctionnel.
Il s'aligne totalement sur les discours politiques : réduction des droits, chasse aux profiteurs qui vivent des allocations plutôt que d'aller bosser ces fainéants, radiation automatique et sans recours conforme au choc de simplification et à la suppression des postes de fonctionnaires en charge de traiter les dossiers.
[^] # Re: Debian ne pip plus ?
Posté par Nicolas . En réponse au journal La galère de Python en déploiement. Évalué à 3.
On utilise des programmes souvent très optimisés, multithreadés par construction, la transmission des données est bufferisée dans les pipes, on travaille par flux (capacité à traiter de gros volumes de données avec une empreinte mémoire réduite). Tout ça "gratuitement".
[^] # Re: Debian ne pip plus ?
Posté par Nicolas . En réponse au journal La galère de Python en déploiement. Évalué à 5.
Les pipes, c'est quand même une tuerie comme paradigme de programmation (en vrai la notion de coroutine, qui est donc un des éléments importants du langage).
Et avec ça tu mets dans ton rétro pas mal de langages, y compris compilés, en terme de perf.
[^] # Re: banques en ligne, sans applis, c'était hier?
Posté par Nicolas . En réponse au journal Où je me cherche une banque. Évalué à 1.
Ahah ! Les forums comme source d'information fiable ! Vivement de voir débarquer des informaticiens formés sur Linuxfr dans le métier… oh wait…
[^] # Re: banques en ligne, sans applis, c'était hier?
Posté par Nicolas . En réponse au journal Où je me cherche une banque. Évalué à -1.
Ça reste de la banque en ligne. Je suis chez Bourso parce que un conseiller Banque postale essayait de me refiler tout et n'importe quoi. C'est de pire en pire, EdF m'a fait le même coup. D'un autre côté c'est grâce à un autre conseiller que j'ai pu avoir un compte courant sans frais pour des opérations exceptionnelles.
En attendant pour les banques en ligne il faut être totalement autonome et donc avoir des besoins trèèèès basiques. Pour moi, commence à se poser la question inverse, celle d'un vrai conseiller qui puisse orienter dans la gestion des sous…
Vous me faites marrer à discuter de détails informatiques plutôt que de la qualité des services rendus (conseils, disponibilité, offres, etc.)
Z'êtes tous des pauvres en fait :p
[^] # Re: Épargne à la Nef
Posté par Nicolas . En réponse au journal Où je me cherche une banque. Évalué à 2. Dernière modification le 22 décembre 2024 à 15:29.
https://fr.m.wikipedia.org/wiki/Fran%C3%A7oise_Nyssen
Une des caractéristiques de ce mouvement est de chercher à infiltrer différents champs… souvent en avançant masqué.
[^] # Re: Connaissance client
Posté par Nicolas . En réponse au journal Où je me cherche une banque. Évalué à 2.
Ça dépend de ton profil. Si tu t'amuses à sortir des 10k tous les mois en petits coupures tu peux être certain que tous les voyants rouges vont s'allumer. Si tu es une personnalité politique, un dirigeant d'entreprise important, etc. tu seras aussi repéré et traité différemment.
À minima y'a les obligations auprès deS administrationS fiscaleS, les interdits bancaires, etc.
Pourquoi la criminalité organisée et Musk adorent les crypto ?
# Précisions
Posté par Nicolas . En réponse au journal Où je me cherche une banque. Évalué à 2.
L'affichage temps réel n'indique pas les transactions réelles. Ça peut être trompeur, selon les cas, car ça ne correspond pas à l'état réel du compte en banque.
Toutes les banques sont temps réel. C'est juste que la date de paiement n'est pas celle que tu crois.
[^] # Re: Who's that guy ?
Posté par Nicolas . En réponse au lien Software is Way Less Performant Today. Évalué à -2.
La recherche des fichiers n’est pas si consommatrice. La structure des répertoires est très légères et, sauf le premier accès, va être pauvre en IO. Ce qui va se jouer c’est le syscall (permutation user-kernel mode), et les différents algo. en œuvre pour la résolution du chemin, la vérification des droits, etc. Par défaut, par exemple, la liste des fichiers est très souvent triée dans le monde Unix, au lieu d’être restituée dans l’ordre présent sur le disque (± l’ordre dans lequel ça a été écrit). Il y a de quoi accélérer tout ça, ne pas constamment demander au kernel une résolution de chemin encore faut-il y avoir accès (donc probablement qu’en
C?) et les connaître. Ça demande une compréhension fine du système, un profiler n’est qu’une aide qui ne répond que, très mal, qu’à une partie du problème. Au mieux du mieux, il te donne une piste sur les bouts de code à optimiser. Mais rien ne garantit que ce bout de code n’est pas tout simplement bon à jeter à la poubelle, au lieu de passer du temps dessus pour grapiller quelques pourcents. Ton truc de modifier la structure de tes répertoires, c’est typique d’une fausse bonne idée : un répertoire c’est juste une liste de fichiers, et une liste de 10k éléments (×255 octets / noms de fichiers = 2,55Mo) c’est que dalle à l’heure actuelle. Si t’es limité par une aussi petite liste, c’est clairement que y’a une couille dans ton programme (ie. si t’as un problème d’IOs, c’est parce que tu fais des IOs à tort). Quand t’as 16Go de données, oui là tu peux mettre en place une stratégie de segmentation pour traiter par partie…Pour SQL c’est encore pire. Dans tous les cas il ne faut pas préjuger du facteur limitant d’une application. Dans ma vie, j’ai connu exactement le contraire. Faut dire que j’ai travaillé sur des applis scientifiques (donc totalement limitées par le calcul) et du traitement batch de données dans la banque/assurance (donc masse de SQL en ce qui me concerne), où un problème d’IO a toujours relevé, très clairement, d’une mauvaise conception : car le principe de base dans mon domaine, c’est un accès/traitement/mise-à-jour totalement séquentiel et linéaire des données (l’enjeu sera de dimensionner correctement capacité de calcul et débits, et dans ce cas cela relève des choix de production). Si tu demandes un accès random, tu vas être à la ramasse sur les IOs, mais ton problème n’est absolument pas un problème d'IOs, le problème c’est l’accès random sur xGo de données…
Dans 99% des cas que je rencontre en pratique, c’est codé avec les pieds, avec un modèle physique de données inadapté (je plaide coupable : je normalise systématiquement pour privilégier la maintenance, ce qui multiplie les jointures…) et le compilateur, CPU, n’y peuvent absolument rien. Remet tes données à plat, maintien un journal des mouvements, traités en batch à postériori, comme on peut le faire dans le monde bancaire, tu va voir que les IOs ne seront plus ton (seul) problème. Ouah t’as optimisé un code sous-optimal ? La bonne affaire ! et si je le vire pour faire la même chose de manière autrement plus efficace ?
[^] # Re: Who's that guy ?
Posté par Nicolas . En réponse au lien Software is Way Less Performant Today. Évalué à 3.
Si ton optimisation n'est pas celle du compilo. y'a des chances pour que tu te sois foiré quelque part.
Pour avoir appris sur mon temps libre l'assembleur, je peux dire qu'il n'est pas si difficile d'optimiser un code. La connaissance de l'assembleur est bien un pré-requis car il donne vraiment une idée suffisamment précise du comportement du CPU (y compris les questions de latence sur les IO car ces accès sont explicites - et on distingue bien un accès en lecture et en écriture).
À partir de là :
L'exercice consiste à étudier la sortie d'un compilo sur du code simple.
Par obligation on est amené à réimplémenter des fonctionnalités très simple. Autre exercice : étudier comment la libc ou autres fait ça.
Spoiler alert : il y'a quantité d'optimisations qui ne sont pas déléguées au compilo. Alors à moins de considérer que les devs de la libc sont des branques…
Trois trucs avec le compilo :
Tu ne le maîtrises pas ni le contrôle. Alors à moins de délivrer qu'un binaire final, tu ne peux préjuger des optimisations appliquées. Les compilos modernes sont devenus horriblement complexes… et LENTS !
À force de déléguer on finit par avoir des CPUs complètement troués parce qu'on pense que la prédiction de branche automatique c'est bien plutôt que de prendre 5s pour signifier au CPU que ce code-ci sera l'exception et l'autre la règle (donc non optimiser un code nécessite pas d'avoir forcément un bagage technique de fou). Sur ce point la causalité est inversée : si c'est le foutoir dans les CPU à tel point qu'un dev n'est pas capable de prédire à l'avance quel code sera performant sur telle machine (manque de prédictibilité du matériel et absence de modèle simple du comportement d'un CPU), c'est bien parce que les concepteurs de CPU y vont chacun de leur petites trouvailles pour obtenir les meilleures perf. malgré du code claqué au sol. On retrouve la même blague sur le nombre de cycle horloge par instructions. Bref on se mort la queue : si un CPU est si compliqué c'est aussi à force d'optimisations que les devs n'ont pas voulu faire parce que… "c'est trop compliqué un CPU".
Ce qui nous amène au dernier point : le compilo applique des optimisations génériques car il n'a pas le moindre début d'idée de ce que le code fait. Seul l'usager sait ce qu'il va en faire et le boulot d'un dev. c'est aussi d'optimiser son temps, savoir quand et où il a intérêt à lever les automatismes et prendre en charge lui-même les micro-optimisations (car faut-il encore le rappeler une énième fois la micro-optimisation c'est que dalle en terme de gain de performance face aux choix de conception - sélection des algorithmes, arbitrage entre le besoin et les moyens, etc.) C'est pas la compilo qui va te dire si ton algo de tri doit être économe en espace ou en temps, si t'es données sont presque triées ou totalement aléatoire, etc. Il pourra toujours essayer de le deviner mais cela impliquera une surcharge qui ne sera pertinente que sur de gros volumes (information que le compilo ne connaît pas…).
[^] # Re: panique morale
Posté par Nicolas . En réponse au lien Wikipédia, plongée dans la fabrique d’une manipulation. Évalué à 6.
Moi j'aime bien la mise en abîme. Le papier qui est objectivement un torchon finit par être contre-productif tellement il prouve par les faits que ce journal est de la merde en barre.
[^] # Re: Ils se contredisent tous seuls
Posté par Nicolas . En réponse au lien Les produits tech sont pensés pour tomber en panne, oui vous pouvez être furax. Évalué à 0.
Quoi les gouvernants achètent la paix sociale par l'exploitation de population étrangères tout en excitant la xénophobie et le racisme des indigènes ! J'étais pas au courant. On me dit jamais rien à moi !
[^] # Re: Ils se contredisent tous seuls
Posté par Nicolas . En réponse au lien Les produits tech sont pensés pour tomber en panne, oui vous pouvez être furax. Évalué à -3.
Flemme de tout lire. Y'a eu un gugusse pour parler de la main d'œuvre payée au lance-pierre à l'autre bout du monde ou bien comme d'habitude on continue d'être totalement hors-sol sur ce site ?
[^] # Re: Ah ces concours...
Posté par Nicolas . En réponse au lien La Nasa cherche à sauver un astronaute sur la Lune et met 45 000 $ sur la table. Évalué à 3.
En même temps, 20k pour (ré)inventer le travois, ça va c’est bien payé.
Après y’a ceux qui construisent des usines à gaz pour montrer qu’ils ont la plus grosse. Et y’a les vrais ingés.
[^] # Re: Cas d'usage et économies réelles
Posté par Nicolas . En réponse au journal Gestion domestique de l'énergie: OpenHEMS. Évalué à 2.
Ce qui arrange EdF c'est la réduction du pic de consommation. Pas le remplissage des creux avec du superflu. Mais bravo pour le tour de passe passe !
[^] # Re: L'IGN c'est cool !
Posté par Nicolas . En réponse au lien LiDAR HD : vers une nouvelle cartographie 3D du territoire. Évalué à 5. Dernière modification le 26 novembre 2024 à 07:54.
C'est tout l'enjeu. Et ce n'est pas une simple conversion de format :
--- transformer les coordonnées cartographiques en coordonnées cartésiennes ;
--- trouver les plus proches voisins de chaque point (ou utiliser un modèle de terrain qui est une grille construite à partir du nuage de points) ;
--- dans le cas de mon algo. estimer le tenseur de courbure, le "diagonaliser", filtrer les points en utilisant valeurs et vecteurs propres comme critères (car ils décrivent localement la surface) ;
--- tesselation pour transformer un nuage de point en un ensemble de surface (c'est très loin d'être trivial) ;
--- sortie finale (renormalisation des coordonnées, conversion dans le format voulu, etc).
Chaque étape fait appel à des algorithmes bien couillus. L'originalité de mon code était la capacité à limiter drastiquement le nombre de faces sans pour autant trop perdre en précision du modèle. C'était déjà critique à l'époque étant donné le volume des données. Avec la résolution atteinte par cette nouvelle campagne Lidar je pense que ça va devenir impossible de faire sans, sauf à se contenter de tuiles ridiculement petites. Ça me donne presque envie de m'y remettre.
# L'IGN c'est cool !
Posté par Nicolas . En réponse au lien LiDAR HD : vers une nouvelle cartographie 3D du territoire. Évalué à 5. Dernière modification le 25 novembre 2024 à 20:02.
Un institut qui produit des cartes de très grandes qualité (les top25 en particulier), un portail grand public (geoportail), plusieurs (?) applications smartphone, tout un tas de données de carto. mis à disposition gratuitement… j'avais utilisé les données Lidar dans un petit projet perso et la précision dans certaines régions était déjà bluffante mais là ça promet du lourd. J'ai malheureusement perdu mon travail mais je ne résiste pas à l'envie de montrer ce qu'on peut faire avec des données de l'ordre du mètre, un "export" dans Blender après optimisation adaptative du modèle :
Puy Marie sans mesh
Exemple de mesh, optimisation
[^] # Re: Cas d'usage et économies réelles
Posté par Nicolas . En réponse au journal Gestion domestique de l'énergie: OpenHEMS. Évalué à 4.
On est clairement dans de l'écologie de bonne conscience. Tous les cas d'usage présentent de très gros consommateurs. À fortiori car une consommation raisonnée rend inepte ce genre《 d'optimisation 》.
[^] # Re: dans quel but ? retrouver son mot de passe perdu ? 2FA ?
Posté par Nicolas . En réponse au message Utilisation forcée d'une adresse personnelle dans le cadre pro. Évalué à 3.
C'est comme ça qu'on voit maintenant des cookies de session durer plusieurs jours, tellement le 2FA est pète-couille. C'est le 0FA.
[^] # Re: ce n'est malhereusement pas que l'édition qui souffre.
Posté par Nicolas . En réponse au lien 2024, le début de la fin pour l'édition indépendante ?. Évalué à 1.
On peut prendre le cas des normes hygiéniques dans l'alimentaire. L'État a face à lui de multiples acteurs. Un《 petit 》n'aura pas les moyens de normes extrêmement strictes. Cependant les conséquences d'une intoxication seront très localisées, le volume de marchandises frelatées étant réduit. De plus si la situation persiste sa réputation sera faite et il fera faillite. Un《 gros 》 lui ne connaîtra pas tout ces mécanismes sociaux de régulation. D'ailleurs dans le temps ce n'était pas naturel de se fournir ainsi, de là l'invention des marques. Par contre il a les moyens de mettre en place des règles strictes. Remarque qu'avec tous les scandales sanitaires et autres rappels de produits, on observe bien que ça ne les empêche pas de tirer les coûts par le bas autant que possible.
[^] # Re: ce n'est malhereusement pas que l'édition qui souffre.
Posté par Nicolas . En réponse au lien 2024, le début de la fin pour l'édition indépendante ?. Évalué à 1.
L'impérialisme, stade suprême du capitalisme
[^] # Re: Pas un nouveau type de PC
Posté par Nicolas . En réponse au lien Microsoft invente un nouveau type de PC : il n’y a pas d’ordinateur dedans . Évalué à 4.
La gueule des admin. réseaux le jour où ça tombe en carafe…
Et ne parlons pas du niveau d'exigence actuel des UI.
[^] # Re: TL;DR : du blabla pour votre argent
Posté par Nicolas . En réponse au lien Ne laissons pas Bolloré et ses idées prendre le pouvoir sur nos librairies !. Évalué à 3. Dernière modification le 19 novembre 2024 à 15:38.
Vous exposez une vision libérale des choses. C'est-à-dire une conception économique où les choix des agents sont indépendants les uns des autres. C'est une idéologie. Dans la réalité les échanges génèrent des externalités.
De plus dans le cas d'espèce, il est question d'une entreprise idéologique parfaitement élaborée par un néo-fasciste dont les intentions sont revendiquées, et les moyens d'action à la hauteur. De fait Bolloré intègre toute la chaîne du livre, conception, édition, commercialisation, diffusion et promotion.
À ce sujet règne une grande confusion dans toute cette discussion. Si Bolloré obtient tant de pouvoir avec la bienveillance des pouvoirs publics malgré l'atteinte évidente à la démocratie c'est aussi parce qu'il peut se présenter comme rempart fasse aux Gafam… alors qu'il n'en est que la déclinaison national(ist)e.
[^] # Re: TL;DR : du blabla pour votre argent
Posté par Nicolas . En réponse au lien Ne laissons pas Bolloré et ses idées prendre le pouvoir sur nos librairies !. Évalué à 0.
Au demeurant, c'est la logique même du portail unique qui est discutable. C'est une logique de concentration.
J'aime pour ma part glaner dans les rayons, ou encore pour les essais me baser sur les citations et creuser de fil en aiguille. Ça permet de diversifier ses références, de travailler le pluralisme des idées. Ça évite le renfermement et l'étroitesse d'esprit…
Il fait vraiment aimer être soumis et détester la liberté pour suivre les algorithmes de recommandation des plates-formes (bulle de filtre, uniformisation des fois, tout ça…). Et ne parlons pas du projet idéologique de Bolloré &co. dont le contenu intellectuel avant même d'être moralement discutable frappe par sa médiocrité. Ça pue quand même beaucoup cette concentration des éditeurs et à terme le but sera de tuer les petites maisons malheureusement… ce sera d'autant plus facile si les libraires perdent le contrôle de leur proposition. Même en physique, dans les grandes chaînes style Fnac le rayon sciences fait peur à voir… (j'habite Paris pourtant)
[^] # Re: TL;DR : du blabla pour votre argent
Posté par Nicolas . En réponse au lien Ne laissons pas Bolloré et ses idées prendre le pouvoir sur nos librairies !. Évalué à 9.
Merde j'ai cherché j'ai pas vu où est-ce que je pouvais donner mon argent à cette excellente initiative. Peux-tu me donner le lien ?