Double précision vs eedomus [Résolu]

[TJL21]

Bonjour,

J'ai déjà sollicité quelqu'un du forum sur le sujet et j'ai cherché également un peu sur le Net mais le 'php' et le 'php eedomus' étant quelque peu différents, peut-être que l'un d'entre vous pourra/ saura me dire s'il est possible d'effectuer un calcul en double précision avec les fonctions dont nous disposons ?

La raison est que je cherche à effectuer un calcul pour un script et que, si les nombres utilisés ne sont pas dans ce format, le résultat sera faux.

Merci pour votre aide

[opa95]

Bonjour
Le plus simple est de faire un script php et de l'essayer sur la box, tu verras si la précision te convient ou si le résultat du calcul est conforme à ton attente
Pour pi, il donne 3.1415926535898, je pense que ça devrait te suffire.

[TJL21]

Bonjour
Le plus simple est de faire un script php et de l'essayer sur la box, tu verras si la précision te convient ou si le résultat du calcul est conforme à ton attente
Pour pi, il donne 3.1415926535898, je pense que ça devrait te suffire.

Bonjour,

oui, c'est fait j'ai testé le script mais j'ai des erreurs dans le résultat d'où ma question

Du coup, j'essaye de comprendre d'où l'erreur peut venir...

Merci pour ta réponse, j'investigue

[thrymartin]

envoi le script et le calcul voulu
c'est peut être simplement un problème de parenthèse et de priorité d'un opérateur

pour le plugin point de rosée, ya jusqu'à un log et le résultat est conforme à ce qu'on obtient avec un tableur.

[TJL21]

envoi le script et le calcul voulu
c'est peut être simplement un problème de parenthèse et de priorité d'un opérateur

pour le plugin point de rosée, ya jusqu'à un log et le résultat est conforme à ce qu'on obtient avec un tableur.

J'allais l'envoyer en MP à la personne vers qui je m'étais tournée pour poser la question la première fois.
A la minute, cela m'est impossible de le poster ici ; certainement en début d'après-midi

[TJL21]

Voilà, comme promis, le script pour lequel je souhaite utiliser des nombres en double précision

Code : Tout sélectionner

<?

// Conversion d'une date du calendrier grégorien en jour julien (JJD).
// Julien est en l'honneur de Jules Scaliger, le père du mathématicien qui a introduit ce calendrier
// (pour les dates antérieures au 4 octobre 1582).
// A compter du 15 octobre 1582, c'est le calendrier grégorien qui est utilisé ; il est toujours notre
// calendrier actuel.
// Pour mieux comprendre, l'année 1582 a été raccourcie de 10 jours : le lendemain du jeudi 4 octobre 1582
// devenant le vendredi 15 octobre 1582.

$J = date(j) ;
$M = date(n) ;
$A = date(Y) ;
$JJD = 367 * $A - floor('1.75' * (floor(($M + 9) / 12) + $A )) + floor(275 * $M / 9) - floor('0.75' * (1 + floor('0.01' * (floor(($M - 9) / 7) + $A)))) + $J + '1721028.5' ;

$aujourdhui = date('Y/m/d') ;

// Pour déterminer le jour de changement de saison pour une année comprise entre +1000 et +3000, voici le calcul à suivre (en jour Julien) :

$DT = ($A - 2000) / 1000 ;

$E_Spring = '2451623.80984' + '365242.37404' * $DT ; // jour de l'équinoxe de printemps
$S_Summer = '2451716.56767' + '365241.62603' * $DT ; // jour du solstice d'été
$E_Autumn = '2451810.21715' + '365242.01767' * $DT ; // jour de l'équinoxe d'automne
$S_Winter = '2451900.05952' + '365242.74049' * $DT ; // jour du Solstice d'hiver


    // Conversion du jour julien en date du calendrier grégorien

    $limites = array($E_Spring, $S_Summer, $E_Autumn, $S_Winter) ;
               
    foreach ($limites as $key) {
        $a = $key + 32045 ;
        $b = floor(4 * ($a + 36524) / 146097) - 1 ;
        $c = $a - floor(146097 * $b / 4) ;
        $d = floor(4 * ($c + 365) / 1461) - 1 ;
        $e = $c - floor(1461 * $d / 4) ;
        $m = floor((5 * ($e - 1) + 2) / 153) ;

        //Résultats :
        $jour = round($e - floor(((153 * $m) + 2) / 5)) ;
        $mois = $m + 3 - 12 * floor($m / 10) ;
        if ($mois == 3) {
            $spring = "/$mois/$jour" ;
        }
        if ($mois == 6) {
            $summer = "/$mois/$jour" ;
        }
        if ($mois == 9) {
            $autumn = "/$mois/$jour" ;
        }
        if ($mois == 12) {
            $winter = "/$mois/$jour" ;
        }
    }
   
    // Définition des saisons grâce à la formule de conversion
    $saisons= array($winter => 'hiver' ,
         $autumn => 'automne' ,
         $summer => 'été' ,
         $spring => 'printemps' ,
         '/01/01' => 'hiver') ;


    //  Comparaison de la date d'aujourd'hui avec celle du changement de saison pour connaître la nôtre
    sdk_header('text/xml') ;
    foreach ($saisons AS $cle => $value) {
        $saison = date('Y').$cle;
        if (strtotime($aujourdhui)>=strtotime($saison)) {
            echo "<root>" ;
            echo "<date>".utf8_encode($aujourdhui)."</date>" ;
            echo "<saison>".utf8_encode($value)."</saison>" ;
            echo "</root>" ;
            break ;
        }
    }

?>

Avec ce script (basé sur le script initial créé par Madoma73), je désire m'approcher au plus près de la vérité et éviter d'avoir une date générique (sans vouloir offusquer le créateur du script) puisque je me suis aperçu que cette année l'été était le 20 et non le 21 juin...

Je sais, je suis perfectionniste mais on ne me changera pas à mon âge ^^

Hier soir, j'ai réalisé quelques tests rapides pour vérifier les années à venir mais j'ai dû faire une bêtise qqpart car il me semblait avoir vu une erreur pour 2023 !
Je viens de re-tester le script jusqu'en 2025 et je ne décèle plus d'anomalie

Si certains veulent regarder de leur côté, je l'accepte volontiers et aimerais avoir votre retour

Si tout fonctionne, il vous suffira de copier le code ci-dessus et de remplacer celui rédigé par Madoma73 pour le plug-in 'saison'

Amicalement,

[opa95]

Bonjour
A priori, les formules qui nécessitent réellement une bonne précision sont les 4 qui calculent les dates des saisons en notation Julien
$E_Spring = '2451623.80984' + '365242.37404' * $DT ; // jour de l'équinoxe de printemps
$DT varie de 0.001 à 1 pour les dates supérieures à 2000 et si tu testes les valeurs données par l'eedomus par rapport à une calculatrice, le résultat est bon à au moins 6 décimales près (peut-être mieux, je n'ai testé que 0.001 et 1).
Si tu veux réellement pinailler, les formules de ce type sont des approximations : il faudrait indiquer dans ce cas l'écart maximal entre la valeur calculée et la valeur vraie (Voir le site de l'observatoire de Paris). Si par malheur, le changement de saison se faisait au voisinage de minuit, tu pourrait encore avoir une valeur qui bascule d'un jour à l'autre à cause d'une seconde ou d'une minute d'erreur

[TJL21]

Bonjour,

A priori, les formules qui nécessitent réellement une bonne précision sont les 4 qui calculent les dates des saisons en notation Julien
$E_Spring = '2451623.80984' + '365242.37404' * $DT ; // jour de l'équinoxe de printemps

Oui, c'est cela ! Ces formules m'ont été communiquées par une personne de l'IMCCE (Institut de Mécanique Céleste et de Calcul des Ephémérides) et sont approximatives à 20minutes près.
Les vraies formules, enfin je veux dire celles qui m'ont été données, sont pour le printemps par exemple : Equinoxes de printemps => JD = 2451623.80984D0 + 365242.37404D0*DT
C'est là que la double précision intervient puisque le DO indique (ou requiert) cette précision.

$DT varie de 0.001 à 1 pour les dates supérieures à 2000 et si tu testes les valeurs données par l'eedomus par rapport à une calculatrice, le résultat est bon à au moins 6 décimales près (peut-être mieux, je n'ai testé que 0.001 et 1).
Si tu veux réellement pinailler, les formules de ce type sont des approximations : il faudrait indiquer dans ce cas l'écart maximal entre la valeur calculée et la valeur vraie (Voir le site de l'observatoire de Paris). Si par malheur, le changement de saison se faisait au voisinage de minuit, tu pourrait encore avoir une valeur qui bascule d'un jour à l'autre à cause d'une seconde ou d'une minute d'erreur

Honnêtement, ce que je voulais en retravaillant le script au départ, c'était de pouvoir construire quelque chose en 'php' et commencer à m'y intéresser plus profondément... maintenant que j'ai compris un minimum le fonctionnement de certaines fonctions, j'espère pouvoir m'améliorer.
Pour ce qui est de la précision, je pense qu'elle doit y être avec les formules utilisées puisque je ne décèle plus d'erreur, mais je reste en communication avec la personne de l'IMCCE pour évaluer une potentielle correction à apporter

Merci de ton retour opa95

[TJL21]

Bonjour,

Voici la réponse de la personne de l'IMCCE concernant la comparaison de ses calculs avec ceux du script :

Voici mes valeurs pour le jour julien avec la différence par rapport aux vôtres :
PRINTEMPS : 2458928.6571575 : -0.00016329996 jours = -0.23515195 min
ETE : 2459021.4000273 : -0.23515195 min
AUTOMNE : 2459115.0573401 : -0.23515195 min
HIVER : 2459204.9141665 : -0.23515195 min
L'écart est donc constant, et tient uniquement au traitement numérique interne (double précision non prise en compte). Vous devriez donc trouver la même chose que moi au niveau des dates du calendrier Grégorien. Comme ce n'est pas le cas, cela signifie donc que votre conversion vers le calendrier Grégorien n'est pas exacte.

Je vais plancher à nouveau sur le script pour vérifier sur la durée que la supposée erreur n'y est pas et, en parallèle, tester une nouvelle méthode de conversion des jours Julien en jour Grégorien au cas où celle actuellement implémentée génère quand même une erreur... bref, je vous tiens au courant.

[merguez07]

Honnetement je ne pense pas que l'erreur soit liée à un problème de précision de calcul.
je pencherais plus vers une formule incomplète

Ton gars de l'IMCCE est il bien fiable ?

[opa95]

Bonjour
Il ne s'agit pas d'un problème de précision de calcul : on trouve les mêmes résultats que toi avec ta formule sur excel pour le printemps
"$E_Spring = '2451623.80984' + '365242.37404' * $DT ; // jour de l'équinoxe de printemps"
$E_Spring=2458928,657321 et non 2458928.6571575
La formule de départ est-elle exacte?
Pour arriver au second résultat, il faut un terme du second ordre en $DT et pour que ça fonctionne aussi en 2100 (je n'ai pas été vérifier plus loin, il faudrait que j'ai les heures précises à la seconde près pour les siècles suivants).
$E_Spring = '2451623.80984' + ('365242.37404'-0.41*$DT) * $DT

[TJL21]

Ton gars de l'IMCCE est il bien fiable ?

Fiable... je dirais 'je l'espère oui' vu l'endroit où il travaille ; mais je ne le connais pas !

Lorsque je me suis penché sur la question et que je n'arrivais pas à trouver qqchose de cohérent sur le Net concernant la méthode de calcul des saisons, j'ai rédigé un message, en suivant le lien approprié, sur le site de l'IMCCE.
C'est lui qui m'a répondu et il m'a donné les formules que vous connaissez en me disant qu'elles sont approximatives à 20 minutes près (à condition de respecter la double précision (DO)

Je lui fais donc confiance car, pour moi, il sait de quoi il parle (en tout cas, il est mieux placé que moi)

[TJL21]

"$E_Spring = '2451623.80984' + '365242.37404' * $DT ; // jour de l'équinoxe de printemps"
$E_Spring=2458928,657321 et non 2458928.6571575
La formule de départ est-elle exacte?

Comme je viens de répondre à Merguez07, je suppose que la formule est correcte au vue de l'endroit où travaille la personne... après, je ne peux que "boire ses paroles" car, si je lui ai demandé conseil, c'est que je ne suis pas capable de trouver une formule par moi-même !

Pour arriver au second résultat, il faut un terme du second ordre en $DT et pour que ça fonctionne aussi en 2100 (je n'ai pas été vérifier plus loin, il faudrait que j'ai les heures précises à la seconde près pour les siècles suivants).
$E_Spring = '2451623.80984' + ('365242.37404'-0.41*$DT) * $DT

Je ne suis pas sûr de bien comprendre là peux-tu être plus explicite ?

[opa95]

Bonjour TJL21
Si on applique strictement la formule indiquée, on obtient avec une calculatrice ou excel ton résultat pour l'année 2020 qui correspond à $DT=0.020.
La formule que tu utilises correspond à une approximation linéaire de la forme :
Date = a+ b*$DT avec a=2451623,80984 et b=365242,37404 qui donne
Date=2458928,657321 pour $DT=0,020.
On peut même faire le calcul à la main :
b*$DT= 365242,37404*0,020=7304,8474808 et donc Date = 2451623,80984+7304,8474808
soit Date = 2458928,6573208 arrondi à 2458928,657321
Si la formule est exacte et ne correspond pas à une approximation, on ne peut rien y faire.
Les valeurs données par ton correspondant ne correspondent pas exactement à la formule utilisée.
Si l'on suppose que l'IMCCE a une méthode de calcul plus sophistiquée et donc que les résultats donnés sont bons, il faut utiliser une meilleure approximation en utilisant 3 coefficients au lieu de 2.
Pour déterminer ces coefficients, on utilise en général une méthode de moindres carrés en ajustant au mieux la formule aux valeurs exactes pour 2020, 2100, 2200..., plus il y en a, mieux c'est.
Pour faire, vite j'ai utilisé en plus de la valeur de 2020 la seule valeur du printemps 2100 (malheureusement je n'ai pas la valeur des secondes) et j'ai ajusté le troisième terme :
Date = a+ b*$DT + c*($DT)² avec a=2451623,80984 et b=365242,37404 j'ai trouvé c=-0,41 (valeur approchée, car je n'ai pas assez de précision sur 2100).
Dans le cas de $DT=0,02 (2020), $(DT)^2= 0,0004 et donc c*($DT)² = -0,41*0,0004=-0,000164
Donc Date=2458928,6573208-0,000164=2458928,657157 au lieu du 2458928,657158 proposé. (si tu remplace -0,41 par-0,408 tu obtiens le résultat proposé 2458928,657158, mais il faudrait les valeurs exactes pour 2100,... pour savoir si c'est plus pertinent).
Si tu gardes la valeur de -0.408 je pense que ce sera correct au moins jusqu'en 2100, ça devrait suffire à ton application.
Tous ces résultats sont rigoureusement exacts si tant est que a, b et la valeur de la date soit bien 2458928,657158 : Il n'y a plus de problème de double précision ou autre.

[merguez07]

Je lui fais donc confiance car, pour moi, il sait de quoi il parle (en tout cas, il est mieux placé que moi)

OK mais tu es bien d'accord qu'il t'a donné une formule approchée (la preuve c'est qu'il indique qu'elle sera précise à 20 mn près). Donc du coup je comprends pas pourquoi il te dit que tes résultats sont différents des siens puisque la différence est de moins d'un minute et que lui utilise certainement une équation bien plus élaborée.

En tout état de cause, oublie le fait que l'erreur provient d'un problème de précision. Ce n'est pas le cas.

[TJL21]

Donc du coup je comprends pas pourquoi il te dit que tes résultats sont différents des siens puisque la différence est de moins d'un minute et que lui utilise certainement une équation bien plus élaborée.

De ce que j'ai compris, la comparaison se fait à partir de le même formule mais, étant donné que la double précision est manquante "chez nous" (réflexion élaborée par lui en fonction de ce qui est obtenu avec le script), cela induit cette différence dans le résultat !

[merguez07]

De ce que j'ai compris, la comparaison se fait à partir de le même formule mais, étant donné que la double précision est manquante "chez nous" (réflexion élaborée par lui en fonction de ce qui est obtenu avec le script), cela induit cette différence dans le résultat !

je reste convaincue qu'il n'utilise pas la même formule et que cette histoire d'absence de double précision dans nos calculs est un fantasme

[opa95]

Bonjour
Je suis tout à fait d'accord avec Merguez, quand on fait le calcul "à la main" les résultats sont exacts : il n'y a aucun effet de précision simple, double ou infinie comme le permettrait un langage comme "Lisp".
Eedomus donne le même résultat que le calcul à la main, il n'y a pas de problème de précision, le résultat de Eedomus est le bon si les données de départ sont les bonnes.
L'autre calcul n'est pas correct : soit il utilise une autre formule, soit il utilise des stockages intermédiaires qui ne sont pas assez précis.
Pour le problème de calendrier, si l'erreur est de l'ordre de la minute, je ne pense pas que ça perturbe beaucoup le fonctionnement.
Quant au calcul précis des heures de coucher et de lever du soleil et donc de durée du jour, ça dépend aussi du lieu d'observation et on trouve sur le net de belles formules qui prennent au moins 10 lignes...
Tout cela est-il bien nécessaire?
Bref l'important est que l'Eedomus fonctionne bien.

[opa95]

Bonjour TJL21
Le résultat de l'eedomus étant identique au calcul à la main, il est juste si les constantes sont justes.
Pour la formule initiale "JD = 2451623.80984D0 + 365242.37404D0*DT", je ne sais pas dans quel langage elle est implémentée, mais j'aurais tendance à soupçonnée une mauvaise interprétation par le compilateur, peut-être faut-il que JD et DT soient bien déclarés en double précision.
Il serait intéressant de tester le résultat de l'opération 365242.37404D0*DT avec DT=0.02 et de le comparer au calcul manuel.

[TJL21]

Bonjour à tous les deux,

Merci pour vos réponses et vos réflexions sur le sujet.
Je ne veux mettre la parole de personne en doute et je prends en compte tous les retours (les vôtres ainsi que ceux de la personne de l'IMCCE).

Il est clair que je ne cherche pas à faire un script parfait et la vingtaine de minutes de précision mentionnée me suffit largement... tant que le résultat tombe juste jusqu'à la fin du siècle (après, je ne serai plus de ce monde).

Je vais être en vacances la semaine prochaine ; j'espère pouvoir prendre le temps de regarder de plus près tes explications opa95 (rien de sûr avec mes travaux).

Je pense que l'on peut clore le débat ; qu'en pensez-vous ?
Comment fait-on pour indiquer 'résolu' en face du sujet svp ?