Reprise du message précédent :

800 iso  

http://www.latimes.com/business/au [...] story.html

 
Avec Snap camera tu peux monter plus haut mais c'est logiciel et non plus matériel. Faut quand même voir que ça reste un smartphone  
D'apres quasi tous les tests que j'ai pu lire le S6 est de qui se fait de mieux au niveau APN si on exclue certains modèles très spéciaux comme le Lumix.

il n'y a aucun intérêt à monter au delà de 800 ISO avec un capteur 1/2.6" aussi bon qu'il soit

Woot, iPhone 6s reçu ! 2 jours ouvrés c'est assez cool. Test ce week en je pense

Le truc à te dissuader d'aller voir le film.

Preums@work

 
Fallait essayer un G4... mais tu peux toujours retourner ton samsung  

 
Le G4 est bon aussi:
 

 
Oui, fallait essayer un G4

 
Sur les tests que j'ai pu lire, le G4 est un des meilleurs photophone du moment mais n'est pas meilleur que le S6 qui reste (pour le moment) la référence avec son capteur Sony (VS capteur LG). Ceci étant dit, il est très bon et dans certains domaines (vitesse par exemple) même meilleur que le S6. De plus, comme le S6, le format RAW est supporté et il a aussi un mode manuel complet comme le S6.
 
Bref, ce sont les meilleurs photophones pour le moment.

Je ne comprends pas l'engouement pour eora3D : https://www.kickstarter.com/project [...] ur-smartph
 
ça ne fait pas rêver :
(lien non disponible sur leur site hors mobile)  
https://sketchfab.com/models/5ea411 [...] 57003ba75e

Il n'y a que moi que cette page fait ramer comme jamais ? Je n'ai jamais vu Chrome répondre aussi lentement que sur cette page.
Les photos font 10Mo chacune ou quoi ?
edit: ils abusent des GIF

C'est un scanner 3D pour $200? Le prix d'entrée actuel semble être au moins le 2~2.5x pour moins de précision publiée.

https://www.youtube.com/watch?v=MNa [...] pp=desktop
 
Comment voler une voiture avec une balle de tennis.
Et c'est mon N+2 qui m'envoie ça  

 
ça marche parfaitement
 

Pas de pb pour moi avec Firefox sur un notebook plutôt moyen pourtant.

Youtube est bloqué au boulot, mais je suppose que c'est un type qui déverrouille la portière en tapant une balle de tennis contre la serrure. Ca marche parfaitement, en effet, sur certains modèles de voitures (rares maintenant ?) qui utilisent un système à air comprimé pour la centralisation. J'avais une seat cordoba de la fin des années 90 qui s'ouvrait très bien comme ça.

Oh merde, c'est aujourd'hui que Marty et Doc arrivent !

t'a 3 heures devant toi

Je viens de redécouvrir (tout seul comme un grand) les arbres binaires stockés dans des tableaux.

Si on encode chaque noeud de la façon suivante:
gauche = 1
droit = 0

Une valeur de 0 signifie l'absence de noeud.

On peut traverser l'arbre "breadth first" juste en traversant le tableau. La traversée sera normalement bcp plus rapide qu'avec des pointeurs vu qu'on traverse un tableau, donc on bénéficie des cache lines (surtout si on aligne la taille de la structure du noeud). Un facteur 100 ou plus est envisageable.

Idem pour de nombreuses insertions et suppressions car les noeuds sont préalloués (on fait un tradeoff vitesse-mémoire, comme d'habitude). Eventuellement, si l'arbre est très déséquilibré, on peut p-ê préallouer dynamiquement des sous-arbres de taille fixe (64 ou 128 noeuds par exemple) avec un pointeur vers le sous-arbre le cas échéant. A voir si ça n'engendre pas des opérations qui plomberaient le gain de performance de la structure. L'arbre de profondeur n a 2^n-1 noeuds.

Maintenant, j'essaye de trouver un encodage qui permet de faire la même chose pour une traversée "depth first".

edit: je crois que j'ai trouvé... une minute

Heu ton second arbre est pas la version la plus efficace... Renseigne toi sur les arbres binaires de recherche (binary search tree)
 
Normalement on essaye toujours de stocker ca comme ca:
Le nombre sur la gauche, est plus petit que le parent, le nombre sur la droite, est plus grand que le parent.
 
=> ca te donne une complexité O(log n) et jusqu'a O(n) dans le pire cas.
 
Ce sera infiniment plus efficace que des notions quasi-inutiles de "c'est stocké en ram au même endroit". Je veux bien que ce soit, parfois, intéressant, mais dans la large majorité des cas, avoir une complexité algorithmique bien foutue est bien plus avantageuse que ce genre de considération
 
https://fr.wikipedia.org/wiki/Arbre [...] _recherche

mais l'insertion à  un cout de log(n) (pour trouver la bonne feuille ) + le rééquilibrage ( qui est en temps constant si je mes souviens bien)

Et peut-être que ça n'a rien à voir avec ce qu'il cherche à faire?

much: Tu peux stocker la traversée inorder et pre-order dans deux tableaux.
Ça te permet de reconstruire l'arbre si besoin et ton DFS bah c'est juste la traversée pre-order en fait.
Après y a peut-être plus malin, c'est pas la recherche qui manque sur ce sujet...

Edit: mais si tu veux également faire beaucoup d'insertions et suppressions, là c'est la merde.

Ca n'est vrai que si le nombre de noeuds est très supérieur (disons d'un facteur 10) au facteur constant qui est invisible dans ta notation O.
Donc dans des arbres avec 1000 noeuds ou plus. Dans bcp d'applications, les arbres binaires sont relativement petits, et ça n'est plus vrai.

La rapidité des processeurs actuels est telle qu'il faut voir les accès aléatoires en RAM comme l'équivalent d'accès disque. Si tu trashes tes caches L2 et L1, tu te prends de grosses baisses de perfs dans la vue parce que l'accès en RAM prend 200 fois plus de cycles que l'accès en L1. La vision où seule la complexité algorithmique déterminait les perfs, c'était bon dans les années 80-90 quand le facteur constant était très faible (le plus souvent inférieur à 5). Depuis l'architecture Pentium et l'intégration de caches rapides au coeur de l'unité de traitement, cette vision est à revoir. Aujourd'hui, si tu veux exploiter tes coeurs à fond, il faut utiliser la stack au maximum et accéder à la RAM de façon séquentielle. D'où l'intérêt de la structure dont je parle.

J'ai pensé à stocker dans le noeud l'indice du noeud père. Ainsi on peut traverser l'arbre comme on le ferait avec des pointeurs et si on traverse l'arbre on ne trashe pas trop les caches.
Donc au lieu d'avoir 2 pointeurs, on a 2 int.

Les complexités sont identiques, car les algorithmes sont inchangés. C'est seulement la façon d'encoder l'arbre et le layout en mémoire qui changent.

Ouep, mais je sais de source sur (j'ai peut être travaillé pour facebook par exemple   dans lequel, on va pas se mentir, ya pas mal d'arbres justement), je connais en fin de compte très peu de cas ou tu as la nécessité de pusher comme un goret dans ton arbre... Même s'il est vrai qu'ils peuvent exister ces cas, comme partout, il y a de tout, partout
 

Je suis d'accord sur le fond, de toute façon c'est évident, maintenant je reste ultra mitigé dans les faits... Ca mériterai quelques articles/démo si tu as ca sur le coude. Disons au passage que la notation O est une notation globale, assez pratique, et la seule réellement enseignée et vue en France (d'ou mon utilisation ici), mais que, si tu veux, on peut commencer à parler de NSpace, DSpace, NTime, DTime, qui incluront largement tout ce dont tu es entrain de parler, mais en algorithmique, et je suis pas sur, vu les explications, que ton algo s'en sorte mieux   .
 
En l'état, pour moi, une "explication" comme ça ressemble beaucoup à cette pelletée de mec que j'ai pu voir -et que je vois encore-, qui t'expliquent que parce que le bit là il est au bon endroit, ça va être perf, et qui me sortent une complexité O(n²) au passage.
=> bien sur, loin de moi le fait que je te juge, vu que j'ai pas vu l'algo, et que je pars jamais avec un mauvais pressentiment, on est jamais à l'abri d'une surprise Je parle d'un cas général là exclusivement

Pour ce qui est de l'implémentation d'algos sur la stack, je faisais ça il y a plus de 10 ans parce qu'en embarqué temps réel c'est quelque chose de courant, voire obligatoire. Mais je suis sûr que c'est aussi comme ça que sont programmés pas mal d'applications musicales et de jeux vidéo.

Pour les considérations de cache, un pote de chez Thalès m'avait parlé de ça il y a bien 10-12 ans aussi. J'avoue qu'il m'a fallu plusieurs années pour intégrer ce qu'il m'avait raconté.
Sinon, ça fait quelques années que tous les grands pontes de C++ font régulièrement des conférences à ce sujet, ça n'a vraiment rien de nouveau. Ex Stroustrup en 2012. https://www.youtube.com/watch?v=YQs6IC-vgmo

Sinon, tu peux jeter un oeil à ceci:
http://baptiste-wicht.com/posts/20 [...] deque.html

Random Insert (+Linear Search): l'insertion est en O(n) à la fois pour la liste (parce qu'on traverse la liste jusqu'à l'emplacement d'insertion) et le vector (parce qu'il faut déplacer en mémoire tous les éléments derrière), et pourtant vector est gagnant pour les petites structures; c'est l'effet du cache. Lorsque la structure fait 4k, il y en a moins en cache et donc on n'en bénéficie plus, et list reprend le dessus du fait de sa complexité plus avantageuse. deque est essentiellement une liste doublement chaînée de plusieurs vector, c'est pour ça qu'il a de bonnes performances un peu partout.

Ces mesures ont été répliquées maintes fois.

C'est aussi bien connu des scientifiques qui font du calcul haute performance, ainsi que des fabricants de bases de données.
Le papier qui fait tjrs référence est celui d'Ulrich Drepper: https://people.freebsd.org/~lstewar [...] memory.pdf

Quoi qu'il en soit, je pense que je vais me coder ces structures d'arbre pour me faire mes propres mesures, mais je n'ai pas de doute sur le résultat.

je check

ROOOH putain !
 

#TaVieSexuelleEnFilm

Oui à part ça j'ai pas bien compris ce qu'on était sensé voir

darklord en plein écran sur le twitter de JetBrains.

 
OKLM  

Ah c'est darklord ?  
 
Wow  

Des fois qu'il lui resterait un semblant de crédibilité...

 
Il était à Devoxx 2015, Taiche m'a présenté
On a bouffé du brownie maison et tout.
Incroyab'

Un peu d'art dans un monde de brute: http://thecreatorsproject.vice.com [...] usic-video
 
On dirait Louis CK à 3:18

 
Lui aussi http://www.slate.com/blogs/the_sla [...] ately.html
 

https://twitter.com/EnglishRussia1/ [...] 6144075777