Posté par gUI (Mastodon) .
Évalué à 10.
Dernière modification le 20 juillet 2023 à 07:46.
C'est 15 lignes de python, mais qui utilisent une bibliothèque autrement plus grosse (Huffman). J'aurais plutôt dit "Algo des années 50 ≥ Google BERT".
Sinon c'est rigolo oui, et je me demande si du coup on ne va pas voir fleurir rapidement d'autres implémentation de Huffman plus rapides par exemple. En zippant on profitera de l’engouement de l'IA !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Des implémentations de Huffman, ça doit déjà être pas mal exploré comme sujet. Potentiellement avec les machines modernes, on peut gratter, mais bon, c’est déjà des algos utilisés à très grande échelle, y compris pour compresser les retours de serveurs web là ou potentiellement il y a beaucoup à gagner à optimiser aux ptits oignons donc je parierai qu’il y a plus grand chose à faire ?
Par contre peut-être que l’exploration d’algorithmes de compression un peu spécifiques pour faire ce genre de trucs ?
# Traduction de precision
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Il me semble que precision, dans le contexte de l’article, se traduise par fiabilité, ou fidélité dans la langue de La Fontaine ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Attention toutefois
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 20 juillet 2023 à 07:46.
C'est 15 lignes de python, mais qui utilisent une bibliothèque autrement plus grosse (Huffman). J'aurais plutôt dit "Algo des années 50 ≥ Google BERT".
Sinon c'est rigolo oui, et je me demande si du coup on ne va pas voir fleurir rapidement d'autres implémentation de Huffman plus rapides par exemple. En zippant on profitera de l’engouement de l'IA !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Attention toutefois
Posté par Thomas Douillard . Évalué à 5.
Des implémentations de Huffman, ça doit déjà être pas mal exploré comme sujet. Potentiellement avec les machines modernes, on peut gratter, mais bon, c’est déjà des algos utilisés à très grande échelle, y compris pour compresser les retours de serveurs web là ou potentiellement il y a beaucoup à gagner à optimiser aux ptits oignons donc je parierai qu’il y a plus grand chose à faire ?
Par contre peut-être que l’exploration d’algorithmes de compression un peu spécifiques pour faire ce genre de trucs ?
[^] # Re: Attention toutefois
Posté par barmic 🦦 . Évalué à 3.
Déjà bencher les actuels et leur paramètres pour améliorer le résultat.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Une précision (sans jeu de mot)
Posté par Misc (site web personnel) . Évalué à 8. Dernière modification le 20 juillet 2023 à 10:34.
Il semble que le papier de recherche ne soit pas correct:
https://kenschutte.com/gzip-knn-paper/
[^] # Re: Une précision (sans jeu de mot)
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
Il me semble que l’auteur du fil Twitter en parle justement. Du moins de ce que j’ai compris, avec proposition d’amélioration.
# voir aussi
Posté par steph1978 . Évalué à 3.
https://aclanthology.org/2023.findings-acl.426.pdf
https://github.com/Futrell/ziplm/
[^] # Re: voir aussi
Posté par steph1978 . Évalué à 2. Dernière modification le 21 juillet 2023 à 16:40.
Et https://www.uber.com/en-CH/blog/neural-networks-jpeg/ qui propose d'utiliser directement la sortie de l'encodeur DCT de JPEG comme entrée du réseau de neurones et ainsi d'en supprimer certaines couches et donc d'accélérer l’entraînement.
Bref, intéressant de voir les liens entre encodeur et ML.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.