Deutsch English Français Italiano |
<ujqp8f$1h3re$2@news.usenet.ovh> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!usenet.goja.nl.eu.org!paganini.bofh.team!usenet.ovh!news.usenet.ovh!.POSTED!not-for-mail From: robby <me@pla.net.invalid> Newsgroups: fr.sci.maths Subject: =?UTF-8?Q?Re=3A_=5BLONG=5D=5BSolution_et_programme=5D_solve_a_+_k_b?= =?UTF-8?Q?_=7E_entier_=28_i=2Ee=2E_=C3=A0_moins_d=27epsilon_d=27un_entier_?= =?UTF-8?Q?=29?= Date: Fri, 24 Nov 2023 19:15:43 +0100 Organization: Alfa Network En Travaux Message-ID: <ujqp8f$1h3re$2@news.usenet.ovh> References: <654d3788$0$25951$426a74cc@news.free.fr> <uirkc1$176f$1@cabale.usenet-fr.net> <ujqo1k$1h3re$1@news.usenet.ovh> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 24 Nov 2023 18:15:44 -0000 (UTC) Injection-Info: news.usenet.ovh; posting-account="robby"; logging-data="1609582"; mail-complaints-to="abuse@usenet.ovh" User-Agent: Mozilla Thunderbird Cancel-Lock: sha256:zT6j24VWmNtk1S6OXc64fTsxC3cIx7252HSp9fYEBqk= Content-Language: fr In-Reply-To: <ujqo1k$1h3re$1@news.usenet.ovh> Bytes: 3337 Lines: 48 > Le 13/11/2023 à 22:08, Olivier Miakinen a écrit : > > Le 13/11/2023 10:59, Fabrice NEYRET a écrit : > >> Olivier Miakinen a écrit : > >>> Le nombre k cherché vaut 32 × 106 = 3392 > >> > >> et on est alors certain qu'il n'y en a pas de plus petit ? > > > > Alors non. alors ça c'est embêtant. en fait, j'aimerais pouvoir énumérer ( ou au moins encadrer ) les valeurs de k pertinentes. bon, le plus simple que j'y revienne sur un cas concret (je retombe régulièrement sur ce problème). mais typiquement, il s'agit en gros de tracer efficacement des figures en Eulérien plutôt qu'en Lagrangien. Ex, tracer une figure déposant des points régulièrement le long d'une trajectoire ( courbe en polaire, par ex ) est facile en programmation ordinaire. Mais quand on écrit des /shaders/ (par ex pour GPU) le programme s'exécute en parallélisme massif pour chaque pixel simultanément. Pour un pixel en (x,y) donné, le shader appelé au pixel doit choisir s'il trace qqchose ou pas. Re-parcourir toute une boucle de construction de figure pour voir si un point tombe dans le pixel courant serait très inefficace. L'idée est plutôt de connaitre l'indice du point tombant le plus proche de (x,y), et la couleur du pixel sera alors 1 si on est a une distance de moins de epsilon du point (en fait, c'est rayon du petit disque tracé au point ) sinon 0. Et si on sait trouver directement la distance au point le plus proche, c'est encore mieux. Mais en pratique si on obtient déjà un subset ou un range de points potentiels, c'est déjà mieux que la grosse boucle, du moment qu'on est conservatif. Evidemment, comme c'est un problème inverse, ça n'est pas toujours facile, ni faisable. Mais pour un certain nombre de constructions on y arrive... parfois. ex: points le long d'une spirale de Fibonacci: https://www.shadertoy.com/view/fdjSRW ( plutôt que https://www.shadertoy.com/view/wtsczN ) mais tracer sans boucle un trefoil en shader, par ex, même la courbe continue P = (2+cos3a)* [ cos(2a), sin(2a) ], c'est plus coton. ( i.e. trouver les a tel que |P(a)-pix| < eps ) -- Fabrice