Je voulais voir si on pouvait remplacer l'iDCT typique des compressions par une approximation polynomiale qui permet entre autre de faire des opérations directement sur les coefficient, ce qui me semble impossible avec une image sous forme d'IDCT (mais je me trompe peut-être). Est-ce qu'une image pourrait être considéré comme une fonction holomorphe d'un plan ?
Je parlais de coef complexe mais aussi de "résultat" complexe ou en quaternion, si on prend une image comme une fonction de x,y et qui rend un triplet RGB (ou autre). donc f(x,y) -> (r,g,b) que l'on pourrait traduire en (f(x,y,z,t) -> (r,g,b,0) pour utiliser des quaternions, ou encore f(x,y) -> (Y) dans le cas noir et blanc, plus simple.
Disons que j'ai un cas en tête qui doit tomber pile poile dans le cas pathologique. Il s'agissait de parser des fichiers de petites tailles. En C, j'aurais simplement utiliser un char[] de taille "suffisante", en ocaml, buffer ne propose pas les même fonction de parse que string, la conversion est donc obligatoire.
Donc, chaque fichier utilise une string de qq ko. J'imagine que vu la taille, elle n'est pas alloué dans le tas mineur mais directement dans le tas majeur. Donc, si tu parses 10 000 fichiers, la limitation sera le GC. En jouant sur les options, j'ai gagné 15% de perf, en utilisant beaucoup plus de mémoire. J'imagine que l'idéal serait un allocateur qui recycle les vieux objets de grandes tailles, cela évite de réallouer la mémoire.
Ce cas était tellement énervant, car en C ou C++, il n'y aurait eu aucune allocation pendant la durée de la boucle. Et au final, le temps était passé dans la gestion mémoire.
Je tient un prof de math, je pose ma question : est-ce que les polynômes de complexe ou de quaternion existent et ont les mêmes propriétés que les polynômes avec des réels ?
J'ai l'impression que cette branche des mathématiques a un peu laissé la place aux matrices, mais les cours parlent beaucoup des polynômes. De plus les opérations sur les matrices sont un peu moins "souple".
Je voulais m'amuser avec les approximations polynomiales sur des images, avec un polynôme classique, on ne peut faire qu'une "couleur" sur une ligne (une courbe quoi). Avec un complexe, on pourrait faire une image avec une couleur, etc…
Entièrement d'accord, mais si ton object fait 100ko, tu ne peux pas le copier.
Le plus simple, c'est d'avoir des objets immuables. Ainsi, tu n'as aucune différence sémantique entre balader un pointeur et l'objet lui-même puisque personne ne peut le modifier, par contre, sa durée de vie n'est plus sous contrôle et un GC est nécessaire. Ocaml fonctionne comme ça. Si il y a plein de string partout, cela va bien plus vite, par contre, si il y a plein de string à vie courte, la consommation mémoire s'envole, car il est impossible de réutiliser un buffer.
Le moment où tu n'as plus en tête tout le pipeline de traitement.
Ça, de toutes façons, même Rust n'y pourra pas grand chose.
Si justement, Rust te garanti d'avoir un seul propriétaire de la mémoire, tu ne peux pas avoir 2 pointeurs qui se baladent, c'est plus facile à suivre. C'est le principe de ce genre de contrainte, avoir une sémantique clair et simple.
Franchement, réutiliser des array de mémoire sans copie est un moyen de faire un code très rapide qui use peu de mémoire, mais c'est aussi le meilleur moyen de se tirer une balle dans le pied, car il peut devenir très compliquer de savoir quel traitement à déjà eu lieu et l'état réel du buffer.
Donc, que rust propose de vérifier des propriétés qui te garantissent que tu ne fais pas de la merde, c'est pas mal. Regardes les perfs qu'il obtient à la fin, et surtout la consommation mémoire.
"4.5*.93 = 4.185+ε (avec ε positif), en arrondi bancaire 4.19"
Le truc c'est le ε qui traine, qui fait une bascule. Mais même un décimal ne peut pas stocker tous les nombre de façon exact (1/3,1/7, sqrt(2), e, Pi…), pour toi, il n'existe pas de cas pathologique similaire ?
Tu as toujours le ((a-1)*n) + (a * n) = n, pour n dans [0;1] ? Et c'est vrai aussi pour plus de 2 termes ? avec du calcul décimal.
Oui, c'est très connu comme papier. Et une source infini de problème provient du fait que les optimiseurs de certain compilateur prennent les flottants pour des réels.
"Si on a du float ou double pour du monétaire, la réponse est clairement "non". "
Je répondais à cette phrase-ci.
"Et ce nonobstant toutes les explications qu'on t'a données. C'est un peu dommage."
J'ai quand même appris plein de truc. Mais je trouve qu'il n'y a pas d'exemple d'horror story et beaucoup de "on dit".
J'ai appris l'existence de l'arrondis bancaire, ainsi que les règles d'arrondis pour la TVA. Cela peut se faire avec n'importe quel type. Je me suis rendu compte que le type DECIMAL qui code exactement certain nombre décimal évite le problème de l'accumulation d'erreur d'un nombre flottant, mais c'est valide pour la somme d'un très grand nombre de ligne. Cela peut aussi se faire avec un simple entier qui représente des centimes. Les IO d'argent se font uniquement en centimes.
C'est déjà pas mal !
La où on ne m'a pas convaincu, c'est l'obligation d'utiliser un type DECIMAL dans mes calculs internes comme le propose certain langage.
Je suis désolé, car c'est faux. J'ai un cas qui a besoin d'une division, le type monétaire ne contient pas assez de décimal pour ne pas faire d'erreur grossière au final. Ce que tu dis n'est vrai que pour des transferts ou la valeur de compte courant. Bref, pour les IO mais surtout pas pour des calculs internes.
Pour faire le teste, il faudrait générer quelques millions de nombre et faire la somme, et recommencer avec des nombres arrondis et estimer l'erreur final. Le "round to even" devrait avoir une erreur plus faible.
Si tu manipules une masse de truc tu finis souvent par faire des tables temporaires pour continuer des calculs. J'ai l'impression que c'est fini le fait de ne stocker que les données "raw", des étapes intermédiaires peuvent être stocker aussi.
Maintenant, si tu additionnes 2 millions de nombres avec chacun ce type d'erreur, les erreurs s'additionnent, et le résultat pourra être faux de manière imprévisible, même si on ne fait aucun arrondi intermédiaire.
Pas de manière imprévisible, cela peut tout à fait se calculer. si tu n'as que des additions, tu as n opérations, donc n * l'erreur au maximum erreur de 10-7 ou 10-16 (float32 ou float64). Avec des montants inférieur au milliard d'euro, tu peux faire quelques milliers d'addition en float64 avant d'avoir un soucis. Avec 2 millions d'addition, tu ne pourra pas en effet.
Avec du décimal, on additionnerait des valeurs exactes, et le résultat serait donc exact.
Oui dans le cas simple d'addition sans arrondi ni overflow.
Je viens de penser à un truc, si tu factures avec la méthode 2 qui calcul avec arrondi chaque ligne pour avoir des sommes de TVA facile à avoir, il est possible d'avoir de la TVA à zéro avec des toutes petites sommes facturées ?!
Genre tu factures une ligne 0.20€ ttc tu as 0.2*.02 = 0.004 € de TVA qui s'arrondissent à 0 ?
[^] # Re: HS math : polynômes de complexe
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Frido : un livre, libre, de mathématiques pour l’agrégation. Évalué à 3.
Je vais regarder tout ça. amusant l'histoire du cercle, je trouvais que c'était un "patch", plus intéressant, que les blocks de jpeg.
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 3.
J'étais resté sur un tas mineur de 256 Ko, cela a du changé.
C'était ce code : https://github.com/nicolasboulay/index2share (joli flop, avec une interface incompréhensible pour le commun des mortels, alors qu'il n'y a aucune option)
buffer n'offre pas la même api que string pour les conversions.
"La première sécurité est la liberté"
[^] # Re: HS math : polynômes de complexe
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Frido : un livre, libre, de mathématiques pour l’agrégation. Évalué à 4.
Je voulais voir si on pouvait remplacer l'iDCT typique des compressions par une approximation polynomiale qui permet entre autre de faire des opérations directement sur les coefficient, ce qui me semble impossible avec une image sous forme d'IDCT (mais je me trompe peut-être). Est-ce qu'une image pourrait être considéré comme une fonction holomorphe d'un plan ?
Je parlais de coef complexe mais aussi de "résultat" complexe ou en quaternion, si on prend une image comme une fonction de x,y et qui rend un triplet RGB (ou autre). donc f(x,y) -> (r,g,b) que l'on pourrait traduire en (f(x,y,z,t) -> (r,g,b,0) pour utiliser des quaternions, ou encore f(x,y) -> (Y) dans le cas noir et blanc, plus simple.
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 4.
Disons que j'ai un cas en tête qui doit tomber pile poile dans le cas pathologique. Il s'agissait de parser des fichiers de petites tailles. En C, j'aurais simplement utiliser un char[] de taille "suffisante", en ocaml, buffer ne propose pas les même fonction de parse que string, la conversion est donc obligatoire.
Donc, chaque fichier utilise une string de qq ko. J'imagine que vu la taille, elle n'est pas alloué dans le tas mineur mais directement dans le tas majeur. Donc, si tu parses 10 000 fichiers, la limitation sera le GC. En jouant sur les options, j'ai gagné 15% de perf, en utilisant beaucoup plus de mémoire. J'imagine que l'idéal serait un allocateur qui recycle les vieux objets de grandes tailles, cela évite de réallouer la mémoire.
Ce cas était tellement énervant, car en C ou C++, il n'y aurait eu aucune allocation pendant la durée de la boucle. Et au final, le temps était passé dans la gestion mémoire.
"La première sécurité est la liberté"
# HS math : polynômes de complexe
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Frido : un livre, libre, de mathématiques pour l’agrégation. Évalué à 4.
Je tient un prof de math, je pose ma question : est-ce que les polynômes de complexe ou de quaternion existent et ont les mêmes propriétés que les polynômes avec des réels ?
J'ai l'impression que cette branche des mathématiques a un peu laissé la place aux matrices, mais les cours parlent beaucoup des polynômes. De plus les opérations sur les matrices sont un peu moins "souple".
Je voulais m'amuser avec les approximations polynomiales sur des images, avec un polynôme classique, on ne peut faire qu'une "couleur" sur une ligne (une courbe quoi). Avec un complexe, on pourrait faire une image avec une couleur, etc…
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 4.
Entièrement d'accord, mais si ton object fait 100ko, tu ne peux pas le copier.
Le plus simple, c'est d'avoir des objets immuables. Ainsi, tu n'as aucune différence sémantique entre balader un pointeur et l'objet lui-même puisque personne ne peut le modifier, par contre, sa durée de vie n'est plus sous contrôle et un GC est nécessaire. Ocaml fonctionne comme ça. Si il y a plein de string partout, cela va bien plus vite, par contre, si il y a plein de string à vie courte, la consommation mémoire s'envole, car il est impossible de réutiliser un buffer.
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 7.
Le moment où tu n'as plus en tête tout le pipeline de traitement.
Si justement, Rust te garanti d'avoir un seul propriétaire de la mémoire, tu ne peux pas avoir 2 pointeurs qui se baladent, c'est plus facile à suivre. C'est le principe de ce genre de contrainte, avoir une sémantique clair et simple.
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 3.
Au début seulement, si le code ne devient pas gros, et si personne n'a corrigé de bug avec un emplâtre mal placé.
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 6.
Franchement, réutiliser des array de mémoire sans copie est un moyen de faire un code très rapide qui use peu de mémoire, mais c'est aussi le meilleur moyen de se tirer une balle dans le pied, car il peut devenir très compliquer de savoir quel traitement à déjà eu lieu et l'état réel du buffer.
Donc, que rust propose de vérifier des propriétés qui te garantissent que tu ne fais pas de la merde, c'est pas mal. Regardes les perfs qu'il obtient à la fin, et surtout la consommation mémoire.
"La première sécurité est la liberté"
[^] # Re: On en est arrivé là comment ?!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche devops REX - publication du programme du 2 octobre 2017. Évalué à 3.
Etre un gros lourd, un peu con, n'est pas encore illégal, d’où le rajout de règle, j'imagine.
"La première sécurité est la liberté"
[^] # Re: lieu
Posté par Nicolas Boulay (site web personnel) . En réponse au journal C'est la rentrée, un timing parfait pour un meetup Open Hardware sur Paris @Criteo . Évalué à 4.
Au début de la rue, il y a la bonbonnière de la trinité, je recommande très chaudement : un des meilleurs chocolatiers de Paris.
"La première sécurité est la liberté"
[^] # Re: nan, c'est pas un problème d'arrondi qui te guette
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Tu parles de ça : https://linuxfr.org/users/niconico/journaux/sql-decimal-vs-double#comment-1713014 ?
J'ai du le louper.
Le truc c'est le ε qui traine, qui fait une bascule. Mais même un décimal ne peut pas stocker tous les nombre de façon exact (1/3,1/7, sqrt(2), e, Pi…), pour toi, il n'existe pas de cas pathologique similaire ?
Tu as toujours le ((a-1)*n) + (a * n) = n, pour n dans [0;1] ? Et c'est vrai aussi pour plus de 2 termes ? avec du calcul décimal.
"La première sécurité est la liberté"
[^] # Re: Pour info
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3. Dernière modification le 13 septembre 2017 à 17:11.
Oui, c'est très connu comme papier. Et une source infini de problème provient du fait que les optimiseurs de certain compilateur prennent les flottants pour des réels.
"La première sécurité est la liberté"
[^] # Re: nan, c'est pas un problème d'arrondi qui te guette
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 4.
Je répondais à cette phrase-ci.
J'ai quand même appris plein de truc. Mais je trouve qu'il n'y a pas d'exemple d'horror story et beaucoup de "on dit".
J'ai appris l'existence de l'arrondis bancaire, ainsi que les règles d'arrondis pour la TVA. Cela peut se faire avec n'importe quel type. Je me suis rendu compte que le type DECIMAL qui code exactement certain nombre décimal évite le problème de l'accumulation d'erreur d'un nombre flottant, mais c'est valide pour la somme d'un très grand nombre de ligne. Cela peut aussi se faire avec un simple entier qui représente des centimes. Les IO d'argent se font uniquement en centimes.
C'est déjà pas mal !
La où on ne m'a pas convaincu, c'est l'obligation d'utiliser un type DECIMAL dans mes calculs internes comme le propose certain langage.
"La première sécurité est la liberté"
[^] # Re: nan, c'est pas un problème d'arrondi qui te guette
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 0.
Je suis désolé, car c'est faux. J'ai un cas qui a besoin d'une division, le type monétaire ne contient pas assez de décimal pour ne pas faire d'erreur grossière au final. Ce que tu dis n'est vrai que pour des transferts ou la valeur de compte courant. Bref, pour les IO mais surtout pas pour des calculs internes.
"La première sécurité est la liberté"
[^] # Re: Exemple simple
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
Il y a moins d'erreur à la fin.
Pour faire le teste, il faudrait générer quelques millions de nombre et faire la somme, et recommencer avec des nombres arrondis et estimer l'erreur final. Le "round to even" devrait avoir une erreur plus faible.
"La première sécurité est la liberté"
[^] # Re: Un retour d'expérience
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
Si tu manipules une masse de truc tu finis souvent par faire des tables temporaires pour continuer des calculs. J'ai l'impression que c'est fini le fait de ne stocker que les données "raw", des étapes intermédiaires peuvent être stocker aussi.
"La première sécurité est la liberté"
[^] # Re: "double" et "long double"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
La dernière version du IEE754 ajoute un type décimal (BCD ?) qui doit être supporté dans les dernières versions de GCC.
"La première sécurité est la liberté"
[^] # Re: Le point clef est le calcul scientifique, pas la finance
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Le DECIMAL en sql, est plus une virgule fixe. Même si des implémentations particulières peuvent avoir des tailles variables.
"La première sécurité est la liberté"
[^] # Re: Exemple simple
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
En quoi cet arrondis n'est pas classique ? C'est le mode par défaut des fpu.
"La première sécurité est la liberté"
[^] # Re: "10.222" n'existe pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 4.
Je me doutais un peu.
"La première sécurité est la liberté"
[^] # Re: Monnaie = danger
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Oui, il faut faire attention aussi que le langage hôte ne fasse pas de conversion en double sans prévenir.
"La première sécurité est la liberté"
[^] # Re: nan, c'est pas un problème d'arrondi qui te guette
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Pas de manière imprévisible, cela peut tout à fait se calculer. si tu n'as que des additions, tu as n opérations, donc n * l'erreur au maximum erreur de 10-7 ou 10-16 (float32 ou float64). Avec des montants inférieur au milliard d'euro, tu peux faire quelques milliers d'addition en float64 avant d'avoir un soucis. Avec 2 millions d'addition, tu ne pourra pas en effet.
Oui dans le cas simple d'addition sans arrondi ni overflow.
"La première sécurité est la liberté"
[^] # Re: nan, c'est pas un problème d'arrondi qui te guette
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Mais cela n'a pas d'importance !
si float x = 30.14
Cela veut dire que 30.14+10-7>= x >= 30.14-10-7 (en gros)
donc "30.139999" arrondit à 6 chiffres donnent bien 30.14.
"La première sécurité est la liberté"
[^] # Re: "10.222" n'existe pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Je viens de penser à un truc, si tu factures avec la méthode 2 qui calcul avec arrondi chaque ligne pour avoir des sommes de TVA facile à avoir, il est possible d'avoir de la TVA à zéro avec des toutes petites sommes facturées ?!
Genre tu factures une ligne 0.20€ ttc tu as 0.2*.02 = 0.004 € de TVA qui s'arrondissent à 0 ?
"La première sécurité est la liberté"