S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité
Avatar de Yangzebul INpactien
Yangzebul Inscrit le mardi 6 mai 03 - 358 commentaires -
Les derniers commentaires de Yangzebul :
En même temps les règlementations actuelles permettent déjà de faire respecter les AOC. Des viticulteurs étrangers ont déjà été condamnés et même la Chine ( www.leparisien.fr/economie/l-appellation-champagne-enfin-protegee-en-chine-27-05-2013-2840381.php) les reconnaît !



Non parce qu'un appel d'offre c'est pas " montrez moi vos talents et en fonction de ça je vous choisirez". Un appel d'offre est définis par un cahier des charges qui doit être respecter par les candidats.

C'est ensuite au client de choisir le projet qui répond le mieux à son cahier des charges. En regardant le portfolio de quelqu'un ça ne suffit pas à voir s'il saura répondre à nos besoins puisque par définition chaque cahier des charges à ces spécificités. A moins que le graphiste soit extrêmement spécialisé dans le domaine du client et qu'il a un portfolio conséquent je vois mal comment on peut se faire une idée de sa capacité à répondre à nos attentes sur ces seules informations.

Dans ce cas là le client ne fais pas un appel d'offre s'il n'a pas un projet spécifique en tête mais contacte juste quelqu'un en freelance pour lui donner une vague idée de ce qu'il veut et qu'il lui fasse.





C'est le cas avec n'importe quel appel d'offre,quand tu sélectionnes un prestataire il y a toujours une zone de flou entre ce que tu t'attends à recevoir, ce qu'il a spécifié dans son offre et ce qui est produit réellement.

Tu remarquera que le lien de tryx rejoint beaucoup ce que je dis. Ils rajoutent une "note d'intention" dans le lot, mais la encore c'est comme tout réponse à appel d'offre : cela reste flou.
Je suis partiellement d'accord avec toi, toute la difficulté est le processus utilisé. Tu ne peux, pour moi, clairement pas utiliser ce procédé ici sans forcément lésé une partie.

(...)

La difficulté pour les graphistes c'est la limite entre le côté prestation de service et artistique fournis. Il y a un véritable travail de recherche et d'imagination pour coller au mieux à la demande qui effectivement au final ne sera pas rémunérer alors que finalement dans un appel d'offre ordinaire nous sommes plus à l'état prototype, maquette ou présentation du produit (ce qui est mon cas), là dessus je te rejoins totalement.


Si on devait faire une comparaison équitable, le graphiste devrait ici fournir son portfolio pour montrer ses compétences et un devis détaillé : nombre et nature des livrables, nombre de retours éventuels, nombre de jours de travail et taux horaire en cas de dépassement de celui-ci.

Mais pas de maquettes !
Le client peut parfaitement faire son choix avec seulement ces éléments, et on serait bien plus proche ici de ce qu'une entreprise de service fournit lors d'un appel d'offre.

Edité par Yangzebul le jeudi 24 juillet 2014 à 10:51

Bien sûr que non, pourquoi devraient-ils l'être puisque nous discutons depuis le début de deux ensembles de valeurs distincts ayant la même cardinalité, entre lesquels existe une transformation bijective et dont les membres de l'un ont une représentation plus compacte que leurs correspondants.


Ou est ce que j'ai dit ça ?! J'ai dit


- Hors une bijection entre deux ensemble implique forcément que ces deux ensembles aient la même taille.


Ce qui je te l'accorde peut être ambigüe, mais c'est une formulation grossière en langage naturel, le formalisme n'est pas le but recherché.

Au contraire tu as déjà essayé de prendre le problème de cette manière et je t'ai déjà répondu très explicitement :

Quand je dis ensemble je ne parle pas du fichier, mais de l'ensemble des fichiers exprimables dans un espace donnée (chaque fichier étant un point dans cet ensemble). Je faisais une description grossière du "pigeonhole principle".


Je n'ai jamais parlé d'ensemble ayant la même cardinalité mais d'ensemble de même taille !! Et qui par conséquent ont la même cardinalité.




C'est surtout que tu as voulu te la jouer, que tu as raconté n'importe quoi et que depuis un petit moment tu me tiens la jambe en refusant de reconnaître tes erreurs.

Dommage, les erreurs sont une chose normale en phase d'apprentissage. Ne pas savoir les reconnaître quand on te met le nez dedans est un tort.


Bon d'accord j'ai compris tu t'es mis en tête depuis le début d'essayer de me rabattre le caquet. Cela ce sent, tu préfères chercher à interpréter mes posts de manière à ce que j'ai tord plutôt que comprendre ce que j'ai dit réellement.

Belle mentalité de cour de récré.
Bravo c'est toi qui est le plus fort.

Moi j'arrête là tout à été dit, je ne vois pas l'intérêt d'essayer de parler à quelqu'un dont le but n'est pas de se comprendre mais de chercher l'affrontement.

Bien sûr que si : le million de points de code spécifiés par la norme Unicode, soit un peu moins de 2^21. Ils sont tous représentables aussi bien en utf-8 qu'en utf-32.


Pas dans le même espace !

Ce n'est pas le principe qui est en cause mais la façon dont tu l'utilises.


Tu veux dire comme ça :

http://gailly.net/05533051.html

On va dire qu'on a un problème de communication tout les deux.

Ce quatrième point est faux : il suffit de considérer une bijection de utf-32 vers utf-8 : une valeur utf-8 n'est jamais plus longue qu'une valeur utf-32.


Le premier point était donc imprécis ou non-pertinent, le second faux ou non-pertinent, le quatrième faux.

Et en fait le cinquième aussi, tiens : une fonction qui réduirait le plus souvent la taille mais l'augmenterait parfois pourrait tout de même être considéré comme une compression.


Sauf que dans ton exemple les deux ensembles n'ont pas la même taille.

Je veux bien que ma formulation soit maladroite, imprécise, ambigüe ou mal formalisée, mais fausse.

Mais bon on ne sais jamais peut être va tu démontrer que le pigeonhole principle est faux et obtenir la médaille Fields dans quelques années pour avoir révolutionné les mathématiques combinatoires.

Dans ce cas c'est ton second point qui est erroné : oui les deux ensembles ont la même taille mais ce n'est pas le décompte de l'ensemble des fichiers possibles qui nous intéresse mais la taille de chaque élément.


En quoi c'est différent de cette formulation ?

"- Comme les deux ensembles ont la même taille il existe forcément des points dont la taille augmentera après transformation."

La vision d'un fichier comme un simple ensemble est fausse car tu perds les informations implicites de l'ordonnancement et du format. Pour t'en convaincre tu n'as qu'à te demander quels seraient les éléments de cet ensemble ? 0 et 1 ? Nous n'irions pas loin. Les pixels ? Donc réordonner les pixels avec une bijection ne détruit pas l'information ?

Et puisque la prémisse est erronée...


Quand je dis ensemble je ne parle pas du fichier, mais de l'ensemble des fichiers exprimables dans un espace donnée (chaque fichier étant un point dans cet ensemble). Je faisais une description grossière du "pigeonhole principle".

Après c'est vrai que Shannon utilise bien le terme compression, et dans la pratique comme l'entropie de ce que l'on veut compresser est rarement élevée, cela réduit effectivement la taille.
Ma vision de la sémantique exacte du terme est peut être un peu trop étriquée.

Edité par Yangzebul le mercredi 16 juillet 2014 à 18:20
C'est tout. Le sens "strict" dont tu parles n'a pas vraiment de réalité à l'usage informatique. Pas la peine de se gargariser avec.


C'est donc exactement ce que je disais à OlivierJ avant que tu débarques sur tes grands chevaux au milieu de la conversation.

Dis moi il y a une raison pour justifier que tu sois agressif comme ça ? ma tête te reviens pas ?


Dans ton explication, tu dis que ce qui n'est pas une compression est un encodage.
Euh, hein ?

Dans tous les cas on fait de l'encodage, puisqu'on ré-interprète les données d'origine avec un autre ensemble de symboles que celui d'origine, peu importe que la taille des données finales soit supérieure, inférieure ou égale à celle des données originales.


Oui, mais la réciproque n'est pas vrai, un encodage n'est pas forcément une compression.

Enfin, si l'ensemble final est plus léger que celui de départ, on a compression.


C'est exactement ce que je dis dans le dernier point de la preuve par comptage "Donc ta transformation n'est pas une compression car elle augmente la taille de certains points de ton ensemble : c'est un encodage".

Globalement tu es d'accord avec tout ce que je dis mais tu prends tout mes messages à contresens. Détends toi un peu.

Edit :



Oui, je viens de m'en rendre compte
Déformation trollessionnelle.


OK

Edité par Yangzebul le mercredi 16 juillet 2014 à 17:16


Et il faut encore différencier "compression avec perte" et "compression sans perte", hein.


Tu n'as pas compris la discussion.
Au sens strict (mathématique) du terme "compression sans perte" est un oxymore.

Une compression implique forcément une perte :

- Si tu transformes un ensemble de données en un autre ensemble sans perte cela veut dire que tu utilise une bijection.
- Hors une bijection entre deux ensemble implique forcément que ces deux ensembles aient la même taille.
- Donc il existe pour chaque point de cette ensemble une image dans l'autre ensemble.
- Comme les deux ensembles ont la même taille il existe forcément des points dont la taille augmentera après transformation.
- Donc ta transformation n'est pas une compression car elle augmente la taille de certains points de ton ensemble : c'est un encodage

Cela s'appelle la preuve par comptage.



Enfin bref, ce que je disais c'est que personne ne fait cette distinction dans la langage courant.