Discussion :

[Jipété]

en fait je comprends pas trop la question qui te taraude exactement

Pas la première fois que je me demande si je suis bien lu et compris.
Pourtant, ça a l'air clair :

Mais je veux que le rouge démarre en haut, il me faut donc tout décaler de +Pi/2 sur le cercle et donc, ça m'inverse vert et bleu, voir + haut.

Je veux que le rouge démarre en haut, à midi, à 12 h, à Pi/2, à 90 °

tu veux décaler de Pi/2 si j'ai bien compris

Tu vois, quand tu veux,

Sauf qu'après tu te fais des nœuds :

imaginons que le rouge est a 0 soit 0° =0
le vert quant à lui va à 0-2*PI/3 soit environ 8 heure 30 soit 135° = 2PI/3
et le bleu va à 0+2*PI/3 donc 10 heure 30 soit 225° ou -135° = -2PI/3

Déjà ça c'est faux, car je découpe le cercle en 3 tronçons égaux, donc chacun de 120 ° et donc le vert à 120 et le bleu à 240, soit, en regardant ton cercle, à 2Pi/3 puis 4Pi/3, aussi noté -2Pi/3.

Et en fait, le problème est là, mais je n'ai pas (encore) d'explication ; en reprenant l'exemple de wiwaxia, on lit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for I := 0 to L-1 do begin
  t  := 2*Pi*I(rang du pixel)/L(largeur image);
  Ir := Round(255*F(t)); 
  Iv := Round(255*F(t - 2*Pi/3)); 
  Ib := Round(255*F(t + 2*Pi/3));
end;

que j'ai fait suivre dans le post d'origine par ça :

Et ça colle avec le parcours du cercle en sens inverse.
D'ailleurs, si je l'applique tel quel, les couleurs sont bonnes :

En fait le problème est là : tous les cercles trigo du web comme mes bouquins scolaires montrent un parcours partant de 3 h et tournant dans le sens inverse dad'um, avec dans la partie supérieure du demi-cercle des valeurs de Pi positives pour les points remarquables, et des valeurs négatives pour le demi-cercle inférieur, qui va de 9 h à 3 h en passant en bas par 6 h.

Et le code de wiwaxia est inversé par rapport ça, et c'est ça que je ne comprends pas et que je veux qu'on m'explique.

[Jipété]

Bonjour,

ma question n'inspire pas grand monde, on dirait…

Bah, ça me permet de faire des tests, des essais, des recherches, etc.

Ce matin j'ai pris le taureau par les cornes et j'ai décidé de comprendre le "parcours du cercle", en partant d'un simple bitmap sur lequel je dessine une courbe rouge.

Suite à un bug d'inattention (mal réveillé -- mais tout sert à tout) lors d'un copier/coller mal avisé, (largeuraffichage := MyBitmap.Width div 2, div 2 en trop ), juste une moitié de la cible est calculée et affichée avec for x := 1 to largeuraffichage do et il se trouve que ça affiche donc de 1 à la demi-largeur et c'est la partie inférieure de la courbe qui est dessinée.

En remplaçant iY := demihauteur +Round(... par iY := demihauteur -Round(... ça inverse le rendu : la moitié de courbe est en haut.
Et c'est lié au fait que ce qu'on voit en haut de la courbe (valeurs élevées supposées, ce qui est le cas, le sinus passe de 0 à demihauteur et redescend) est en fait en bas dans les coordonnées de l'objet d'affichage (qui commence à gauche en haut à 0,0) :
- tout en haut du graphique c'est la coordonnée "x, 0"
- tout en bas c'est la coordonnée "x, hauteuraffichage".
Ça surprend, et il faut sans arrêt penser à l'envers.

Le code (on peut difficilement faire plus court et plus simple) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
  demihauteur := (MyBitmap.Height div 2) -1;
  largeuraffichage := MyBitmap.Width;
  decalagesurlecercle := 0; // le dessin commence à 3 h et monte vers 6 h
 
  MyBitMap.Canvas.Pen.Color := clRed;
 
  for x := 1 to largeuraffichage do begin
    // centrage en hauteur puis courbe : -Round elle monte, +Round elle descend
    iY := demihauteur -Round(demihauteur * SIN(x*2*Pi/largeuraffichage + decalagesurlecercle));
 
    if x=1
    then MyBitmap.Canvas.MoveTo(1,iY) // 1re colonne, on se positionne
    else MyBitMap.Canvas.LineTo(x,iY);// colonnes suivantes, on dessine
  end;

Et à partir de ces quelques lignes j'ai essayé différentes valeurs de decalagesurlecercle, que je mets dessous, avec les résultats :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
  //decalagesurlecercle := 1*PI/6; // le dessin commence à  2 h et monte
  //decalagesurlecercle := 2*PI/6; // le dessin commence à  1 h et monte
  //decalagesurlecercle := 3*PI/6; // le dessin commence à 12 h et descend
  //decalagesurlecercle := 4*PI/6; // le dessin commence à 11 h
  //decalagesurlecercle := 5*PI/6; // le dessin commence à 10 h
  //decalagesurlecercle := 6*PI/6; // le dessin commence à  9 h
  //decalagesurlecercle := 7*PI/6; // le dessin commence à  8 h
  //decalagesurlecercle := 8*PI/6; // le dessin commence à  7 h
  //decalagesurlecercle := 9*PI/6; // le dessin commence à  6 h et remonte
  // sur une cible de 240 px de hauteur, 9 h est à 120,
  // 10 h (5pisur6) à 60 et 11 h (4pisur6) à 15

J'étais tout content, je me suis dit que j'allais enfin tordre le coup au problème des 3 courbes où V et B sont inversés, j'ai scrupuleusement recopié mes lignes de cette étude vers le projet "3_courbes", j'ai exécuté et patatras, toujours cette inversion…

J'ai tenté avec +Round(..., même topo, je me suis décidé à rédiger *ce* post pour vous faire part de mon désarroi, ce qui m'a amené à regarder ce que j'allais copier/coller dans mon brouillon de post et d'un coup, je me suis dit que puisque tout marchait à l'envers dans cette histoire, il y avait une chose que j'avais oublié d'inverser : le décalage pendant le parcours du cercle.
Alors j'ai tenté ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//  iY := demihauteur -Round(demihauteur * SIN(x*2*Pi/largeuraffichage + decalagesurlecercle));
    iY := demihauteur -Round(demihauteur * SIN(x*2*Pi/largeuraffichage - decalagesurlecercle));

et c'est enfin tombé en marche correcte !


Mais je n'ai pas l'explication rationnelle et intelligente de pourquoi tout le monde dessine le cercle trigo avec une flèche indiquant le sens inverse dad'um

alors que je constate qu'il faut avancer dans le sens naturel dad'um.


PS : je viens de faire l'essai, ça fonctionne aussi avec +Round(..., faut juste penser à inverser l'affichage

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
       //Canvas.LineTo(i,255-y); // utiliser avec -Round
      Canvas.LineTo(i,y); // utiliser avec +Round

et bien se rappeler que la constante decalagesurlecercle doit être précédée du signe "-".
Résultat, ça met en vrac toute la liste des decalagesurlecercle := valeur; // commentaire, mais ça prendra 5 minutes à refaire, paniproblem'

+++
J'ai une autre question tordue, je la garde pour + tard.

[anapurna]

Salut

Déjà ça c'est faux, car je découpe le cercle en 3 tronçons égaux, donc chacun de 120 ° et donc le vert à 120 et le bleu à 240, soit, en regardant ton cercle, à 2Pi/3 puis 4Pi/3, aussi noté -2Pi/3.

il faut absolument que j'arrete le vin le midi ça ne me reussi pas ^^
effectivement 360 div cela 3 fait 120
je ne sais absolument pas sur quel base je suis partie pour faire ma division


bon a priori tu as trouvé ton erreur tu a oublié de soustraire la valeur de 255 afin d'inverser ta courbe

[Jipété]

bon a priori tu as trouvé ton erreur tu as oublié de soustraire la valeur de 255 afin d'inverser ta courbe

Non, je n'ai rien trouvé qui soit global et reproductible.

J'ai encore passé un temps dément sur le net pour rien, personne n'explique. Chacun balance ses formules, "fais comme ça" mais si on veut modifier quoi que ce soit ça part en sucette...

Pour le moment, j'en suis là et je ne suis pas du tout satisfait car, si je parcours le cercle dans le sens de la flèche (enfin !), c'est en tordant le cou aux valeurs de déphasage, qui devraient être à l'opposé de ce qu'on voit dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
y := demihauteur - round(demihauteur*sin(i*2*Pi / largeuraffichage -troispisursix)); // R
y := demihauteur - round(demihauteur*sin(i*2*Pi / largeuraffichage + cinqpisursix)); // V
y := demihauteur - round(demihauteur*sin(i*2*Pi / largeuraffichage +     pisursix)); // B

Alors tout le monde va dire "mais inverse les signes avant round et après largeuraffichage", à quoi je répondrai que je ne vous ai pas attendu pour en avoir l'idée, mais que ça ne va pas : je me retrouve avec mes inversions V <> B ou R <> V selon que je joue avec 255 ou pas pour la valeur du point.Y.

Bref, c'est toujours autant incompréhensible, et donc non-maintenable.

[Jipété]

J'ai ressorti un bouquin de "géométrie et statistique" de 1^re D et, dans le chapitre "Mouvement vibratoire simple" je peux lire la chose suivante, à propos de l'équation vecteurOM = vecteurOA.cos(omega.t + alpha) [c'est moi qui écris en toutes lettres parce que pour faire ces lettres grecques ici, laisse tomber]

Le coefficient alpha que l'on peut supposer positif (en changeant si besoin est alpha en alpha + ou - Pi) est …

Alors voilà : dans un bouquin de math on suppose des choses, et on les adapte à notre besoin si elles ne nous conviennent pas, c'est ça ?

Y a pas un prof de math quelque part pour expliquer ? Parce que là, ce "si besoin est" m'a laissé tellement sans voix que j'en poste mon désarroi.


Et pour tout vous avouer, si ça se trouve, c'est peut-être à partir de là que j'ai commencé à décrocher, parce que moi, les théorèmes aléatoires et les équations adaptatives, euh, c'est loin d'être une science exacte, hein.

[wiwaxia]

... Mais je n'ai pas l'explication rationnelle et intelligente de pourquoi tout le monde dessine le cercle trigo avec une flèche indiquant le sens inverse dad'um

alors que je constate qu'il faut avancer dans le sens naturel dad'um.

C'est quoi, le sens naturel dad'um ?

Le sens horaire (ou horlogique, rétrograde) est au départ le sens de déplacement de l'ombre de tout objet à la surface du sol, en tout lieu de l'hémisphère Nord situé au-dessus du tropique du Cancer (latitude ~23° 26'), et donc celui de l'ombre du style sur la table de tout cadran solaire.
C'est devenu tout naturellement le sens de rotation des aiguilles des horloges qui les ont remplacés.

Le sens trigonométrique (ou antihoraire, direct) est celui de la rotation de la Terre tel que le verrait un observateur immobile situé sur l'axe des pôles, le sens Sud/Nord correspondant à celui de ses pieds vers sa tête; tourné constamment vers le Soleil, il verrait sous ses pieds les points de la surface terrestre se mouvoir vers sa gauche.
La définition du sens de rotation est donc intimement liée à celle de repère trirectangle direct ; à tout repère orienté direct (Oxy) de dimension (2), il faut associer un 3me axe (z'z) orthogonal au précédent, passant par l'origine (O) et dirigé vers l'avant (donc vers le lecteur qui observe la figure).

... +++ J'ai une autre question tordue, je la garde pour + tard.

Dis toujours: si cela peut éviter une prise d'otages ...

[Jipété]

C'est quoi, le sens naturel dad'um ?

Rhôôô, dad'um = Des Aiguilles D'Une Montre.
Bon, vu ton explication, probable que je me suis fourvoyé avec le sens de "naturel".

-- snip --

Tu m'embrouilles complètement,

Dis toujours: si cela peut éviter une prise d'otages ...

Non, je veux d'abord régler cette histoire de parcours, parce qu'in fine tu n'en as rien dit.
Bah, ça fait deux heures que je gamberge dessus, et j'en suis là :

Je n'ose pas l'écrire, mais pourtant, un test rapide le confirme, serait-il possible que depuis un mois on ait confondu le vert et le bleu ?
Ou qu'on croit parcourir dans le sens inverse dad'um quand on parcourt dans le sens direct ? [ah ben du coup, avec ce qui précède, je ne sais plus comment dire]

Car si je reprends le cercle trigo en faisant bien attention et en n'utilisant que des coefficients alpha positifs, il n'y a pas de secret, la deuxième onde à se dessiner est… bleue.

D'ailleurs, si je commente ses instructions, pof !, a pu ! Image en haut à gauche :


Et là, en regardant le code du vert, son coeff alpha est à septpisursix, à 8 h sur le cercle (-5PI/6 en rouge).

Parce qu'il n'y a pas de secret ni de mystère avec la courbe rouge, qui se met toujours où je lui demande gentiment, exemple avec je sais pas, moi, euh, quatrepisurtrois ?
Allez, soyons fous, et le résultat est en bas à droite.

4PI/3 c'est à 7 h sur le cercle, noté en bleu -2PI/3 et donc AVANT la courbe verte SI on tourne dans le sens habituel dad'um, et si je change de param et que je prends cinqpisursix, image en haut à droite, on est à 10 h sur le cercle et APRÈS la courbe verte.
Donc on tourne à l'envers de la flèche, à l'envers du sens trigo, à l'envers des aiguilles de la montre, un vrai truc de malade guedin jobastre indiqué nulle part.

Enfin, il me semble.

[wiwaxia]

J'ai longuement recherché dans mes programmes ce qui aurait pu t'induire en erreur, et n'ai rien trouvé.
Je place par habitude le rouge à l'origine des angles (O° , "à trois heures" comme tu dirais), et le vert suit en principe en haut à gauche, centré sur la valeur 120° ("à onze heures"); mais il se peut qu'il se soit une fois ou l'autre retrouvé par inadvertance en bas (à -120° ≡ 240° modulo 1 tour).

Il est vain de discuter des décalages angulaires sans avoir précisé les propriétés essentielles de la fonction F(t) en cause:
F(t) est une fonction: a) périodique, de période égale à (2*Pi) - la variable (t) représente alors la teinte, et qu'on l'exprime en une autre unité (en degré, grades ou cycles) de la dénature pas;
b) paire et maximale en (0): la fonction Cos(t) vérifie ce critère, de même que toutes les fonctions génératrices que l'on a envisagées.

La détermination du pixel répond alors au schéma suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
FOR i:= 0 to La-1 DO
  BEGIN
    r:= (i / La); t:= D_Pi * r;
    Ir := Round(255*F(t)); 
    Iv := Round(255*F(t - D_Pi/3)); 
    Ib := Round(255*F(t + D_Pi/3))
END;

Un simple inversion de signe conduit aux couleurs symétriques, le vert se retrouvant en bas.
Exemple: pour la suite des cinq fonctions mises en comparaison (#201 , #230), la couleur locale découle de quelques instructions, et le renversement du cercle chromatique résulte d'un simple changement de signe:

Le procédé s'applique à tout fonction périodique, par exemple à G(s) définie sur [-3 ; +3] et de période égale à (6): il faut alors imposer un décalage égal à un tiers de période, soit (2):

Il s'agit d'un calcul moins simple, dont je n'ai pas parlé.

J'ai ressorti un bouquin de "géométrie et statistique" de 1^re D et, dans le chapitre "Mouvement vibratoire simple" je peux lire la chose suivante, à propos de l'équation vecteurOM = vecteurOA.cos(omega.t + alpha) [c'est moi qui écris en toutes lettres parce que pour faire ces lettres grecques ici, laisse tomber]

Alors voilà : dans un bouquin de math on suppose des choses, et on les adapte à notre besoin si elles ne nous conviennent pas, c'est ça ?

Y a pas un prof de math quelque part pour expliquer ? Parce que là, ce "si besoin est" m'a laissé tellement sans voix que j'en poste mon désarroi.

Et pour tout vous avouer, si ça se trouve, c'est peut-être à partir de là que j'ai commencé à décrocher, parce que moi, les théorèmes aléatoires et les équations adaptatives, euh, c'est loin d'être une science exacte, hein.

Il n'y a qu'une seule trigonométrie, mais diverses formules plus ou moins appropriées à l'usage qu'on veut en faire; et l'on se retrouve rapidement dans une impasse sans un minimum de connaissances et d'entraînement, indispensables à la liberté et au recul nécessaires au bon choix des expressions. Tu viens de faire les frais de la méthode Meccano, et tu devrais tenter d'en tirer une leçon ... d'autant que tu as suivi des cours de maths, et que tu peux donc relire un cours.
Un livre de Maths de niveau secondaire technique te serait d'un excellent secours: aisément compréhensible, et allant à l'essentiel.
Il t'éviterait de te noyer das un verre d'eau.

[Jipété]

Un livre de Maths de niveau secondaire technique te serait d'un excellent secours: aisément compréhensible, et allant à l'essentiel.
Il t'éviterait de te noyer dans un verre d'eau.

J'ai.
Avec de très jolis exemples de cercles trigos avec les points remarquables dessus, un peu comme ça :



Ce que j'ai dit hier, c'est que j'ai viré les -xPi/z, remplacés par des + (le bouquin donne les correspondances, comme dans la moitié inférieure de l'image ci-dessus), et les choses fonctionnent bien SI je parcours le cercle dans le sens des aiguilles d'une montre, à l'inverse donc de la flèche habituelle (je viens cependant de voir des images où "ma" flèche est utilisée, mais le site est non-consultable si pas inscrit, donc je n'ai pas d'explication sur l'utilisation de ce sens).

Et donc, je redis que pour parcourir mon cercle, je démarre en haut à 12 h (Pi/2), je "descends par la droite" jusqu'à 4 h (11Pi/6), et de là je continue à 8 h à 7Pi/6 pour remonter à Pi/2 et voilà.
Et j'ai bien rouge -> vert -> bleu.

Cherchez l'erreur (s'il y en a une).

EDIT : j'ai oublié de donner les codes, hier ; je me suis rédigé un pense-bête (anti-sèches ? ) comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// rouge
for i := offset_gauche to largeuraffichage-1 do begin
  y := demihauteur + round(demihauteur*sin(i*2*Pi / largeuraffichage +pisurdeux));
  Canvas.LineTo(i,255-y);
end;
 
// vert
for i := offset_gauche to largeuraffichage-1 do begin
  y := demihauteur + round(demihauteur*sin(i*2*Pi / largeuraffichage +onzepisursix));
  Canvas.LineTo(i,255-y);
end;
 
// bleu
for i := offset_gauche to largeuraffichage-1 do begin
  y := demihauteur + round(demihauteur*sin(i*2*Pi / largeuraffichage +septpisursix));
  Canvas.LineTo(i,255-y);
end;

En fait, dans la vraie vie, le vrai code se passe en deux temps :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
alpha := une_valeur; 
y := demihauteur + round(demihauteur*sin(i*2*Pi / largeuraffichage +alpha));

et ça 3 fois, donc.
Ce qui fait que si je veux faire un test rapide et tout décaler, il me suffit de faire, 3 fois,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

    alpha := une_valeur + ou - une_autre_valeur

et bon sang, ça fonctionne tip-top, mes trois courbes se déplacent ensemble, que du bonheur.

Exemple avec la correction -pisurdeux, comme ça tu seras content, le rouge démarre à pisurdeux-pisurdeux = 0 = 3 h :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alpha := pisurdeux-pisurdeux;

[Jipété]

J'arrive à synthétiser tout ça d'une manière fort sympathique et très agréable à l'utilisation.

J'ai viré cette variable alpha, remplacée par 3 autres ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
  //alpha: double;
  RPhaseShift, GPhaseShift, BPhaseShift : double;
begin
  RPhaseShift := 0;
  GPhaseShift := RPhaseShift + quatrepisurtrois;
  BPhaseShift := RPhaseShift + deuxpisurtrois;

et le cœur des 3 courbes se présente ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

y := demihauteur + round(demihauteur*sin(i*2*Pi / largeuraffichage + BPhaseShift)); // ou RPh... ou GPh...

Résultat, une seule valeur à ajuster, et les autres se synchronisent à 120 ° près, trop fastoche

Exemples :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
  //RPhaseShift := 0; // le départ de wiwaxia à 3 h
  //RPhaseShift := 0 + pisurdeux; // mon départ à 12 h
  //RPhaseShift := 0 + pisursix; // test 1, départ à 2 h
  RPhaseShift := 0 + troispisurquatre; // test 2, départ à 10 h 30
  GPhaseShift := RPhaseShift + quatrepisurtrois;
  BPhaseShift := RPhaseShift + deuxpisurtrois;

Bien sûr, ta manière de faire fonctionne aussi,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  RPhaseShift := 0; // le départ de wiwaxia à 3 h
  GPhaseShift := RPhaseShift - deuxpisurtrois;
  BPhaseShift := RPhaseShift + deuxpisurtrois;

mais elle me donne l'impression de faire un coup j'avance un coup je recule comment veux-tu que nan mais qu'est-ce que j'raconte, là, , alors que la mienne décrit tranquillement son petit bonhomme de chemin en cercle.
Ça t'ennuie si je la préfère ?

J'ai fait plein de tests, je n'ai jamais pu prendre cette manière de faire en défaut, voici le dernier test avec une valeur pifométrique mais quand même estimée entre 5PI/6 et PI, et c'est bien ce qu'on a à l'écran :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  RPhaseShift := 0 + 2.85; // dernier test, départ qqpart entre 9 et 10 h 
  GPhaseShift := RPhaseShift + quatrepisurtrois; 
  BPhaseShift := RPhaseShift + deuxpisurtrois;

Pas trop libre c't'aprème, la suite à pluche,

[wiwaxia]

J'ai.
Avec de très jolis exemples de cercles trigos avec les points remarquables dessus, un peu comme ça ...

... Que tu ne sais malheureusement ni lire ni utiliser correctement.
Toutes les valeurs des angles mentionnées, parcourues dans le sens trigonométrique (le seul valable en analyse et en géométrie) à partir de l'origine P(0) = (1, 0) = intersection du cercle avec (Ox) - se succèdent dans l'ordre croissant:

1^er quadrant: θ/π = 0 , 1/6 , 1/4 , 1/3
2^nd quadrant: θ/π = 1/2 , 2/3 , 3/4 , 5/6
3^me quadrant: θ/π = 1 , 7/6 , 5/4 , 4/3
4^me quadrant: θ/π = 3/2 , 5/3 , 7/4 , 11/6

... Et donc, je redis que pour parcourir mon cercle, je démarre en haut à 12 h (Pi/2), je "descends par la droite" jusqu'à 4 h (11Pi/6), et de là je continue à 8 h à 7Pi/6 pour remonter à Pi/2 et voilà.
Et j'ai bien rouge -> vert -> bleu.

Cherchez l'erreur (s'il y en a une) ...

Eh bien oui, il y en a une , et une grosse: tu envisages des angles décroissants:

(Pi/2 + 2*Pi = 5*Pi/2 , 11*Pi/6 , 7*Pi/6)

donc une rotation dans le sens négatif, ce dont tu ne tiens pas compte par la suite.
Tes conventions relèvent du changement de variable angulaire: ϕ = (π/2) - θ
que tu n'es malheureusement pas en mesure de gérer clairement, d'où le sac de noeuds dans lequel tu t'emmêles les pinceaux depuis deux jours. Le bricolage que tu proposes ne résout rien.
C'est de l'enfantillage que de remettre en cause une convention universelle, celle du sens trigonométrique, qui est à la base de l'analyse vectorielle - et même de l'analyse tout court, celle qui établit les propriétés des fonctions Sin(t) et Cos(t).

La succession des teintes sur le cercle chromatique est indépendante du sens de rotation.
Si le maximum d'intensité du rouge se place à la position d'angle Alpha, celle du vert sera décalée d'un tiers de tour (2*Pi/3) par exemple dans le sens positif, et celle du bleu de la même quantité en sens opposé; si l'on reprend la fonction (F) déjà évoquée (#268), on obtiendra pour les composantes de couleur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
FOR i:= 0 to La-1 DO
  BEGIN
    r:= (i / La); t:= D_Pi * r; IncR(t, Alpha);
    Ir := Round(255*F(t)); 
    Iv := Round(255*F(t - D_Pi/3)); 
    Ib := Round(255*F(t + D_Pi/3))
  END;

Pour inverser la succession des teintes (RVB) du cercle chromatique, il suffira de permuter les signes des deux décalages, comme l'avait pressenti anapurna.

[Jipété]

Fouhhh, quelle volée de bois vert,

Eh bien oui, il y en a une , et une grosse: tu envisages des angles décroissants:

Hé bien oui, et alors ? C'est interdit ? Il faut arrêter illico presto toutes les horloges à aiguilles et les bannir à tout jamais parce que ces choses ne tournent pas dans le bon sens ?
Bon, tiens, voilà :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  RPhaseShift := 0 - troispisurdeux; // mon départ à 12 h
  GPhaseShift := RPhaseShift - deuxpisurtrois;
  BPhaseShift := RPhaseShift - quatrepisurtrois;

Tu préfères ?

C'est de l'enfantillage que de remettre en cause une convention universelle, celle du sens trigonométrique, qui est à la base de l'analyse vectorielle

Je ne la remets pas en cause, je la laisse où elle est et je parcours le cercle autrement.
Tu me permettras de préférer cette autre manière de circuler, car d'une part il me plait de prendre l'autoroute à contre-sens, le paysage y est plus joli et je vois une certaine logique à additionner des choses pour avancer, et d'autre part ça ne m'empêche pas d'arriver au but.
Je te l'ai dit, pour aller de Nice à Rome je passe par New York.
En quoi ça dérange quelqu'un, si ce n'est ceux qui se cramponnent à leur sens trigo "qui est à la base de l'analyse vectorielle" dis-tu, mais ça me fait une belle jambe, je ne sais pas ce que c'est et je ne l'utiliserai donc jamais.

La succession des teintes sur le cercle chromatique est indépendante du sens de rotation.

donc tu admets qu'il puisse y avoir un autre sens que le sacro-saint sens trigo, ça tombe bien, un peu rebelle dans l'âme il fallait bien que je me démarque.

Bon, mine de rien, tu nous proposes une solution

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
FOR i:= 0 to La-1 DO
  BEGIN
    r:= (i / La); t:= D_Pi * r; IncR(t, Alpha);
    Ir := Round(255*F(t)); 
    Iv := Round(255*F(t - D_Pi/3)); 
    Ib := Round(255*F(t + D_Pi/3))
  END;

que je vois osciller comme le balancier d'une horloge comtoise, un coup à gauche un coup à droite ou plus précisément un coup en haut un coup en bas, c'est ça ? Donc le sens trigo dont tu nous as tant parlé, tu l'empruntes un coup dans son sens et un coup dans l'autre ?
Moi y en a pas comprendre, bwana.

Au fait, j'ai réalisé tout à l'heure, grâce aux jolis + rouges que tu as rajoutés sur le cercle, qu'au bout du compte, en partant de P(0) (1,0) (ton point de départ) et en montant à P(PI/2) (mon point de départ), ben… je parcours le cercle dans ton sens adoré !
Et ça, personne ne l'avait vu,

Bref, mettons tout le monde d'accord, chacun choisira la manière qu'il préfère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
{ // mode -
  RPhaseShift := 0 - troispisurdeux; // mon départ à 12 h
  GPhaseShift := RPhaseShift - deuxpisurtrois;
  BPhaseShift := RPhaseShift - quatrepisurtrois;   }
  // mode +
  RPhaseShift := 0 + pisurdeux; // mon départ à 12 h
  GPhaseShift := RPhaseShift + quatrepisurtrois;
  BPhaseShift := RPhaseShift + deuxpisurtrois;

Pour démarrer à 3 h comme wiwaxia, il suffit de faire RPhaseShift := 0; et voilà.

[wiwaxia]

En quoi ça dérange quelqu'un, si ce n'est ceux qui se cramponnent à leur sens trigo "qui est à la base de l'analyse vectorielle" dis-tu, mais ça me fait une belle jambe, je ne sais pas ce que c'est et je ne l'utiliserai donc jamais.

W: La succession des teintes sur le cercle chromatique est indépendante du sens de rotation.
donc tu admets qu'il puisse y avoir un autre sens que le sacro-saint sens trigo, ça tombe bien, un peu rebelle dans l'âme il fallait bien que je me démarque.

Tu ne comprends pas: le fait de choisir un sens positif n'a jamais empêché l'aiguille d'une boussole ou le rotor d'une machine de tourner dans le sens négatif !
C'est une question d'orientation de l'espace, à commencer par l'observateur qui regarde le cercle orienté, et se situe sur un axe normal au plan du cercle.
Et de l'orientation de ce cercle, dépendent justement les valeurs des angles relatifs à la position des points.

Tu devrais en toute logique te référer à un axe (x'x) orienté vers la droite (convention commune), et à un second axe (y'y) orienté vers le bas. Sinon chaque modification introduite risque de conduire à un nouveau sac de noeuds, et l'on ne tardera pas à entendre les lamentations du programmeur trahi par les mathématiques:

Y a pas un prof de math quelque part pour expliquer ? Parce que là, ce "si besoin est" m'a laissé tellement sans voix que j'en poste mon désarroi.

Les chants du désespoir sont les chants les plus beaux .

[Jipété]

Tu devrais en toute logique te référer à un axe (x'x) orienté vers la droite (convention commune), et à un second axe (y'y) orienté vers le bas.

Il me semble pourtant que c'est ce que je fais quand je dis que le point théorique du parcours commence à 3 h et que je "monte" à 12 h pour démarrer le parcours effectif. Mais peut-être que j'utilise des mots trop terre à terre ?

+++
Sinon, l'autre chose qui me turlupinait se situe là, où l'on peut voir une sortie console avec des colonnes impressionnantes de nombres :

Une autre version de la même fonction linéaire par morceaux:

Elle doit aussi bien fonctionner sur les domaines [0 ; 2*Pi] et [-Pi ; Pi]; j'ai fait un test sur les valeurs réelles:

Pièce jointe 476435

[si vous voyez écrit "pièce jointe blabla", vous m'en voyez navré : en mode prévisualisation j'ai l'image ! cliquez sur le lien pour la voir]

et j'aurais aimé une explication sur ces "valeurs réelles" qui sont pour moi juste des valeurs entières complétées par ".00000".

Ou j'ai fait une confusion avec ton Pascal qui parle de Reel (on le voit bien dans tes codes) quand le mien utilise Real et donc pas de risque de confondre, ou je ne sais pas, d'où cette petite demande de précision.

+++
Et à propos de la fonction linéaire par morceaux :

tu en as sorti une autre version il y a qq jours quand de mon côté je travaillais aussi là-dessus, et je viens enfin d'aboutir, après tous ces rebondissements.

Je remets ta version, qui a besoin d'environ 150-160 msec sur ma machine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
FUNCTION FlinM(t: Real): Byte;          // Fonction linéaire par morceaux
  VAR u, v, w, z: Real; 
  BEGIN
    z:= IPis3 * t;
    IF (z> 3) THEN z := z - 6;
    IF (z<-3) THEN z := z + 6;
    u:= Abs(z + 2); IncR(u, Abs(z - 2));
    v:= Abs(z + 1); IncR(v, Abs(z - 1));
    w:= 0.5 * (u - v);
    Result:= Round(255 * w)
  END;

et la mienne, qui s'exécute en environ 110 msec (Xm c'est le pointeur du balayage horizontal de la matrice, La c'est la largeur de la matrice):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
        if Xm < Ladivsix then begin // 1er morceau sur 6
          PhiR := 255;
          PhiG := Xm;
          PhiB := 0;
        end else
        if (Ladivsix <= Xm) and (XM < Ladivsix * 2) then begin // 2e morceau sur 6
          PhiR := 255-Xm;
          PhiG := 255;
          PhiB := 0;
        end else
        if (Ladivsix * 2 <= Xm) and (XM < Ladivsix * 3) then begin // 3e morceau sur 6
          PhiR := 0;
          PhiG := 255;
          PhiB := XM;
        end else
        if (Ladivsix * 3 <= Xm) and (XM < Ladivsix * 4) then begin // 4e morceau sur 6
          PhiR := 0;
          PhiG := 255-Xm;
          PhiB := 255;
        end else
        if (Ladivsix * 4 <= Xm) and (XM < Ladivsix * 5) then begin // 5e morceau sur 6
          PhiR := Xm;
          PhiG := 0;
          PhiB := 255;
        end else begin // 6e morceau sur 6
          PhiR := 255;
          PhiG := 0;
          PhiB := 255-XM;
        end;
 
        FOR k := 1 TO 3 DO
          case k of
             1: r:=round(PhiR);
             2: g:=round(PhiG);
             3: b:=round(PhiB);
          end;

EDIT : pas compris à quoi servait cette boucle FOR K ... en bas dans ce contexte, alors je l'ai virée et ma foi, ça fonctionne tout aussi bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
            r := round(PhiR);
            g := round(PhiG);
            b := round(PhiB);

et après tests, je l'ai virée aussi au niveau de l'utilisation avec F1..4 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
        r := fx_jpt(Phi, fx);
        g := fx_jpt(Phi - Pi2sur3, fx);
        b := fx_jpt(Phi - D_Pi2sur3, fx); // orig -- et ici on remarque un "-" alors que maintenant c'est un "+" avec une autre valeur, lol !

Je ne mets pas d'image, c'est strictement la même que la tienne -- enfin, à l'œil, parce que mon outil de comparaison des bmp's me remonte ça, comme différences :



Les zones en couleur matérialisent les endroits où les pixels sont différents, et donc, une analyse rapide du coin supérieur droit de la première zone verte (quand le vert "monte" de 0 à 255 pour devenir jaune avec le rouge) montre un pixel à 0,255,0 dans mon fichier et à 0,254,0 pour le tien,
Va falloir que tu revois ta copie,
Ou ça peut rester comme ça.

[wiwaxia]

W: Tu devrais en toute logique te référer à un axe (x'x) orienté vers la droite (convention commune), et à un second axe (y'y) orienté vers le bas.

Il me semble pourtant que c'est ce que je fais quand je dis que le point théorique du parcours commence à 3 h et que je "monte" à 12 h pour démarrer le parcours effectif. Mais peut-être que j'utilise des mots trop terre à terre ? ...

1°) Si tu "montes" au sommet du cadran, c'est que l'ordonnée de ta position augmente, donc que l'axe correspondant (y'y) est orienté vers le haut. Attention au piège des références implicites !

2°) Je sais bien que tu déclares te rendre à la position finale par le chemin le plus court, en passant par celles correspondant à 2 heures, 1 heure et zéro heure (= 12 heures modulo 12). Cependant le cercle gradué constituant la seule référence du mouvement, ta déclaration, prise à la lettre, pourrait indiquer que tu décris un grand arc (4 heures, 5h, 6h ... 11h, 12h): grave ambiguïté.

3°) On ne saurait reprocher à des termes d'être trop "terre à terre", mais seulement imprécis; et je crois que la référence aux cadrans d'horloge a fait partie du langage d'orientation des pilotes d'avion (mais peut-être plus actuellement, du fait de l'introduction du matériel informatique). Le sens horlogique ne fait que reproduire le mouvement apparent du Soleil dans l'hémisphère Nord, ce qui est historiquement justifié puisque les premières pendules sont apparues en Europe.

... Sinon, l'autre chose qui me turlupinait se situe là, où l'on peut voir une sortie console avec des colonnes impressionnantes de nombres :
... / ...
et j'aurais aimé une explication sur ces "valeurs réelles" qui sont pour moi juste des valeurs entières complétées par ".00000".

Ou j'ai fait une confusion avec ton Pascal qui parle de Reel (on le voit bien dans tes codes) quand le mien utilise Real et donc pas de risque de confondre, ou je ne sais pas, d'où cette petite demande de précision.

Je voulais montrer la parfaite conformité de la fonction par rapport à ce qu'on en attendait, et le calcul des valeurs au format Extended était un bon moyen d'y parvenir. Il faudrait que je retrouve le programme.

PS: Je viens de ré-afficher le tableau des valeurs réelles pour la seconde version de la fonction L.M.; cela demandait une petite modification du texte source, qui m'avait échappé sur le moment. Voilà qui est fait:

# Remarque: je remplacerais des deux dernières instructions de cette fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    w:= 0.5 * (u - v);
    Result:= Round(255 * w)

par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    w:= u - v;
    Result:= Round(127.5 * w)

[wiwaxia]

À titre de curiosité, j'ai cherché (et trouvé) une série de fonctions dont des graphes se rapprochent de celui de la fonction dont on vient de parler, et finissent par se confondre avec lui lorsqu'un paramètre associé tend vers zéro.

Les calculs, un peu difficiles, ne sont pas décrits ici. Voici les graphes des fonctions couleur, correspondant à des valeurs décroissantes de (h); on retrouve exactement les expressions linéaires lorsque (h) est nul.

Le but était de rechercher la palette de luminance maximale, mais dépourvue de raies trop brillantes au niveau des couleurs secondaires - ce problème a déjà été évoqué en plusieurs occasions.

Les palettes correspondant aux deux premières valeurs de (h) - 0 et 1 - sont indiscernables; les raies brillantes s'estompent effectivement à partir de (0.05) , mais les couleurs secondaires elles-mêmes finissent par disparaître au-delà de (0.2), ce qui est à éviter.
On ne dispose donc que d'une marge relativement faible.

Note: lire "h" en place de "k" sur la dernière image; ce détail m'a échappé.

[Jipété]

Bonjour,

1°) Si tu "montes" au sommet du cadran, c'est que l'ordonnée de ta position augmente, donc que l'axe correspondant (y'y) est orienté vers le haut. Attention au piège des références implicites !

Pas exactement : si je "monte vers 12 h", c'est pour indiquer ma position sur le cadran d'une horloge et ce que je ne comprends pas dans ta réponse, c'est le texte rouge qui s'y trouve, puisque c'est exactement le cas, exemple avec cette image

où l'on voit bien les signes "-" à gauche et en bas, donc les signes "+" (sauf qu'ils ne sont pas matérialisés) en haut et à droite.

2°) Je sais bien que tu déclares te rendre à la position finale par le chemin le plus court,

Non, je ne crois pas l'avoir dit, et j'ai réalisé hier qu'en fait, pour aller de 12 h à 4 h par le sens trigo, ça faisait parcourir 2/3 du cercle.
Sauf que dans la vraie vie du processeur il ne parcourt rien, il se contente d'avoir des bits à 1 et d'autres à 0 en fonction d'instructions qui lui sont données, il le fait et basta.
Ce n'est pas comme s'il fallait aller de Nice à Rome en passant par NYC à pieds avec un sac de 50 kg sur le dos !

OK, vu les décimales, sauf que je ne sais pas ce qui a changé d'un code à l'autre, mis à part la correction mineure que tu as indiquée et qui ne change rien au résultat final : dans ton image, au jaune à bloc (abscisse à 255), le vert est encore à 254.

+++
À titre de curiosité également, j'avais posé une question, elle est passée à la trappe, donc elle revient, poussée par l'histoire du processeur ci-dessus ; je t'avais récemment demandé pourquoi ne pas écrire BEGIN u := u+v; END; plutôt que BEGIN w := u+v; u := w; END; et tu m'avais répondu que tu n'aimais pas je ne sais plus quoi à propos des registres du proc' et c'est là-dessus que je voulais une précision.

EDIT : pour la collec',

Cherchez le vert !

3 images extraites du docu "Hollywood, la vie rêvée de Lana Turner", très sympa (Arte, mercredi soir) :

[wiwaxia]

... Pas exactement : si je "monte vers 12 h", c'est pour indiquer ma position sur le cadran d'une horloge et ce que je ne comprends pas dans ta réponse, c'est le texte rouge qui s'y trouve, puisque c'est exactement le cas, exemple avec cette image

où l'on voit bien les signes "-" à gauche et en bas, donc les signes "+" (sauf qu'ils ne sont pas matérialisés) en haut et à droite ...

1°) Si tu affirmes monter du bord latéral droit du cercle (3 h) à son sommet (12h), c'est qu'il y a ascension, progression vers le haut, augmentation de l'altitude: tu te réfères donc à un axe vertical ascendant (y'y), celui du repère (xOy) que tu cites d'ailleurs immédiatement après. Or ce repère ne peut être maintenu après renversement de l'orientation des angles.

L'adoption du sens horaire exige le renversement de l'un des axes, par exemple celui de (y'y): il y a sinon incompatibilité entre les signes des coordonnées des points et les propriétés des fonctions trigonométriques.
L'argument du réalisme cynique

... En quoi ça dérange quelqu'un, si ce n'est ceux qui se cramponnent à leur sens trigo "qui est à la base de l'analyse vectorielle" dis-tu, mais ça me fait une belle jambe, je ne sais pas ce que c'est et je ne l'utiliserai donc jamais ...

auquel j'aurais été tenté de me ranger par lassitude, ne tient malheureusement pas: l'orientation de l'espace est déjà impliquée dans la fonction Arctan(y, x) (ou l'une des variantes dont on a parlé), fonction qui donne l'angle orienté vu par un observateur situé au-dessus du repère direct (xOy) qu'il regarde.
Pour la notion de repère direct, (re)voir la règle des trois doigts de la main droite, ou le bonhomme d'Ampère.

Alors de trois choses l'une:
a) Tu maintiens le sens horlogique en te référant à une repère indirect; la relation

Angle polaire(x, y) = Arctan(y/x)

demeure valide, mais tu ne pourras plus consulter les figures géométriques présentes dans tes livres ou sur la Toile, parce qu'il te faudrait les inverser toutes.
b) Tu maintiens le sens horlogique en continuant de te référer aux relations habituelles (désormais fausses) et aux schémas qui leur sont associés: il te faudra introduire des corrections de signe, et tes projets se transformeront en Festival de la Rustine, assortis de crises de découragement et de saillies du style

... parce que moi, les théorèmes aléatoires et les équations adaptatives, euh, c'est loin d'être une science exacte, hein.

c) Tu en reviens à la convention commune (celle du sens trigonométrique), et tes calculs pourront être compris (et éventuellement corrigés) par autrui.

Il faut voir plus loin que le bout de son nez, et il n'y a aucune indignité à user du langage commun.
Et si je ne suis pas suffisamment convaincant, tu peux au moins m'accorder le bénéfice du doute.

... Non, je ne crois pas l'avoir dit, et j'ai réalisé hier qu'en fait, pour aller de 12 h à 4 h par le sens trigo, ça faisait parcourir 2/3 du cercle.
Sauf que dans la vraie vie du processeur il ne parcourt rien, il se contente d'avoir des bits à 1 et d'autres à 0 en fonction d'instructions qui lui sont données, il le fait et basta.
Ce n'est pas comme s'il fallait aller de Nice à Rome en passant par NYC à pieds avec un sac de 50 kg sur le dos ! ...

Ce qui est pointé, c'est l'ambiguïté de ton langage: se déplacer sur le cadran des positions (4 h) à (12 h), c'est littéralement effectuer 2/3 de tour.
L'écart angulaire dont il est question est celui qui sépare les positions de deux composantes couleur sur le cercle. Nul n'a jamais dit que le processeur se mettait à tourner ! Tu nous entraînes en pleine confusion.

... OK, vu les décimales, sauf que je ne sais pas ce qui a changé d'un code à l'autre, mis à part la correction mineure que tu as indiquée et qui ne change rien au résultat final : dans ton image, au jaune à bloc (abscisse à 255), le vert est encore à 254 ...

J'ai listé pour vérification les valeurs réelles de la fonction étudiée, en court-circuitant tout simplement la dernière instruction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Result:= 255 * w

la valeur retournée passant ainsi au format Extended.
Je n'ai pas compris cette histoire de couleur locale (254, 255 ?). Quel est le point (ou le pixel) concerné ?

... À titre de curiosité également, j'avais posé une question, elle est passée à la trappe, donc elle revient, poussée par l'histoire du processeur ci-dessus ; je t'avais récemment demandé pourquoi ne pas écrire BEGIN u := u+v; END; plutôt que BEGIN w := u+v; u := w; END; et tu m'avais répondu que tu n'aimais pas je ne sais plus quoi à propos des registres du proc' et c'est là-dessus que je voulais une précision ...

L'affection

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

u:= ...

transfère à la variable (u) une nouvelle valeur qu'on ne trouve jusque là en aucun autre endroit du programme, et qui se substitue immédiatement à l'ancienne valeur; on ne dispose d'aucun contrôle sur l'opération, et cela me gêne.
L'instruction me paraît beaucoup moins anodine que dans le cas d'un entier.
Il se peut que ce soit généralement sans conséquence, que certains langages s'y prêtent mieux que d'autres.
Je sais aussi que la majorité des programmeurs prise la concision du code, et se moque éperdument de ces considérations byzantines. Je suis moi-même tenté de prendre des raccourcis, et d'écrire avec mauvaise conscience

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
s:= a + (b*c);
 
IF Test(i, j) THEN

Je ne vais cependant jamais plus loin - et cela peut paraître excessif.

Je sais cependant:
1) qu'on a toujours insisté, au cours de ma formation au langage Pascal, sur l'obligation de consigner dans une variable appropriée le résultat de toute fonction ou expression simple;
2) que le code le plus concis n'est pas forcément le plus rapide (à ma grande surprise, il y a trois ou quatre ans);
3) que dans certains cas l'accumulation des calculs sans variable intermédiaire conduit au désastre.

Je m'en tiens donc à la prudence: ne jamais laisser au processeur le soin de gérer les résultats intermédiaires.

[Jipété]

[...] Je m'en tiens donc à la prudence: ne jamais laisser au processeur le soin de gérer les résultats intermédiaires.

De ce que j'en connais des processeurs (et à une époque on les dépannait à l'oscilloscope et aux schémas, on voyait avec nos yeux les cafards noirs à 14 ou 16 pattes servant de briques de base pour fabriquer des registres), la mécanique électronique sait parfaitement récupérer le contenu d'une adresse mémoire et la passer à l'unité de calcul, puis récupérer un autre contenu d'une autre adresse mémoire et la passer aussi à l'ALU en lui demandant de faire telle opération sur ces deux données, puis le proc va récupérer le résultat et le stocker là où le prog lui dit de le mettre.
Pourquoi pas dans l'une des deux cases précédemment accédées et maintenant disponibles ?
Là ou ailleurs, pour le proc c'est pareil.

+++

1°) Si tu affirmes monter du bord latéral droit du cercle (3 h) à son sommet (12h), c'est qu'il y a ascension, [...]

STOP ! Tu y vois ascension, je n'y vois que position sur un cercle, pour montrer à un gamin de 5 ans (qui sait quand même lire une horloge à aiguilles, j'espère) où je me trouve, et c'est tout.

fonction qui donne l'angle orienté vu par un observateur situé au-dessus du repère direct (xOy) qu'il regarde.

Et moi je regarde ce fichu cercle ex-ac-te-ment comme je regarde une horloge : normal (au sens matheux) au centre. C'est pas bien ?

Ce qui est pointé, c'est l'ambiguïté de ton langage: se déplacer sur le cadran des positions (4 h) à (12 h), c'est littéralement effectuer 2/3 de tour.

Ce qui n'est pas clair dans le tien, c'est quand on te pose une question simple à réponse oui-non et que tu n'y réponds pas ou alors avec une longue tirade qui m'embrouille plus qu'autre chose.
La question simple c'était ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  RPhaseShift := 0 - troispisurdeux; // mon départ à 12 h
  GPhaseShift := RPhaseShift - deuxpisurtrois;
  BPhaseShift := RPhaseShift - quatrepisurtrois;

Tu préfères ?

Là, si tu me dis oui, je valide ce code et terminé !

Si tu me dis non, je valide celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  RPhaseShift := 0 + pisurdeux; // mon départ à 12 h
  GPhaseShift := RPhaseShift + quatrepisurtrois;
  BPhaseShift := RPhaseShift + deuxpisurtrois;

Ça serait bien que tu te décides, car je n'attends plus que ça pour terminer un zip que d'autres pourront tester.

Dans un cas comme dans l'autre, il y a un écart de 2/3 de cercle entre le point de départ rouge et le point vert, et encore 2/3 d'écart entre vert et bleu.
Si on tourne dans l'autre sens il n'y a plus qu'un tiers mais qu'est-ce que ça change, à part nous perturber les neurones ?

+++

Je n'ai pas compris cette histoire de couleur locale (254, 255 ?). Quel est le point (ou le pixel) concerné ?

C'est le pixel encadré en orange que j'ai mesuré à 0,254,0, mais en fait c'est toute la colonne qui est concernée, et je dirais même plus, c'est toute la zone verte qui commence à la moitié de "l'ascension" du vert qui passe de 0 à 255 normalement.



Il doit y avoir une blague dans les calculs à partir du milieu de l'ascension, blague qu'on retrouve également à la descente du rouge sombre qui vire au noir, et pareil pour les 4 autres zones.

+++

Un livre de Maths de niveau secondaire technique te serait d'un excellent secours: aisément compréhensible, et allant à l'essentiel.
Il t'éviterait de te noyer dans un verre d'eau.

[wiwaxia]

... Et moi je regarde ce fichu cercle ex-ac-te-ment comme je regarde une horloge : normal (au sens matheux) au centre. C'est pas bien ? ...

L'habitude n'est pas une justification: il y a de bonnes et de mauvaises habitudes. Et l'obsession des cadrans d'horloge, qu'aucune des études que tu as faîtes ne justifie, relève de ces dernières.
Tu fais ce que tu veux: je ne peux que te renvoyer à ton excellente bibliothèque, et il n'y a pas pire sourd que celui qui ne veut rien comprendre.

... Ce qui n'est pas clair dans le tien, c'est quand on te pose une question simple à réponse oui-non et que tu n'y réponds pas ou alors avec une longue tirade qui m'embrouille plus qu'autre chose ...

Tu exiges des justifications dans un domaine difficile, alors que tu refuses une convention d'usage: il ne faut pas t'étonner que les réponses ne soient pas évidentes. Je ne t'ai pourtant rien dit qui ne se trouve dans tes livres.

... La question simple c'était ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  RPhaseShift := 0 - troispisurdeux; // mon départ à 12 h
  GPhaseShift := RPhaseShift - deuxpisurtrois;
  BPhaseShift := RPhaseShift - quatrepisurtrois;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  RPhaseShift := 0 + pisurdeux; // mon départ à 12 h
  GPhaseShift := RPhaseShift + quatrepisurtrois;
  BPhaseShift := RPhaseShift + deuxpisurtrois;

Ça serait bien que tu te décides, car je n'attends plus que ça pour terminer un zip que d'autres pourront tester ...

Essaie l'un et l'autre bloc d'instructions: je ne saurais prédire le résultat, faute de connaître l'algorithme complet.
Je sais seulement que les teintes (R, V, B) se succèderont dans l'ordre opposé.

... C'est le pixel encadré en orange que j'ai mesuré à 0,254,0, mais en fait c'est toute la colonne qui est concernée, et je dirais même plus, c'est toute la zone verte qui commence à la moitié de "l'ascension" du vert qui passe de 0 à 255 normalement.



Il doit y avoir une blague dans les calculs à partir du milieu de l'ascension, blague qu'on retrouve également à la descente du rouge sombre qui vire au noir, et pareil pour les 4 autres zones ...

C'est ton algorithme, pas le mien. Et le comportement de ce dernier est très clair.
Essaie d'afficher comme moi les valeurs réelles de ta fonction: on verra bien ce qui se passe.