Le topic de la programmation: Et envoyez des sioux!

[Whiskey]

Ola

Petite question en passant, en Python (dernière version stable), quand je lance la console (REPL) et que je tape :

>>> 1.1 * 3

il me sort : 3.3000000000000003 au lieu de 3.3.

Pour un langage soi disant réputé dans le domaine scientifique ca fait peur. Est ce normal ?

[Orhin]

C'est pas spécifique à un langage ça.
La multiplication de float est par nature imprécise et peut donner ce genre de résultat.

Le problème avec Python (ou Javascript) c'est que le type de nombre utilisé n'est pas explicite.

[Whiskey]

je vois, merci

[Garrluk]

Oui c'est normal, tu auras le même comportement dans tous les langages, c'est lié à la façon dont les nombres à virgules sont stockés (on appelle ça des nombres à virgule flottante, ou floating point number en anglais).
C'est le même principe que l'écriture scientifique dont tu as peut-être déjà entendu parler en physique au lycée : au lieu d'écrire 0,5 on écrit 5*10^-1.
Si tu veux comprendre comment ça marche tu peux commencer par lire la page wikipédia de la norme IEEE754.
J'aime bien cette page aussi qui donne une bonne idée de comment les nombres sont représentés : https://www.h-schmidt.net/FloatConverter/IEEE754.html

[TarteAuxFleurs]

Tu as un module Python pour avoir une précision fixe (donc potentiellement plus précise que du IEEE754) sur le calcul flottant : https://docs.python.org/3/library/decimal.html

[Whiskey]

Oui c'est normal, tu auras le même comportement dans tous les langages, c'est lié à la façon dont les nombres à virgules sont stockés (on appelle ça des nombres à virgule flottante, ou floating point number en anglais).
C'est le même principe que l'écriture scientifique dont tu as peut-être déjà entendu parler en physique au lycée : au lieu d'écrire 0,5 on écrit 5*10^-1.
Si tu veux comprendre comment ça marche tu peux commencer par lire la page wikipédia de la norme IEEE754.
J'aime bien cette page aussi qui donne une bonne idée de comment les nombres sont représentés : https://www.h-schmidt.net/FloatConverter/IEEE754.html

Tu as un module Python pour avoir une précision fixe (donc potentiellement plus précise que du IEEE754) sur le calcul flottant : https://docs.python.org/3/library/decimal.html

Intéressant, merci pour vos réponses.

[Orhin]

D'ailleurs c'est un problème récurent quand on ne fait pas gaffe, j'ai eu un "4.004 * 1000 = 4003.999..." la semaine dernière en Javascript.

[Whiskey]

Peut etre rien a voir mais perso ca ma tout de suite fait penser au feu processeur Cyrix ^^ (oui suis vieux )

[Kamasa]

D'ailleurs c'est un problème récurent quand on ne fait pas gaffe, j'ai eu un "4.004 * 1000 = 4003.999..." la semaine dernière en Javascript.

Bah faut juste penser à arrondir le résultat après, une broutille

[gros_bidule]

En monétique on utilise au maximum des entiers (donc travailler en centimes/cents, ce genre de chose). Une valeur c'est comme un oeuf, si ça flotte c'est généralement source de problèmes
Mais je pleins les domaines où tu n'as pas (sinon moins) le choix.

[Cwningen]

Ola

Petite question en passant, en Python (dernière version stable), quand je lance la console (REPL) et que je tape :

>>> 1.1 * 3

il me sort : 3.3000000000000003 au lieu de 3.3.

Pour un langage soi disant réputé dans le domaine scientifique ca fait peur. Est ce normal ?

En binaire à virgule 1/5 (ou plutôt 1/101) a une écriture infinie : 0,0011 (la partie soulignée est répétée à l'infini). Comme le stockage se fait avec une mantisse fini, on se retrouve avec une valeur approchée. Quand on part d'une écriture décimal, on se retrouve souvent avec ce genre nombre infini lors de la conversion.

[chouetteunhibou]

Peut etre rien a voir mais perso ca ma tout de suite fait penser au feu processeur Cyrix ^^ (oui suis vieux )

ce n'était pas, plutôt, au bug des premiers Pentium ?
https://fr.wikipedia.org/wiki/Bug_de...ion_du_Pentium

[Whiskey]

ce n'était pas, plutôt, au bug des premiers Pentium ?
https://fr.wikipedia.org/wiki/Bug_de...ion_du_Pentium

J'ai du confondre

[Foksadure]

J'ai du confondre

Sans doute parce que le Cyrix i686 avait aussi son bug :

https://en.wikipedia.org/wiki/Cyrix_coma_bug

[Lazyjoe]

En monétique on utilise au maximum des entiers (donc travailler en centimes/cents, ce genre de chose). Une valeur c'est comme un oeuf, si ça flotte c'est généralement source de problèmes
Mais je pleins les domaines où tu n'as pas (sinon moins) le choix.

DeepLearning : "8 bits c'est bien assez pour un float"

[Awake]

Salut,

Petite question algorithmique, sur le problème suivant :

Write a function, uncompress, that takes in a string as an argument. The input string will be formatted into multiple groups according to the following pattern:

<number><char>

for example, '2c' or '3a'.

The function should return an uncompressed version of the string where each 'char' of a group is repeated 'number' times consecutively. You may assume that the input string is well-formed according to the previously mentioned pattern.

uncompress("2c3a1t"); // -> 'ccaaat'

uncompress("3n12e2z"); // -> 'nnneeeeeeeeeeeezz'

J'ai codé ça (c'est du js mais ne prenez pas peur)

const uncompress = (s) => {
  let mul = "";
  let result = "";
  
  for(const i in s) {
    if (/^\d+$/.test(s[i])) {
      mul += s[i];
      continue;
    }

    result += s[i].repeat(mul);
    mul = "";
  }

  return result;
};

Ça passe tous les tests et me valide le problème.

Mais à ma surprise la solution au problème était :

const uncompress = (s) => {
  let result = [];
  const numbers = '0123456789';
  let i = 0;
  let j = 0;
  while (j < s.length) {
    if (numbers.includes(s[j])) {
      j += 1;
    } else {
      const num = Number(s.slice(i, j));
      for (let count = 0; count < num; count += 1) {
        result.push(s[j]);
      }
      j += 1;
      i = j;
    }
  }
  return result.join('');
};

Je comprend pourquoi il n'utilise pas repeat, c'est pour que la complexité O(xy) soit plus évidente, mais pourquoi utiliser deux pointeurs ? Pourquoi utiliser un array pour stocker la valeur de retour ?
C'est moi ou ma solution est plus élégante ?

[Dross]

Pour moi ça me semble globalement équivalent.

A la différence qu'en terme de perfs (mais bon, à mon avis ça n'aura pas d'intérêt ici), faire plusieurs concaténations de strings et l'utilisation d'une regex pourrai être moins performant. Une regex est aussi moins lisible (pour du code facile à gérer pour un junior par exemple).

Mais c'est du pinaillage arrivé là à mon avis.

[Orhin]

La solution "officielle" me semble surtout écrire par quelqu'un qui fait du Go (ou autre langage bas niveau).

Niveau perfs, le include sera mieux que la regex.
Par contre, ce n'est pas le cas avec le tableau + join (en plus d'être franchement pas lisible).
Après, si tu veux vraiment vérifier ça, ça se bench.

Perso en solution la plus élégante, j'aurais plutôt vu un truc du genre (écrit sur mon tél donc y'a sûrement des fautes) :

function uncompress(s: string): string {
  let result = ""

  const groups = string.match(/(\d+[a-z])/)

  for (const group of groups) {
    const size = parseInt(group.slice(0, -1))
    const letter = group.slice(-1)

    result.padEnd(result.length + size, letter)
  }

}

[Garrluk]

C'est un type de compression assez commun qu'on appel RLE et en pratique ce ne serait pas compressé comme ça si on voulait des perfs (ce qui est la principale raison d'utiliser de la compression RLE en fait).
A priori le mieux dans ce cas ce serai d'avoir 2 tableaux : 1 tableau d'int avec les valeur de répétition et 1 de char avec les caractères à répéter, ça éviterai d'avoir à gérer la conversion int->string/string->int qui va sûrement être le truc qui bouffe le plus de perf à la compression comme à la décompression.
Ça peut être une bonne idée de transmettre aussi la taille du tableau décompressé en préambule pour pouvoir ne faire qu'une seule allocation au début de la décompression plutôt que plusieurs réallocations au fur et à mesure que le tableau grandit.
Donc utiliser une structure qui ressemblerait à :

{6,{c,a,t},{2,3,1}} // -> ccaaat
{17,{n,e,z},{3,12,2}} // -> nnneeeeeeeeeeeezz

Mais du coup ça devient trivial à décompresser et ça ne fait plus un exercice de code très intéressant .

[Awake]

@Dross : c'est équivalent mais ma solution est plus simple à lire, à complexité égale, non ?

@Orhin : ta solution full regex est top mais c'est un cours d'algorithmique, je pense que ce n'est pas ce qu'ils cherchent.

@Garrluk : intéressant merci, je ne pensais pas que ce genre d'algo hyper basique pouvait réellement être utilisé en compression

[war-p]

La compilation de la regex à chaque tour de boucle :fear:
Sinon, en complément d'info, effectivement ça ressemble au rle.

[Cwningen]

C'était très efficace pour les bitmaps avec peu de couleurs et des gros aplats (pas de dithering). Mais ça a vite été dépassé.

[Garrluk]

Pour le stockage d'images ce n'est effectivement plus très utile, pour faire du transfert de données par contre c'est toujours utilisé. Justement grace à la rapidité de compression/décompression, qui fait que c'est presque gratuit.

[Cwningen]

Quel genre de transfert ? Le type de données sur lequel RLE est efficace est très réduit. Sur le reste il augmente beaucoup trop souvent la taille.

[Awake]

La compilation de la regex à chaque tour de boucle :fear:

Juste là dessus : les interpreteurs/compilateurs ne sont pas capables de s'en rendre compte et d'optimiser ça eux même de nos jours ?

[Helix]

Pour le stockage d'images ce n'est effectivement plus très utile, pour faire du transfert de données par contre c'est toujours utilisé. Justement grace à la rapidité de compression/décompression, qui fait que c'est presque gratuit.

Le RLE est un des éléments de la dernière étape du codage JPEG, encore pas mal utilisé.

[Garrluk]

Quel genre de transfert ? Le type de données sur lequel RLE est efficace est très réduit. Sur le reste il augmente beaucoup trop souvent la taille.

Je l'ai utilisé une fois pour des images de HUD d'un casque de réalité augmentée, donc des images très simples principalement vides, qu'on avait besoin de compresser pour des histoires de débits.
Et une fois sur des données volumétriques qui provenaient d'un appareil médical (scanner ou IRM?) pour faire le transfert entre mémoire CPU et VRAM pour l'affichage. Ça ne compressait pas grand chose d'autre que le vide autour de la personne mais ça suffisait pour le besoin qu'on avait.

Mais tu as raison, ce n'est pas souvent utile non plus .

Le RLE est un des éléments de la dernière étape du codage JPEG, encore pas mal utilisé.

Merci, je ne savais pas .

[Orhin]

Juste là dessus : les interpreteurs/compilateurs ne sont pas capables de s'en rendre compte et d'optimiser ça eux même de nos jours ?

Si, et ce depuis un bail.

[Dross]

@Dross : c'est équivalent mais ma solution est plus simple à lire, à complexité égale, non ?

J'aurai tendance à préférer une solution sans régex si on va sur la lisibilité / accessibilité pour un junior.

Déjà car les régex c'est pas standard : une régex sous C# et sous Javascript ne sont pas forcément écrites de la même manière (bien qu'ayant un socle commun très grand) amenant un risque de mauvaise lecture (que tu n'aura pas avec des fonctions de base de type "include"), souvent on est obligé de rouvrir un tableau récapitulatif pour juste s'y replonger et la lire avec assurance, la complexité monte toujours très rapidement (typiquement quand tu l'écrit ça va, quand tu la relis dans 6 mois c'est l'horreur ; un bon code smell d'un code peu maintenable), et enfin utiliser des regex simples (donc lisibles) pour des cas simples... peuvent amener des problèmes de perfs pour un avantage discutable. Souvent les perfs ça ne sera pas un problème, mais j'ai déjà connu dans le passé des UI de SPA qui traînaient la patte à cause d'un usage important de regex, ce qui est un peu dommage.

Ça se vois d'ailleurs de la manière dont ce sujet est porteur en terme de railleries :





Après les regex ont des usages totalement appropriés (quand t'a pas d'autres choix sans que ça devienne usine à gaz), mais perso je préfère les limiter à ces cas là, et en plus je les intègre jamais dans le code qui les utilises lui même (je les injectes et les testes en profondeur à part, documentant/testant tout les cas supportés pour aider mon futur moi qui me maudira sur un cas pas imaginé à l'époque).

[acdctabs]

Les regex c'est bien pour les formulaires. C'est tout