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