RSS

Les ingénieurs d’Apple sont-ils doués?

Ils étaient tous choqués dans le métro quand j’ai jeté mon ipod touch sur les rails. Peu après, quand ils ont compris que j’étais un sexy coder (car ça se voit et j’avais le tee-shirt) ils ont aussi compris que mon geste était naturel. Ipod-touch était mal codé.

Chez Apple aussi, ils ont tout compris: pour faire un bon produit, il faut un bon designer, un bon spécialiste en ergonomie, pour le reste: il y a MasterCard (des clients).

Ca faisait 10 minutes que j’écoutais de la musique en mode shuffle (le mode qui permet d’écouter des chansons au hasard) lorsque je me suis rendu compte que c’est toujours les mêmes 16 chansons qui passaient en boucle sur les 1232 présentes. Pourtant le mode shuffle, c’est fait pour tomber au hasard sur plein de chansons! Alors où était le problème? Pour moi, tout était clair.

Imaginons que vous ayez une liste de 30 chansons. Comment coder un mode shuffle?

L’homme Delarue dira: “on balance un random à chaque fois qu’on doit passer à la chanson suivante.” C’est pas terrible. Car on peut retomber souvent sur la même. Un codeur naîf dira: “on construit une nouvelle liste en prenant une par une au hasard à partir de la liste de départ”. C’est mieux, mais c’est pas terrible niveau complexité: sur une grosse playlist, il faudra attendre beaucoup pour le traitement.

Pour faire efficacement un mode shuffle, vous choisissez un nombre (par exemple 7), et vous jouez la septième chanson. Puis la 14ième. Puis la 21ème. Puis la 28ème. Au délà de 30, puisqu’il n’y a que 30 chansons, vous faites modulo 30: en gros vous jouez la 6ème chanson, puis 13ème etc. Et comme ça, à chaque fois vous avez juste une addition et un modulo à faire et on a l’impression que c’est une playlist mélangée.

 

Et bien chez Apple ils ont fait ça. Ils ont été jusqu’à penser à tout ça (c’est pas des noobs non plus). MAIS. Il y a un “mais”. Pour que ça marche, il faut que le nombre de chansons au total (ici 30) et le pas (ici 7) soient premiers entre eux. Le jour où vous avez 70 chansons, le mode shuffle ne lancera que 10 chansons. Et c’est ce qui s’est passé sur mon Ipod touch qui a du finir écrabouillé à cause de ce moment d’inattention de la part des programmeurs.

 

Conclusion: quand on finit ses études en ignorant toujours la petite hypthèse qui fait marcher le théorème pour 100% des cas et pas juste la moitié, on finit par coder des ipod qui ont des shuffle merdiques et qui finissent écrasés par une rame de métro.


26 Comments Add Yours ↓

  1. me #
    1

    Pour clarifier:

    me: pfff
    tu crois franchement que c’est ca qu’ils ont fait?
    j’y crois pas une seconde
    Onur: lol
    non je pense pas qu’ils aient fait ça

  2. Jonas #
    2

    Merde je vais tester ça. Mais sur les ipod shuffle ça m’a l’air plus travaillé que cela. Il fait de stransitions en fonctions du BPM des deux chansons, pour ne pas perturber l’oreille (testé et restesté).

    Mais bon ça marche bien modulo la diffrence entre les styles de musique présent sur l’engin…

  3. Zorro #
    3

    C est un log, c est ca? Quelle mauvaise fois il a!

  4. xong #
    4

    très bon :)

  5. Kun #
    5

    Si j’avais un baladeur qui implémentait la méthode de shuffle conseillée dans ce post, je le balancerai sur les rails.

    Pourquoi ?
    Parce que dans la pratique, les musiques sont la plupart du temps triées par artistes, hors, avec cette méthode, plusieurs musiques du même artiste vont être jouée à la suite, puis l’artiste suivant dans l’ordre alphabétique, etc…

    Donc, trois problèmes :
    - Si on commence toujours l’écoute vers le même endroit, la liste des artistes est la même,
    - Si on commence du début, nous n’entendrons que très rarement les artistes avec un nom en ‘z’ dans le cas de grande liste,
    - Si on commence toujours avec la même chanson, la liste pourtant en shuffle, sera toujours la même.

    Donc, c’est bien de voir proposer une alternative à un système faillible, mais ce serait mieux si l’alternative n’avait pas autant de lacunes :)

  6. MGK #
    6

    @Kun : suffit seulement de prendre la liste de départ dans un ordre différent … et toutes la liste de lacunes que tu as cités se trouve à la poubelle.

    Un coup par ordre alphabétique du titre, un coup ordre inversé, un coup trié par artiste, un coup par compositeurs, un coup par genre, un coup par nombre d’écoute, un coup par système de notation, un coup par durée, un coup par album etc… sans compter si tu ajoutes à chaque fois le tri inverse ou bien si tu t’amuses aussi à ensuite couper la liste en deux et prendre la seconde moitié.

    tu fais ça AVANT de choisir un nombre et c’est réglé…

    et puis pour info, si tu commences par un même artiste comme tu as dis, rien ne dit que le nombre choisi sera toujours le même, donc pas de similarité dans la playlist vu que tout est décalé !

    et pour finir, ta liste de 3 problèmes : deux sont identiques.

    donc c’est bien de critiquer une bonne alternative, mais ce serait mieux si cette critique en vallait la peine :D

  7. 7

    Excellent.
    C’est effectivement impardonnable de créer un objet qui se veut parfait et d’oublier les math de base.

    J’ai aussi écrit un article sur l’iphone il y a quelques temps “iPhone, quand tu nous tiens!”

    http://www.facile.ch/Article.aspx?Article=Iphone

  8. Fabien #
    8

    Pourquoi tu nous embête? Tu as qu’a rajouter une chanson et puis c’est reglé

  9. reyam89 #
    9

    Moyennement rigoureuse ta démonstration.

    Pourquoi le pas et le nombre total de musique doivent être premier ?

    Ca peut faire un TD maple sympa.

  10. 10

    Playlist en lecture seule ?
    Shuffle sur les morceaux préférés/plus écoutés ?

    Parfois faut mieux formater le machin quand on passe d’une mise à jour à l’autre… Les bug due aux changement de version c’est dur à tracker (parce qu’il faut un document de la version d’avant sur un logiciel de la nouvelle version)

    (désolé moi j’adore débuguer… j’ai pas pu me retenir de poster :p)

  11. Kun #
    11

    @MGK:
    `MGK`=”suffit seulement de prendre la liste de départ dans un ordre différent … et toutes la liste de lacunes que tu as cités se trouve à la poubelle.”
    Selon l’ordre que tu choisi, certains problèmes persistes. De plus, j’espère que ta proposition est de faire une tri “logiciel”, car je ne me vois pas m’amuser à trier ma liste à chaque fois dans un ordre différent avant de la jouer.
    Car :
    - je veux que ma liste soit classée par artiste pour m’y retrouver plus facilement ;
    - comme indiqué dans le post, un tri sur une grosse liste prendra du temps, donc ça rajoute un problème. (que le post dit vouloir régler…)

    `MGK`=”[...]”

    Tri qui prennent du temps, et qui ne règle pas totalement le problème : la lecture de la liste se faire de façon incrémentielle (répétée & décalée), ce qui met à l’écart des musiques selon leurs noms/genre/etc …
    Ex : un artiste en ‘M’ qui n’a que des chansons en ‘M’ ne sera que rarement joué avec cette méthode (sauf dans le cas du classement par “les moins écoutés”, du coup).

    `MGK`=”tu fais ça AVANT de choisir un nombre et c’est réglé…”

    “Je” en tant qu’utilisateur, ou que développeur ?
    Si c’est en tant qu’utilisateur, je ne pense pas qu’il soit convenable de laisser à l’utilisateur la peine de faire des traitements qui devraient être automatisés côté logiciel.

    et puis pour info, si tu commences par un même artiste comme tu as dis, rien ne dit que le nombre choisi sera toujours le même, donc pas de similarité dans la playlist vu que tout est décalé !

    `MGK`=”et pour finir, ta liste de 3 problèmes : deux sont identiques.”
    Non, il s’agit bien de trois problèmes différents, je te conseil de les relire en essayant d’en saisir les nuances.
    Cependant, plusieurs de ces problèmes peuvent en effet être réglé de la même façon.

    `MGK`=”donc c’est bien de critiquer une bonne alternative, mais ce serait mieux si cette critique en vallait la peine :D
    Je pense qu’à partir du moment où une critique met en avant au moins un problème de conception, elle en vaut la peine.
    Ensuite, effectivement, si on rajoute un tas de surcouches à la méthode proposée, elle peut devenir concevable, mais dans ce cas :
    - ça la complexifie ;
    - autant préciser tous les aspects de la solutions, plutôt qu’une toute petite partie. Surtout quand se vante (via le sous-entendu) que contrairement aux autres, “on” (les auteurs du billet) pense à toutes les hypothèses, ce qui fait marcher le théorème pour 100% des cas.

    Cordialement.

  12. fif #
    12

    30 est un nombre premier ? C’est nouveau ! c’est divisible par 2, 3 , etc…..
    c’est pas un nombre premier. 29 c’est mieux !(et juste)

  13. vangelis #
    13

    @fif : premiers ENTRE EUX != premier

  14. Joe #
    14

    Fif> Relis mieux, il a dis que 30 et 7 étaient premiers ENTRE EUX. Et non que 30 était un nombre premier.

  15. LLB #
    15

    MGK : si on doit faire un tri avant, c’est débile. Un tri a généralement une complexité de O(n log n). Faire un mélange d’une collection est en O(n). En bonus, un mélange de tableau garantit que chaque combinaison est équiprobable.

    A moins d’avoir un processeur de 1950 et une million de titres, c’est largement assez rapide. :)

  16. xyz #
    16

    t’as plus qu’as te jeter sous les rails le jours ou tu pond un code de merde…

  17. sunny75 #
    17

    je n’y crois pas une seconde, très mauvaise démonstration d’ailleurs.

    essaye de trouver un peu mieux comme articles …

    sunny

  18. ShamoX #
    18

    Et si le pas est beaucoup plus grand que le nombre d’éléments de la liste et pris au hasard… Alors 2 choses :
    1) Le premier élément est bien toujours différent
    2) Le risque de bug présenté dans ce mail est toujours présent, mais ne se présente pas 2 fois de suite (et a une probabilité d’arriver de plus en plus faible au fur et à mesure que le nombre d’éléments de la liste augmente).
    3) C’est super simple à coder :
    L : liste des éléments
    p : le pas
    p = rand()
    élément_suivant(précédent) :
    retourne : (précédent + p) % taille(L)
    élément_suivant(p)
    … Vite fait comme ça, il me semble :
    1) que la complexité est en O(1) (constant) (suffit de maintenir la taille de la liste (ce qui est le cas dans iTunes))
    2) que le bug déclaré par ce poste peut arriver
    3) ça expliquerait qu’ils ne l’aient jamais observé puisqu’il faut que : p ne soit pas premier avec taille(L)… hors p est pris au hasard…
    4) aucune des lacunes citées ne sont présentes puisque le pas n’est pas une valeur constante mais le paramètre variable.

    Enfin, je suis du genre à trouver des fausses solutions très vite… C’est certainement le cas ici encore :)

    ShamoX

  19. DrGkill #
    19

    La démo on s’en tape, aucun shuffle digne de ce nom n’existe. Je pense que c’est parce que le cerveau humain se souviens plus de certaines choses que d’autres.
    En gros si une zic dans ta playlist que tu peux pas saquer passe 2 fois, tu le note et ça te casse les couilles.
    Si une zic que tu aimes passe 2 fois ça te convient et tu n’en tiens pas rigueur.

    Donc du te défoule sur ton shuffle alors qu’il faudrait mieux t’en vouloir d’avoir mis dans ta playlist des zics qui te révulsent.
    Il faut aussi t’en vouloir d’avoir des émotions et de changer d’état d’esprit.
    Ou alors… Tu fais des playlist qui correspondent à ton état d’esprit et t’as plus besoin du shuffle.

    Les mathématiques (et par conséquent l’algo) ne sont pas la solution à tout.
    Parfois, des solutions simple qui demandent de ne pas être trop fainéant sont suffisante.

  20. DrGkill #
    20

    A force d’être informaticien, on en oublie parfois d’être humain.

  21. 21

    DrGkill> Ou en tant que SexyCoder tu crées un algo qui va générer des playlists suivant ce que t’as envie d’entendre via tags Last.FM :) .
    Dès que PwnPlayer supportera les plugins je porterai ça sur iPod Touch (voir BMPx ou Amarok+scripts pour démo ;) )

  22. s0rc3r #
    22

    Je voudrais pas passer pour celui qui sait tout mais : Apple cay le mal

  23. 23

    ce qui est sur c’est qu’il pourrait pu un générateur aléatoire digne de ce nom (au moins Mersenne Twister)… en plus il suffit d’aller sur la page de M Matsumoto pour l’avoir :)

  24. Émeric #
    24

    “ça expliquerait qu’ils ne l’aient jamais observé puisqu’il faut que : p ne soit pas premier avec taille(L)… hors p est pris au hasard…”
    Ça ne dispense pas de devoir tester s’ils sont premiers entre eux. Un exemple trivial est si ta liste est de taille paire, et ton p est également pair. Tu n’accéderas qu’à la moitié de ta liste de lecture.

    Si tu veux vraiment te dispenser du test, tu choisis p au hasard dans une liste de nombres premiers. Bien entendu, tu ne t’assures pas une expérience utilisateur optimale, même si tu couvres toutes la liste. Si ton p = N*Taille(Liste) + 1 (pour un N quelconque), tu auras une lecture séquencielle des titres, même si p est beaucoup plus grand que Taille(Liste).

  25. Blackberry #
    25

    Ou pas…

    J’ai testé avec un bon paquet de musiques et ça marche très bien sur l’iTouch V2 tout comme sur l’iPod Classic

    ++

  26. 26

    ouais, je crois aussi qu’ils se basent sur les BPM mais aussi sur ce qu’on écoutte le plus souvent (: ils le repasse plus que le reste) :p


2 Trackbacks/Pingbacks

  1. Sexy Coders » La sortie sexy… codeur. 20 01 09
  2. weshCous1(Bien || Bien); /  Sexy Coders 16 02 10

Your Comment




Choux cailloux