Forum TI-Planet.org

Bug de nClock signalé sur cnCalc : http://www.cncalc.org/thread-11948-1-1.html


Le programme nous indique donc :

• Thu 5 janvier 2016 (soit jeudi au lieu de mardi)
• Fri 6 janvier 2016 (soit vendredi au lieu de mercredi)

Je viens de tester sur TI-Nspire CX CAS avec Ndless 4.0.3, et le programme m'apprend que nous sommes aujourd'hui 7 janvier 2016 un samedi, et que je n'aurais donc pas dû aller travailler...



Dans tous les cas il semble donc y avoir un décalage de 2 jours.
Un problème dans le cas particulier de l'année 2016 bissextile ? Ou bien personne n'avait jamais remarqué que ça ne marchait pas ?

Tout ce qu'a fait la mise à jour récente du programme, c'est :

• rajouter 4 syscalls pour la gestion de 4 OS supplémentaires
• mise à jour du Makefile pour utilisation du dernier SDK Ndless

Cela n'aurait pas dû introduire de bug.

Je ne l'ai pas mis à jour depuis un moment, et j'ai Thu 06 Jan 2016.
Je précise de plus que je demande le 7, elle me met quand même le 6 -.-

Je pense qu'en fait les gens n'ont même pas remarqué (en tout cas moi j'ai rien vu) parce que l'intérêt principal est la miniclock.

J'avais remarqué cela mais pensant que c'était dû à une mauvaise config, ne l'ai pas signalé

Ok, merci pour vos confirmations.

Quelle erreur Levak aurait-il donc commise dans le code suivant que j'ai bien du mal à suivre ?

Code: Select all

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;
    int r = year - (d<<2)*25;
    return weekdays[(year_codes[d&3] + r + (r>>2) + ((r&3)==0) + month_codes[month-1] + day + 1) % 7];
}

Je comprends qu'il y a entre autres un test sur les années bissextiles, mais ne sais pas si il est exact (pour référence : une année est bissextile si elle est divisible par 4, à l'exception des changements de siècle qui ne sont pas bissextiles, et à l'exception à nouveau des changements de millénaire qui sont bissextiles).

critor wrote:(pour référence : une année est bissextile si elle est divisible par 4, à l'exception des changements de siècle qui ne sont pas bissextiles, et à l'exception à nouveau des changements de millénaire qui sont bissextiles).

Si une année n'est pas multiple de 4, on s'arrête là, elle n'est pas bissextile.
Si elle est multiple de 4, on regarde si elle est multiple de 100.
Si c'est le cas, on regarde si elle est multiple de 400.
Si c'est le cas, l'année est bissextile.
Sinon, elle n'est pas bissextile.
Sinon, elle est bissextile.

Voilà le test pour savoir si une année est bisextile

Je sais. Mais maintenant, dis-nous si c'est bien ce que fait le test de Levak dans mon post précédent.
Et si c'est bien ce qu'il fait, quelle est l'erreur alors ?
@+

Je ne comprends pas du tout le calcul en fait. Tout ce que je vois c'est des divisions et multiplications par 4 (logique pour les bissectiles) et par 25 (ce qui combiné avec les 4 donne peut être les 100 pour les siècles) mais je ne vois rien de plus clair.

Sinon, vous pouvez peut être tenter de remplacer ce code par une des implémentations décrites par wikipédia ?
https://en.wikipedia.org/wiki/Determina ... nt_methods

Non, il calcule juste le jour de la semaine.
J'ai l’impression qu'il prend en conte les années bissextiles.
Vu les calculs qui fait.
C'est peut-être sa combinaison qui ne marche pas bien

neuronix wrote:Non, il calcule juste le jour de la semaine.
J'ai l’impression qu'il prend en conte les années bissextiles.
Vu les calculs qui fait.
C'est peut-être sa combinaison qui ne marche pas bien

Tout ça, on avait bien compris...

Si le symbole & est bien utilisé pour le modulo, comme je le pense, à la ligne 8 il faudrait plutôt écrire :

Code: Select all

return weekdays[(year_codes[d&4] + r + (r>>2) + ((r&4)==0) + month_codes[month-1] + day + 1) % 7];

Autrement dit, faire des modulo 4 et non des modulo 3 !!