Bug semaine nClock

[Hayleia]

non, le & est un "et", le modulo c'est % (comme vu à la fin, avec le %7). Du coup, &3 c'est bien %4 en binaire sur des nombres positifs.

[Bisam]

Flûte...
Dans tous les cas, je doute que celui qui a écrit cette ligne l'ait pondu tout seul, donc il suffirait de trouver la source et de vérifier s'il n'y a pas une erreur de copie ou de conversion.

[Hayleia]

Bon ben je sais toujours pas ce que fait le code de Levak mais je confirme que celui de Wikipédia (que je ne comprends pas non plus ) marche.

screenshit.png

[Adriweb]

Dans certains cas, le & peut être équivalent à un modulo, cependant.
Mais bref, ramenez Levak dans ce topic...

[critor]

Mais bref, ramenez Levak dans ce topic...

T'aimes bien confier des missions impossibles, toi...

Pour les syscalls, j'ai commencé à lui dire la veille de la sortie de Ndless 4, et au final j'ai quand même dû me les taper après.
Alors là qu'il faut visiblement en plus réfléchir...

Flûte...
Dans tous les cas, je doute que celui qui a écrit cette ligne l'ait pondu tout seul, donc il suffirait de trouver la source et de vérifier s'il n'y a pas une erreur de copie ou de conversion.

Comme il s'agit ici de Levak, je ne serais pas si prompt à exclure que cette ligne soit le fruit direct de ses pensées.

[critor]

On trouve un algorithme approchant sur Internet : http://blog.artofmemory.com/how-to-calc ... -4203.html
De façon générale, il faut calculer :
(code_année - code_année_bissextile + code_mois + code_siècle + numéro_jour) mod 7

Ci-dessous identifiés par code couleur et commenté, ce que fait Levak :
static short year_codes[] = {5, 4, 2, 0};
static short month_codes[] = {0, 3, 3, 6, 1, 4, 6, 2, 5, 0, 3, 5};
static char weekdays[][4] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
char * getWeekDay(int year, int month, int day) {
int d = (year>>2)/25; // YY si l'année s'écrit YYyy
int r = year - (d<<2)*25; // yy si l'année s'écrit YYyy
return weekdays[(year_codes[d&3] + r + (r>>2) + ((r&3)==0) + month_codes[month-1] + day + 1) % 7];
}

C'est ressemblant, mais différent également.
Le code de l'année bissextile n'apparaît pas clairement ici.
Avec le code du siècle, ils ont peut-être été mal fusionnés avec les instructions s'occupant du code de l'année.
Un 1 est ajouté à la fin alors que n'apparaissant pas dans la formule décrite.
De plus, les codes siècles utilisés ici, 5420, diffèrent légèrement de ceux documentés sur le lien ci-dessus, 6420.

1700s = 4
1800s = 2
1900s = 0
2000s = 6
2100s = 4
2200s = 2
2300s = 0

Si on modifie les codes siècles 6420 en 5420 (la différence concerne les années 2000 à 2099), et si on enlève le +1 final, cela corrige bien le décalage de 2 jours constaté.
Mais il ne faudrait pas que cette correction fausse alors d'autres dates...

Tout-le-monde a-t-il toujours eu un décalage de +2 jours pour toute année 2000 à 2099, et de +1 jour pour les années 2100 à 2399 ?
(les années antérieures à 2000 ne semblent pas gérées correctement)

[critor]

J'ai fait des essais avec plusieurs dates et mauvaise nouvelle, l'erreur est variable.

Elle ne peut donc pas être corrigée de la façon simple décrite précédemment.

Pour rappel, il s'agit donc de trouver le modulo 7 de la somme algébrique :
(code_année - code_année_bissextile + code_mois + code_siècle + numéro_jour

Résumons les différents morceaux du calcul de Levak, après analyse :

• + year_codes[d&3] // code siècle - semble OK pour année dans [1900;1999]U[2100;2399] et faux sur [2000;2099]
• + r + (r>>2) // code année - semble OK
• + month_codes[month-1] // code mois - semble OK
• + day // jour du mois - semble OK
• + ((r&3)==0) + 1

Par élimination, la dernière partie de cette somme algébrique ne peut concerner que le code année bissextile.
Voici ce que dit http://blog.artofmemory.com/how-to-calc ... -4203.html à ce sujet :

Leap Year Code
The other thing to take into account is whether you are dealing with a leap year. EDIT: If the date is in a January or February of a leap year, you have to subtract one from your total before the final step.
Gregorian Calendar
If you can divide a Gregorian year by 4, it’s a leap year, unless it’s divisible by 100. But it is a leap year if it’s divisible by 400.

Ce n'est pas du tout ce que fait le programme avec "+ ((r&3)==0) + 1"...
Il ajoute au lieu de soustraire, et semble totalement ignorer les tests de divisions par 100 ou 400, se contentant du test de division par 4.
De plus, il ne vérifie pas du tout que l'on est bien en janvier ou février.


Mais je suis quand même très surpris que Levak ait pu foirer un algo de façon aussi grossière...
Ou alors, il a développé et donc testé pendant les rares périodes de dates sur [2000;2099] où les 2 erreurs (siècle+ correction année bissextile) s'annulent...

[critor]

Je pense que j'ai réussi à corriger.
Je viens de tester plein de dates entre 1970 et 2039, bissextiles ou pas, avec des résultats corrects à chaque fois.

Et je me moque complètement du fait que ce ne soit pas optimisé - ça marche à la différence, ce qui aurait dû être la priorité :

Code: Select all

// for example, see http://blog.artofmemory.com/how-to-calculate-the-day-of-the-week-4203.html
char * getWeekDay(int year, int month, int day) {
    int d = (year>>2)/25; // century
    int r = year - (d<<2)*25; // year with 2 digits
// (Century Code + Year Code + Month Code + Date Number – Leap Year Code) mod 7
    return weekdays[(year_codes[d&3]                  // century code
               + r + (r>>2)                     // year code
               + month_codes[month-1]               // month code
               + day                           // date number (day of month)
               - (((month<=2)&&isLeapYear(year))?1:0)   // leap year code
               ) % 7];
}

Cela aurait été bien de commenter le truc dès le début.

Je précise de plus que je demande le 7, elle me met quand même le 6 -.-

C'est un autre bug que je viens de constater lors de ma série de tests.
Certaines années (juste avant une année bissextile on dirait), la date réglée prend 1 jour de plus ou de moins que ce que tu as saisi.

Dans le cas ou ça fait 1 jour de moins et que tu as saisi un 1er janvier, le programme t'affiche fièrement et sans broncher que nous sommes le 00 janvier...
Décidément, ce Levak et les années bissextiles, ça fait deux...



Là, c'est moins évident...

La date est stockée en tant que timestamp :

Code: Select all

                if(askDate(&year, &month, &day, &hour, &min, &sec)) {
                    timestamp = date2timestamp(year, month, day, hour, min, sec);

On peut imaginer un bug lors de cette conversion en timestamp, surtout qu'il y a des tests d'année bissextile qui ne me plaisent pas :

Code: Select all

long date2timestamp(int year, int month, int day, int hr, int min, int sec) {
    sec = time2timestamp(hr, min, sec);
    int ly = isLeapYear(year);
    for(--month; month > 0; --month)
        day += maxDayInMonth(month, ly);
    year -= 1970;
    day += 365*year - (!ly ? 1 : 0) + (year >> 2);
    return sec + day*86400;
}

Mais il y aurait aussi au moins un autre bug, car même avec un mauvais timestamp jamais le programme ne devrait être capable d'afficher qu'on est un "00 janvier".
Peut-être à la reconversion du timestamp, mais sans garantie :

Code: Select all

void timestamp2day(long t, int * year, int * month, int * day) {
    *year = t/nb_days_in_year;
    *day = t - (*year)*nb_days_in_year;
    *year += 1970;

    int leap_year = isLeapYear(*year);

    *month = 1;
    int max_day = 0;
    while(*day > max_day) {
        *day -= max_day;
        max_day = maxDayInMonth(*month, leap_year);
        ++*month;
    }
    --*month;
}

Ce n'est pas urgent, mais il me semble également y avoir encore un autre bug.
L'affichage devient totalement corrompu au-delà de l'année 2039.
Or selon mes calculs, le nombre de secondes écoulées depuis le 1er janvier 1970 est alors encore très loin d'avoir épuisé les 32 bits du timestamp...

[Adriweb]

On peut espérer que les Nspire seront un poil obsolètes en 2039

[Anonyme0]

Le bug de l'an 2038 est bien une réalité, le timestamp 32 bits sera complétement finit le 19 janvier 2038 (étrange que ça te le fasse en 2039).