Le topic de la programmation, string, chaînes, cuir et compagnie

[Nilsou]

On est bien d'accord

Ha oui oui oui, je plaide coupable pour mon cast foireux. En fait c'était ma première supposition mais le fait que la valeur soit "cohérente" m'a fait buggé, souvent avec des casts partiels ou foireux on a des valeurs carrément éloigné ou sans aucun sens en contexte. Je n'avais pas pensé à la façon dont sont codé les float, j'étais un peu crevé aussi .

[Møgluglu]

time_val est une mesure d'intervalle, il veut récupérer le nb de secondes depuis le 1/1/1970. Pourquoi pas, c'est pas sa question.

Je comprends pas trop ce que tu veux dire. Que ce soit un nombre d'années à partir de la naissance du petit Jésus ou un nombre de secondes à partir de l'Epoch sacrée des Unixiens, c'est juste une putain de date.
Ça seraient des durées si l'Epoch ou JC étaient autre chose que des dates arbitraires.

À la limite, si on comptait à partir du Big Bang, ça pourrait avoir du sens d'utiliser des flottants.

(Après, ça ne me choque pas plus que ça hein, tout le monde utilise du flottant tout le temps là où on devrait utiliser de la virgule fixe, on n'est plus à ça près.)

[TiNitro]

J'ai pas du être clair bowdel. Je voulais juste dire que justement on ne sait pas ce qu'il veut en faire, et que la priorité c'était déjà de lui trouver ce qui foirait.
Après je vois milles raisons de caster un intervalle en secondes dans un réel.... et un float ou un double, c'est assez naturel sur les architectures courantes.

Pour tout t'avouer, je ne sais même pas comment faire de la virgule fixe dans mon C++

[Tramb]

En fait time_t peut être de largeur différente ou déjà être un double dans le standard POSIX. Donc inutile de dire que tout cela est un peu périlleux

[Møgluglu]

Bon, je sais je radote, mais je rappelle que représenter des dates dans des flottants il y en a qui ont essayé, ils ont eu des problèmes.

[Tramb]

Bon, je sais je radote, mais je rappelle que représenter des dates dans des flottants il y en a qui ont essayé, ils ont eu des problèmes.

Ca n'empêche pas certains d'essayer, hein.

[Tramb]

J'ai pas du être clair bowdel. Je voulais juste dire que justement on ne sait pas ce qu'il veut en faire, et que la priorité c'était déjà de lui trouver ce qui foirait.
Après je vois milles raisons de caster un intervalle en secondes dans un réel.... et un float ou un double, c'est assez naturel sur les architectures courantes.

Pour tout t'avouer, je ne sais même pas comment faire de la virgule fixe dans mon C++

Bah voilà, moi je ne vois pas les mille raisons de caster des dates dans un flottant.
Les dates dans des types de dates (c'est pas pour rien que y a time_t dans POSIX et pas un long ou chaipaquoi).
Les durées, aka des différences de dates, tu peux éventuellement en foutre des float si tu sais ce que tu fais.
Genre de l'intégration numérique comme dans l'article de Moleglouglou.

Avec un bon assert comme quoi on n'a pas perdu de précision c'est encore mieux quand on prend des risques
int dt;
float fDt = (float)dt;
assert((int)fDt == dt);

(ça n'empêchera pas le missile de se crasher mais c'est un bon réflexe à avoir)

[TiNitro]

je me mettais juste dans une situation du genre calcul de distance parcourue = vitesse x durée. Vitesse et distance sont des float. T'as besoin de la durée en seconde et en float.
Et ta durée, tu la calculeras comme une différence de date.
Ça dépend dans quoi on bosse quoi, je travaille sur des prévisions depuis belle lurette, donc multiplier un double par un nombre de jours j'ai du le faire whatmille fois.

Après on est d'accord, c'est une différence de date qui m'intéresse, et il y a mieux que time_t pour faire ça....

[Møgluglu]

En fait vous êtes violemment en accord complet.
Dans cet exemple ce que dit Tramb, c'est qu'il ne faut pas calculer distance_parcourue = vitesse × float(date_fin) - vitesse × float(date_début), mais bien distance_parcourue = vitesse × float(date_fin - date_début).
La soustraction est exacte mais amplifie les erreurs précédentes, donc il faut la faire au début, et avant toute conversion avec arrondi. Dans ce cas c'est évident, dans d'autres nettement moins (genre les formules du produit scalaire ou de la solution d'une équation du second degré qu'on apprend à l'école qui sont numériquement toutes pourries).

[TiNitro]

ouais voilà.
Violemment.

Pfiouuuu, on passe à aut'chose ?

[Tomaka17]

Pfiouuuu, on passe à aut'chose ?

Rust est la "most-loved technology" de stackoverflow : http://stackoverflow.com/research/de...ded-and-wanted

[TiNitro]

faudra que je me tente un coup de Rust sur CodinGame tiens, à force.

[Nilsou]

Pour revenir sur l'histoire du temps.
Mais du coups, si je veut faire une simple représentation d'une équation temporelle dans laquelle le point d'origine est important (pour la phase). Je fais comment ?
Ça veut dire qu'il est interdit d’écrire un simple :

Sin ( temps ) car temps finira de toute manière par dépasser les bornes et pouf. Alors il reste quoi comme méthode, écrire ce genre d’équation en différentielle ? Ce qui est, vous l'admettrez, un peu relou ...

[Tramb]

Tu veux faire quoi exactement ? La plotter ?

[Nilsou]

Bah l'utiliser dans une équation qui évolue temporellement.
La plupart de mes équations sont incrémentales donc je n'ai pas rencontré ce soucis (réseaux de neurones) . Mais là j'avais besoin d'un bête sinus qui évolue temporellement. Je me rend compte que c'est plus chiant que je ne le croyais ...
La seule solution "propre" que je vois serait d'utiliser
Sin(t+dt) = sin(t)cos(dt)+cos(t)sin(dt)
en utilisant cos²+sin² = 1 pour avoir cos(t).

Comme ça on utilise que des fonctions de Dt et l'ancienne valeur de sin, mais bonjour l'équation pour faire un sinus quoi

[Møgluglu]

Bah l'utiliser dans une équation qui évolue temporellement.
La plupart de mes équations sont incrémentales donc je n'ai pas rencontré ce soucis (réseaux de neurones) . Mais là j'avais besoin d'un bête sinus qui évolue temporellement. Je me rend compte que c'est plus chiant que je ne le croyais ...
La seule solution "propre" que je vois serait d'utiliser
Sin(t+dt) = sin(t)cos(dt)+cos(t)sin(dt)
en utilisant cos²+sin² = 1 pour avoir cos(t).

Comme ça on utilise que des fonctions de Dt et l'ancienne valeur de sin, mais bonjour l'équation pour faire un sinus quoi

Non tu as raison, ça c'est un coup à avoir une dérive progressive et se prendre un Scud sur la gueule. Par contre c'est toi qui places le temps d'origine t0, et c'est pas le 1er janvier 1970 ?
Avec une bibliothèque mathématique digne de ce nom, sin(t) restera précis jusqu'à t très grand. Par contre c'est t qui sera de moins en moins précis en absolu. Je ne sais pas tes ordres de grandeur, mais en double tu dois avoir de la marge.
Je suppose que Pi n'apparaît nulle part dans le calcul de t ?

[Tramb]

Un filtre harmonique comme tu fais à base de sin((n+1)t) en fonction de sin(nt), c'est une très bonne solution très stable à ce problème, en effet.
Après si tu connais la durée max d'évaluation de ta fonction, tous les coups sont permis hein !

[Nilsou]

Non tu as raison, ça c'est un coup à avoir une dérive progressive et se prendre un Scud sur la gueule. Par contre c'est toi qui places le temps d'origine t0, et c'est pas le 1er janvier 1970 ?
Avec une bibliothèque mathématique digne de ce nom, sin(t) restera précis jusqu'à t très grand. Par contre c'est t qui sera de moins en moins précis en absolu. Je ne sais pas tes ordres de grandeur, mais en double tu dois avoir de la marge.
Je suppose que Pi n'apparaît nulle part dans le calcul de t ?

Si si c'est :
2 * PI * freq * time

- - - Mise à jour - - -

Un filtre harmonique comme tu fais à base de sin((n+1)t) en fonction de sin(nt), c'est une très bonne solution très stable à ce problème, en effet.
Après si tu connais la durée max d'évaluation de ta fonction, tous les coups sont permis hein !

Nan mais je fais des cerveaux électroniques, en théories j'ai pas de durée max.
En pratique j'en ai évidemment, mais si je me retrouve à planter pour des raison inconnues sur des expe d'un mois ça va pas le faire .

Donc pas d'autres solutions réellement "propre" ? Snif quoi ...

D'ailleurs j'y pense, time_t c'est quoi sa limitation ? J'imagine qu’il y a une sacré marge mais bon ...

[Møgluglu]

Si si c'est :
2 * PI * freq * time

Bah ça semble nettement plus facile alors, à chaque période 1 / freq tu sais que tu reviens à zéro. Si ta fréquence est un rationnel, il y a un multiple de la période qui correspondra à un nombre entier de tics d'horloge.
Et tu peux utiliser sinpi et cospi aussi, dispo dans toute bonne libm.

Bien entendu on encule les mouches : sur un système moderne, timeval a un nombre de secondes sur 32 bits et un nombre de microsecondes qui tient sur sur log2(10^6) < 20 bits. Le tout tient exactement dans la précision de 52 bits d'un double, sans perte. Si tu passes à clock_gettime, là on arrive à 62 bits et ça peut se discuter.

[Nilsou]

Tu propose donc de faire la soustraction à chaque fois ?
Ok pour l'enculage de mouche, je vais rester sur une solution sur un double du coups.

Intéressant pour clock_gettime, j'utilise parfois la fonction, j'essaierais de faire attention.

[vectra]

Canard les coucous

Je regarde la fonction madvise sous linux qui, avec l'argument HUGEPAGE et une allocation mémoire par mmap + ANONYMOUS plutôt que par malloc/calloc, pourrait permettre une lecture/écriture séquentielle un peu plus performante en expliquant au kernel et en partculier au mécanisme de pagination de bien vouloir gentiment nous laisser tranquilles.

Je lis et je teste, je vous dirais si j'obtiens des résultats qui vont bien. Mais si ça rappelle des vieux souvenirs à des papys en noir, n'hésitez pas à venir radoter ici
En particulier, ce qui m'effraierait assez, c'est que le compilateur fasse ça tout seul dans certains cas.

[war-p]

Rust est la "most-loved technology" de stackoverflow : http://stackoverflow.com/research/de...ded-and-wanted

Tiens en parlant de ça, ça compile glium chez toi avec les breaking changes de la 1.7?

[Tomaka17]

Tiens en parlant de ça, ça compile glium chez toi avec les breaking changes de la 1.7?

Un type a publié une version de sa lib qui compile pas.

[Møgluglu]

En particulier, ce qui m'effraierait assez, c'est que le compilateur fasse ça tout seul dans certains cas.

Le compilo non, mais l'OS si.

De toute façon pour des accès séquentiels je prédis que ça ne changera strictement que dalle : chaque niveau de TLB est dimensionné pour couvrir tout le niveau de cache correspondant même avec des pages de 4K. Les cas où tu risques de thrasher tes TLB sont quand tu as des données sparse (mais pas trop, genre avec des lignes de cache pleines mais des pages de 4K creuses).

[war-p]

Un type a publié une version de sa lib qui compile pas.

Ok, du coup faut forcer la dernière version que t'as commit?

[Tomaka17]

Ok, du coup faut forcer la dernière version que t'as commit?

Ouai je pense. J'avoue que j'ai plus ou moins perdu le fil de ma propre lib.
Je me concentre à 100% sur ma lib Vulkan pour l'instant, et en attendant je laisse les gens qui ont l'accès review et merge les PRs.

[vectra]

Le compilo non, mais l'OS si.

De toute façon pour des accès séquentiels je prédis que ça ne changera strictement que dalle : chaque niveau de TLB est dimensionné pour couvrir tout le niveau de cache correspondant même avec des pages de 4K. Les cas où tu risques de thrasher tes TLB sont quand tu as des données sparse (mais pas trop, genre avec des lignes de cache pleines mais des pages de 4K creuses).

Merci Moglu!

Faut que je trouve moyen de te caser quelque part dans le manuscrit, toi et les autres coins, pour votre contribution aux parties info.
J'ai même inclus des images de tests HFR (avec l'accord des gars), alors au point où j'en suis, pourquoi pas un dessin de Couly

[Møgluglu]

Tu propose donc de faire la soustraction à chaque fois ?

Je ne sais pas, je n'ai pas vu ton code. Mais l'idée est que tu as intérêt à avoir la même référence pour tous les calculs de temps : le risque quand tu mélanges des temps relatifs et des dates absolues est que l'un dérive par rapport à l'autre, et que ta phase ne veuille plus rien dire. Si tu fais tout en relatif, ça peut dériver aussi, mais quand tout dérive en même temps c'est souvent moins grave (ça change juste très légèrement la fréquence, la phase reste cohérente à défaut d'être correcte).

Donc soit tu calcules tout en relatif, soit tout en absolu, mais évite le mélange des genres.

[vectra]

Le compilo non, mais l'OS si.

De toute façon pour des accès séquentiels je prédis que ça ne changera strictement que dalle : chaque niveau de TLB est dimensionné pour couvrir tout le niveau de cache correspondant même avec des pages de 4K. Les cas où tu risques de thrasher tes TLB sont quand tu as des données sparse (mais pas trop, genre avec des lignes de cache pleines mais des pages de 4K creuses).

Ben j'ai fait les tests et ça change que d'alle. Pire, ça ralentit à mort si on fait pas tout bien.

Pour le fun:

#define ARRAY_MMAP_ALLOC(TAB, DIM, DATATYPE) \ 
TAB = (DATATYPE *) mmap(0, DIM * sizeof(DATATYPE),	\
			PROT_READ|PROT_WRITE,		\
			MAP_PRIVATE|MAP_ANONYMOUS,	\
			-1, 0);				\
								\
MSG_ASSERT( TAB != MAP_FAILED, "mmap allocation failed" );	\
posix_memalign( (void**) &TAB, 64, N * sizeof(DATATYPE) ); \
madvise(TAB, DIM * sizeof(DATATYPE), MADV_HUGEPAGE);			\

[war-p]

Ouai je pense. J'avoue que j'ai plus ou moins perdu le fil de ma propre lib.
Je me concentre à 100% sur ma lib Vulkan pour l'instant, et en attendant je laisse les gens qui ont l'accès review et merge les PRs.

Bon, après investigation, apparemment, c'est cgmath qui fout la merde avec la 1.7, pas glium directement. Je sens que ça va se terminer avec Piston cette histoire