Reprise du message précédent :

 
Ah bah voilà !
Donc c'est normal

C'est un tri casier quoi.  

 

 
noban pour le gif plz      
 
Sinon pour le CR en lui-même tu fais ce que tu veux hein

 
Bah ouais mais c'est la vie, j'ai eu ça tout cuit, j'ai pas eu de démarche à faire, c'est beaucoup plus croustillant quand c'est moi qui s'en charge !
Je suis tellement attaché à mon confort de n'avoir personne dans la vie , c'est ptet ça après tout
Pouvoir être indépendant, libre, ne pas s'engager
Mais de l'autre côté ça m'attire, et j'aimerais trouver quelqu'un pour partager des choses

 
 
Bah personnellement je suis un peu comme ça, j'ai aucune envie d'embrasser en général
 
Mais faut le faire parce que l'envie vient après/pendant ce moment

en fait j'ai trouvé une solution approximative avec un histogramme de résolution plus élevée (sachant que je n'ai pas le min-max mais une borne sup de max(max, -min) au départ), ça permet d'avoir une solution approximative qui correspond bien a mes besoins basiques .
 
Après je crois que c'est intéressant à creuser. Je ne crois pas que ce soit possible si les entrées ne sont pas bornées par quelque chose de connu par contre.
 

 
Je l'aurais volontiers massée, je préfère parce que c'est plutôt à sens unique, et que les compétences requises sont moins sévères que pour embrasser

ouais, c'est ce que je pensais

ben écoute si tu as mieux je suis tout ouïe. Je ne t'ai pas entendu sur le sujet, et ça n'a pas été suggéré sur stackoverflow.

oui, j'ai compris ton message à la 2e lecture après avoir posté

 
Reflexion (ou rotation?) de filles? Bon, je vais tâcher d'en parler avec Sorrento.

Je donnais juste le nom du tri que t'as décrit : http://fr.wikipedia.org/wiki/Tri_comptage

 
 
 
Des float.
Et la deuxième solution que tu proposes ne peut pas vraiment servir dans ce cas.
En fait, je cherche à faire un test de visibilité sur un scène 3D à partir d'un Z-buffer (avec des valeurs dans [0,1]). Je recalcule en gros la profondeur de certains points et je compare à ce qu'il y a dans le Z-buffer.
Malheureusement le calcul de profondeur ne donne pas exactement la même chose (aucune idée pourquoi, sûrement parce que les calculs matriciels ne sont pas fait de la même façon entre le Z-buffer et l'autre calcul de profondeur).
J'ai grosso modo des valeurs coïncidant sur les 6 premières décimales, mais divergentes après.
 
La question, c'est trouver quel ordre de grandeur est idéal pour discriminer si une profondeur est dans le Z-buffer.
Suffisamment petit pour discriminer tous les points que je teste (que je sais être tous différents, pas d’occurrences multiples), mais suffisamment grand pour que les erreurs de calculs n'impactent pas. Comme je sais pas vraiment d'ou viennent ces erreurs, je pensais qu'il valait mieux chercher la distance min entre deux points et prendre un ordre de grandeur en dessous pour tester si c'est le bon point ou pas.
 

 
C'est pas anormal.  
C'est juste que tu connais pas la meuf, qu'il te faut du temps pour avoir le feeling, toussa  
 
La même chose m'est déjà arrivée.
Fille avec qui j'ai bu en soirée, on va chez elle.
Puis gros blocage, j'ai juste plus envie quoi. Je me force, mais ça veut pas.
 
Gros blanc. Finalement, on est allée se faire une bouffe dans sa cuisine, et c'est resté mon meilleur souvenir de la soirée

j'ai passé l'age de faire des exercices.
C'est un problème du monde réel, et effectivement j'ai des valeurs générées à la volée.

espérons ne pas avoir min = 0 et max = 2147483647

parce que c'est la taille max d'un uint, pas d'un int.

ah dans le même genre, un autre problème que j'ai eu à résoudre cette semaine:
comment écrire un algo efficace pour déterminer l'ensemble des parties de [0, max) à moins de p éléments?

ouais t'as raison

Je vais peut-être dire une connerie mais si tu multiplies tes float par une puissance de 10 suffisante tu peux pas appliquer les algos pour entiers ? Quitte à virer les décimales quo coincident vu que la diff ne se fera pas dessus.

C'est justement tout le problème de trouver quel est l'ordre de grandeur judicieux (au fond je m'en fous de la distance min, je veux juste savoir jusqu'à quel ordre il est judicieux de comparer).
J'ai dit 10e-6 sur un exemple, mais je suis pas sur que ça va être la même chose dans une autre configuration.
 
Puis même si je voulais faire ça, ça me ferait des entiers qui peuvent aller de 0 à 10^9, cf post de lucas et livre
 

Après nlog(n) c'est pas si dégueu que ça comme complexité non plus, tu peux essayer et voir si c'est trop lent.

ouais c'est ce que j'ai dit quand je parlais de epsilon solution
 
Après il y a de sérieuses limitations à cet algo, un tri est bien plus safe.

J'ai pas trop capté pourquoi t'as besoin de faire ça.

J'ai un Z-buffer avec la profondeur de l'objet affiché sur chaque pixel.
J'ai une liste de points *p.
Je dois vérifier si les points sont visibles. Pour ça, je teste profondeur(p)>=z(pixel_position(p))
Sauf qu'à cause des erreurs de calcul, j'ai des points sur l'objet qui peuvent être calculé comme derrière...

Genre j'ai un objet qui est le plan d'équation z=0, et j'ai un point au coordonnées (0,0,0)
Mon point est sur l'objet, donc je le considère comme visible.

Sauf qu'à cause d'erreurs de calcul flottant, la profondeur du plan sur le Z-buffer sera par exemple 0.96522112552 (valeur au pif)
Tandis que la profondeur du point (0,0,0) sera calculée comme étant 0.96522113784

En coordonnées 3D, y a pas de problème, l'égalité est rigoureuse. Mais je sais pas pourquoi, le calcul du Z-buffer donne en flottant un truc légèrement différent de la fonction "float profondeur(point p)". P-e parce que le Z-buffer est calculé différemment sur la carte graphique alors que profondeur est exécuté sur le CPU.

Si je les compare directement en logique booléenne, ben le point sera considéré comme non visible (alors qu'en coordonnées 3D il l'est).

Tu peux pas calculer les deux sur le GPU ?    
T'as pas une option du compilateur à désactiver pour qu'il utilise une meilleure précision ?    
Pourquoi t'as besoin de revérifier sur un point est visible ? C'est pas l'objectif du Z-buffer déjà ?

Malheureusement non parce que mon programme est basé sur une implémentation OpenGL archaique (fixed-function pipeline), dont la classe de base n'a pas été codé par moi, dont c'est précisément le défaut :
Tu ne peux pas faire (ou difficilement) des choses plus complexes que de l'affichage.
C'est pour ça qu'il y a dix ans, OpenGL est passé aux shaders, qui eux permettent de faire des manipulations plus sophistiqués.
Un vrai dev OpenGL me taperait dessus pour ce que je fais, mais là j'ai franchement pas le temps de recoder la classe de base et tout ce qu'il y au dessus à base de shaders.

Ben c'est précisément pour ça que je m'en sers.
L'objectif du Z-buffer, c'est de tester si les points sont devant ou pas. En general, dans les applis de rendu le cas point pile sur l'objet est rare (et pas critique), du coup tu fous un epsilon un peu random et ça passe
Dans mon cas, les points sont tous "sur" mon objet rendu. Du coup, je voulais essayer de faire un truc plus propre (bon, stun peu con au fond, vu que je fais un truc sale à la base).

Cela dit, même en FFP, y a pe d'autres solutions (par ex associer une couleur à chaque point, faire le rendu de la scène et compter quelles couleurs sont là), mais de toute façon je fais un projection parce que j'ai besoin de savoir sur quel pixel se trouve tel point, donc je me suis dit autant faire le test de visibilité au passage

https://www.youtube.com/watch?v=KSguNiW8HA4
 
         

Une balle dans la tête du chat et le problème est résolu.

Et ma * dans tassör ?

Parle avec respect dma soeur imaginaire qu'existe pas fdzp

9 mois après que je passe chez toi t'en auras une batzard.  

Allah ne pardonne pas la nécrophilie, frer

Inchallah si elle est au paradis elle vit toujours frer.