kantien a écrit 1225 commentaires

Euh il y a un point qui m'échappe dans ta présentation : il est où ton capital, histoire que ta monnaie donne confiance ?

Non parce que le principe du commerce, c'est l'échange de biens/services contre des biens/services. Là on a Jice qui possède un capital de dix noix de coco (peut être même plus) et Strash le voudrait bien pour lui. Malheureusement, il n'a rien à lui donner en échange au comptant. Sur ces entre faits, tu te pointes, sans aucun capital valant celui de Jice, tu émets du coquillage et prétend que ça vaut le capital de Jice ? Tu ne serais pas un peu escroc sur les bords par hasard ? Les banques, elles, ont du capital pour garantir leur émission de monnaie… C'est là la source de la confiance dans la monnaie créée ex nihilo. ;-)

T'as du zapper cette partie dans ton lien wikipédia :

Le jeu d'écriture comptable est le suivant:

• inscription de l'augmentation du dépôt du client (qui est, ici, le prêt de la banque à son client) au passif du bilan de la banque, la monnaie sur le compte du client étant due par la banque à son client.
• inscription de la créance à l'actif du bilan de la banque, la monnaie due par le client étant considérée comme un actif de la banque.

Si t'as pas de capital à la base, en cas de défaut du débiteur, tu te débrouilles comment avec ce passif dans ton bilan ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Je sais très bien comment est créé la monnaie et le fonctionnement du processus de création monétaire par le crédit : « le crédit crée les dépôts ». C'est exactement ce que je décris dans ma petite histoire entre Jean, Antoine et Murielle : le crédit de Jean crée le dépôt.

Au départ je croyais que c'était ce principe qui heurtait Jice, raison pour laquelle je l'ai illustré simplement pour montrer qu'il n'y a rien de choquant dans le principe. Mais il semblerait, qu'au fond, ce ne soit pas ce principe qui le choque, mais le fait qu'il y ai de l'intérêt sur ce crédit lorsque le dépôt est créé ex nihilo par la banque. Ce qu'il semble remettre en cause c'est le principe de l'usure et de savoir si la banque rend un service pour laquelle elle exige un service en contre partie sous la forme d'intérêt. Le système est tout aussi juste est légitime dans ce cas, comme dans ma petite histoire entre mes trois personnages, mais ici ce serait plus long à expliquer du fait de la complication du système afin qu'il passe à l'échelle (oui, le système de Jean, Antoine et Murielle ne passe pas vraiment à l'échelle si Murielle n'a jamais entendu parler de Jean et ne peut faire confiance dans la monnaie émise).

On peut trouver dans ce pamphlet une piste d'explication du principe (voir, par exemple, l'histoire du rabot : il est peut être même bon de commencer la lecture par cette histoire en faisant une recherche dans la page avec le mot clef « le rabot »).

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

La dette est ainsi inscrite dans la création même de la monnaie.

Et pourquoi voudrais-tu qu'il en soit autrement ?

Jean, coiffeur, se rend chez Antoine, restaurateur. « Bonjour monsieur, je désirerais prendre un repas chez vous. En échange du service que vous me rendrez, je vous en rendrez un autre : celui de vous coupez les cheveux dans mon salon, et je vous donne pour cela un bon pour coiffure en reconnaissance de ma dette ».

Voilà, sans s'en rendre compte, par cette reconnaissance de dette, Jean et Antoine viennent d'inventer le principe même de la monnaie. Il se peut, qu'au final, Antoine ne veuille finalement pas se faire couper les cheveux mais préfère un massage. Il se rend alors chez Murielle et lui propose, en échange de son massage, soit un repas chez lui soit de bénéficier, à sa place, de la coupe qu'Antoine lui doit. Si elle a beoin d'une coupe de cheveux et fait confiance dans l'émetteur de dette, en l'occurence Antoine, elle accepte le marché. Maintenant si on fait abstraction des biens et personnes concernés, on obtient le principe de la monnaie : c'est un type universel pour représenter une reconnaissance de dette.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

non mais sérieux adopteunmec c'est quoi dans vos esprits, un site de rencontre philosophiques pour deviser des avantages comparés de la méthode socratique vs Kant ? (invocation de Kantien en cours)

Bah, à une époque j'utilisais Meetic pour ça… enfin je veux dire, par pour deviser des avantages comparés de la méthode socratique vs Kant.

Sinon pour rester dans le thème Weboob, par un heureux hasard, hier dans ma ville dans le cadre des marchés de Noël, il y avait un commerçant venu présenter sa bière. Son utilitaire, habillé aux couleurs de son produit la bière kékette, portait en gros le slogan : « un petit coup de kékette ? ». Je vous laisse imaginer le nom de sa bière ambrée…

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Frama-C est sous LGPL avec des parties en BSD.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

à priori f-lambda peut traiter ce genre d'optimisation ?

A priori, j'aurais tendance à répondre oui. Flambda est une phase d'inlining beaucoup plus aggressive de la part du compilateur, avec des heuristiques pour que la taille du code spécialisé généré n'explose pas trop.

On peut avoir, par exemple, un facteur de gain de x20 en vitesse d'exécution grâce à la spécialisation par flambda d'un code hautement fonctorisé.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Qu'en pensez-vous ?

Que je ne suis pas sur d'avoir compris ta question. Ce que tu demandes ressemble fort à de la spécialisation de code à la compilation, c'est à dire de l'évaluation partielle ou inlining (qui ne se limite pas à de la propagation de constante littérale) et que c'est ce que fait f-lambda.

Quand tu passes de (fun x y -> x + y) 2 à (fun y -> 2 + y), tu fais une étape de béta-réduction, c'est-à-dire que tu exécutes le code, mais tu peux faire cela avec n'importe quelle expression du langage (pas simplement une constante comme 2) et c'est de la spécialisation de code par inlining.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Surtout que l'on parle du langage, ça n'empêche pas de faire une arithmétique loufoque dans une bibliothèque.

Dès qu'on a des fonctions polymorphes dans le langage, on peut faire une implémentation loufoque de l'arithmétique (mai l'arithmétique en question n'est pas loufoque). L'idée consiste à identifier un entier avec le principe de définition par récurrence (n x f = f (f ...(f x)), l'entier n applique n fois la fonction f à x) :

module N = struct
  type t = {n : 'a. 'a -> ('a -> 'a) -> 'a}
  let zero = {n = fun z _ -> z}
  let succ m = {n = fun z s -> m.n (s z) s}
  let fold {n} = n
  let rec nat = function 0 -> zero | n -> succ (nat (pred n))
  let int n = fold n 0 (fun x -> x + 1)
  let even n = fold n true not
  let odd n = fold n false not
  let add n m = fold m n succ (* n + m = n + 1 + ... + 1 *)
  let mul n m = fold m zero (add n) (* n * m = 0 + n + ... + n *)
  let exp n m = fold m (succ zero) (mul n) (* n ** m = 1 * n * ... * n *)
  let (+), ( * ), ( ** ) = add, mul, exp
end

à l'usage :

N.(even (nat 5));;
- : bool = false

N.(even (nat 4));;
- : bool = true

N.(int (nat 2 ** nat 8 + nat 5 * nat 2));;
- : int = 266

(* la suite de fibonnaci *)
let fibo n = fst N.(fold n (zero, nat 1) (fun (x, y) -> (y, x + y)));;
val fibo : N.t -> N.t = <fun>

N.(int (fibo (nat 10)));;
- : int = 55

:-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Seulement, contrairement à Pijul, les dév de Git ne se sont pas amusé à refaire une lib SSH.
Ou bien j'ai encore raté un second degré ?

Non, t'as juste raté la discussion sur le sujet dans le premier journal qui présentait pijul (dont le lien est donné dans celui-ci), discussion qui débute ici.

Tu pourrais aussi lire le reste du fil des commentaires pour avoir une idée de la réponse à la question « pourquoi pijul ? ». ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

On simplifie au maximum en réduisant le nombre de parcourt de listes pour construire la liste résultante. Les compréhensions de listes, c'est de la composition de map et filter.

[f(i) for i in une_liste if p(i)]

c'est l'équivalent python du code haskell :

map f . filter p $ une_liste

puis on utilise les lois de bases de map et filter :

map f . map g = map (f . g)

filter p1 . filter p2 = filter (p1 & p2)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

quelle serait l'alternative au même code sans compréhension de listes ?

Au lieu d'imbriquer les compréhension de listes, n'en faire qu'une avec pour condition la conjonction des deux autres. ;-)

[for i in [for j in une_liste if condition1] if condition2]

est équivalent à

[for i in une_liste if (condition1 & condition2)]

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Ce n'est pas parce que le compilateur connait le type que le "programmeur" oui.

Bah si il le connaît. ;-)

Je n'écris presque jamais aucune annotation de type en OCaml (je n'écris les types que dans les interfaces de mes modules, ou quand le compilateur ne peut inférer le type) et je n'ai aucun problème pour connaître le type de mes données à la lecture du code. C'est pareil pour les codes que je lis, et c'est le cas de tous le programmeurs habitués au langage. Les seuls que je vois écrire des annotations, c'est ceux qui viennent des langages avec annotations explicites (comme Java ou C++).

Cela étant, contrairement à ce qu'a dit Renault, ce n'est pas spécialement moderne comme caractéristique d'un langage : le système date du début des années 80.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Ben c’est indécidable, il me semble, parce qu’il faudrait détecter les points de code inaccessibles.

Je me rend compte que j'étais resté trop évasif sur ma notion de nécessaire, j'entendais par là la nécessité au sens de l'approximation conservative telle que définie dans ton lien. Est nécessaire tout ce qui est potentiellement appelé, même sous une condition dynamique qui ne peut jamais terminée.

Mais je dois être biaisé dans mon appréhension de la difficulté, d'après Nicolas Boulay le linker de Gcc effectue ces suppressions (quoi que ça ne signifie pas que le problème soit simple à résoudre).

Pour illustrer ce que j'ai en tête, je l'illustre avec un exemple en programmation modulaire. Imaginons qu'on a un module de List avec cette signature :

module type LIST = sig
  type 'a t
  val nil : 'a t
  val singleton : 'a -> 'a t
  val cons : 'a -> 'a t -> 'a t
  val hd : 'a t -> 'a
  val tl : 'a t -> 'a t
  val append : 'a t -> 'a t -> 'a t
  val map : ('a -> 'b) -> 'a t -> 'b t
  val fold_left : ('a -> 'b -> 'a) -> 'a -> 'b t -> 'a
  val flatten : ('a t) t -> 'a t
end

Un tel module définit le concept de liste chaînée, ainsi que quelques propositions de base sur lui (une théorie élémentaire sur les listes, en somme). Maintenant, je veux écrire un programme qui utilise ce concept mais le seul théorème qui m'intéresse est que l'on peut mapper une liste. Problème pour le compilateur : faire en sorte que seul le code de List.map soit lié statiquement à mon binaire, mon programme n'ayant rien à faire du fait que l'on puisse aplatir une liste de listes par exemple.

On retrouve le même genre de questions dans les langages orientés objets (un objet c'est le module du pauvre) : ne pas lier statiquement le code des méthodes dont on est certain qu'elles ne seront jamais appelées.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Le truc qui fait que la gestion des dépendances est NP-complet c’est pas le graphe de dépendance en soi, si je me trompe pas, c’est qu’à chaque dépendance on a le choix entre plusieurs versions de dépendance et les contraintes qui font que certaines de ces versions ne sont pas toutes compatibles entre elles, ce qui nous donne un genre de problème de satisfaction de contraintes.

Effectivement, c'est ce que je me suis dit après avoir écrit le message, la NP-complétude vient peut être de la prise en compte des conflits entre paquets (ce qui revient à gérer la négation logique dans le problème SAT sous-jacent).

Après que les compilateurs effectuent déjà de l'élimination de code mort, je le sais bien. Mon interrogation, dans la lignée de celle d'arnaudus, est plutôt de savoir à quel point il est difficile de ne garder que ce qui est nécessaire et suffisant pour faire tourner le binaire, ni plus ni moins.

Dans l'exemple que j'ai écrit, il me semble bien que le compilateur OCaml va me lier statiquement tout le module List bien qu'une grande partie de son code ne soit pas utilisé. Dans le cas d'un langage orienté objet, si mon binaire n'utilise pas toutes les méthodes d'un objet, il n'est pas nécessaire de compiler les méthodes non utilisées. Mais à quel point cela peut-il perturber le schème de compilation pour le code d'un objet ?

Quand on fait de la liaison dynamique, on reporte la difficulté sur le gestionnaire de paquet qui doit alors gérer un problème NP-complet (mais c'est sans doute lié au problème de conflits, qui n'existe pas pour la liaison statique). En revanche, pour la liaison statique, ce n'est pas sûr que le problème soit tellement plus simple si on ne veut garder que ce qui est absolument nécessaire, ni plus ni moins, et résoudre la question dans son entière généralité.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Je ne suis pas sûr qu'il soit aussi simple de détecter les bouts de code qui ne seront jamais appelés

À première vue, je dirais que le problème est NP-complet.

let f l = List.map (fun i -> i + 2) l

Ici, la fonction f dépend à la fois de la fonction map du module List ainsi que de la fonction (+), fonctions qui elles-mêmes peuvent avoir d'autres dépendances en amont. Le graphe de dépendances est du même genre que celui d'un gestionnaire de paquets logiciels pour une distribution. Or, il est connu que ce problème se ramène à un problème SAT (voir projet mancoosi) qui est NP-complet.

Après, si les compilateurs se mettent tous à embarquer des solveurs SAT (même optimisés pour les graphes de dépendances que l'on trouve dans du code idiomatique), il y en a qui vont se plaindre que la compilation dure trois plombes et que les compilos modernes sont tous bloated. :-P

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Ce n'est pas plus facile de partir de l'axiome “il existe un ensemble infini”?

Non, pas vraiment. En fait le processus qu'il décrit est celui de la définition d'un ordinal, cela afin de développer la théorie des ordinaux et l'arithmétique transfinie de Cantor dans ZF. Puis l'axiome de l'infini consiste à affirmer qu'il existe un ordinal limite (i.e. qui n'est pas le successeur d'un autre ordinal, mais l'union des ses antécédents par la relation d'ordre que définit l'appartenance sur eux), ce qui revient tout simplement à affirmer, de manière détournée, que l'arithmétique de Peano est cohérente (elle a un modèle, à savoir le plus petit ordinal limite que l'on appelle ).

J'ai pas trouvé le temps d'écrire ce que je voulais faire, ça attendra un peu. Mais juste pour montrer que ZF est un peu étrange sur sa notion d'ensemble, au niveau de l'arithmétique standard on se retrouve avec ça :

Tout est ensemble : un entier est un ensemble, les ensembles ne sont composés que d'ensembles. Il n'y a rien d'autres que des ensembles : les ensembles et leurs éléments sont considérés comme des entités homogènes. Un modèle de ZF est un module U qui satisfait cette signature :

module type ZF = sig
  type t
  val eq : t -> t -> bool
  val appartient : t -> t -> bool
end

Dans ZF, on ne peut formuler une proposition comme : tout entier est pair ou impair, mais seulement : pour tout objet, si c'est un entier alors il est pair ou impair.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Pour les naturels, j'ai en fait un doute.

Si, on les définissait ainsi :

type naturel = Zero | Succ of nat

Là je l'ai écrit avec la syntaxe OCaml, mais l'idée était la même : une entier est soit zéro, soit le successeur d'un entier. Avec comme principe fondamental pour raisonner sur ce concept, le principe du raisonnement par récurrence (ou de manière équivalente, tout sous-type des entiers a un plus petit élément).

Pour donner une référence, c'est ainsi que Poincaré présentait l'arithmétique dans la Science et l'Hypothèse (ou la Valeur de la Science, je ne sais plus lequel des deux).

Pour l'encodage des entiers dans ZF et sa théorie des ordinaux, cela a son intérêt mais ZF (la théorie axiomatique des ensembles) est une théorie un peu étrange qui ne manipule pas des ensembles au sens où on l'entend usuellement. Quand tu dis que tu admets sans détails les principes de cette théorie, c'est en fait plutôt ceux de la théorie des types que tu as en tête (bien que tu appelles ensembles ce que cette théorie appelle types).

Je n'ai pas le temps de développer plus sur le sujet ce soir, mais j'essaierai demain ou dans le week-end.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Petite erreur dans mon développement de Taylor pour l'étude au voisinage de , il fallait lire :

qui se comporte comme un terme de la forme au voisinage de .

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

À mon époque (une vingtaine d'années), les tribus et la théorie de la mesure de Borel-Lebesgue c'était à partir de la licence; en prépa on ne voyait que les intégrales de Riemann. En revanche les constructions de naturels, fractions, réels… ainsi que le théorème fondamentale de l'algèbre était bien au programme (avec la démonstration).

Pour la preuve, une esquisse fait juste appel à des résultats de base de topologie et de comportements asymptotiques au voisinage de zéro et de l'infini des polynômes. Pour des complexes assez grand en module, le module d'un polynôme non constant se comporte comme son terme de plus haut degré et tend donc vers l'infini. On se limite donc à l'étude de son module sur un domaine fini. Or toute fonction continue sur un compact admet un minimum : il reste à montrer que ce dernier est bien zéro, et donc que le polynôme admet une racine. Soit un nombre complexe tel que soit de module minimal. Cette fois, on a qui se comporte au voisinage de comme le monôme de plus petite puissance (le premier des non nuls, qui existe car le polynôme est non constant). Ainsi, pour un petit rayon, à quelques perturbations près, l'image d'un disque autour de est un disque. Or si l'image de ce disque n'est pas centrée sur l'origine, i.e. si n'est pas une racine, alors on peut trouver à l'intérieur un complexe de module plus petit que celui de l'image de , ce qui contredirait sa minimalité. Donc est une racine du polynôme.

CQFD.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

En gros, l’idee c’est de désigner le bouzin pour rendre ce genre d’erreurs impossible/très dure a écrire en premier lieu.

Oui, et c'est ce qui m'a le plus choqué dans l'article : utiliser des conventions syntaxiques sur les noms de variables et non le système de types pour porter des informations sémantiques. Un code non propre ne devrait même pas compiler !

Pour faire court :

• les types sont des concepts dont on construit les objets ;
• les chaînes de caractères se subdivisent en deux catégories : les sures et les autres ;
• on définit un sous-type pour représenter les chaînes sures ;
• la fonction write ne doit accepter que des chaînes sures en entrée, sinon le code refuse de compiler.

Grossièrement, une spécification simplifiée de son problème dans la syntaxe de mon langage de prédilection ressemble à ceci :

val request : field -> string

module type Safe = sig
  type t = private string
  val encode : string -> t
  val write : t -> unit
end

J'ose espérer que l'auteur n'est pas responsable de système critique sur le plan de la sécurité ou il vaudrait mieux qu'il retourne fabriquer du pain industriel : il n'y a rien de plus sale et moins propre que ce qu'il préconise. ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

95% de la monnaie est de la dette. Que se passera t'il si 95% de la monnaie disparaît ? Fin de la consommation, fin du crédit, fin de l'€uro. Croire au remboursement de la dette est un conte de fées. Et s'il est des utopistes ce sont ceux qui depuis si longtemps croient au même conte plutôt qu'aux comptes.

Je trouve extraordinaire d'être si critique envers une expérience visant à vérifier s'il est possible d'utiliser une monnaie à création positive (donc sans dette), et le l'être si peu avec la monnaie émise par endettement, qui pourtant est tellement déconnante qu'après la crise de 1929 on se retape celle de 2008.

Bah, d'un autre côté, depuis qu'il y a de l'argent qui circule en ce bas monde il en a toujours était ainsi comme il se doit : l'argent est et sera toujours, conformément à sa nature, une reconnaissance de dette. ;-)

Vous avez un écu. Que signifie-t-il en vos mains ? Il y est comme le témoin et la preuve que vous avez, à une époque quelconque, exécuté un travail, dont, au lieu de profiter, vous avez fait jouir la société, en la personne de votre client. Cet écu témoigne que vous avez rendu un service à la société, et, de plus, il en constate la valeur. Il témoigne, en outre, que vous n’avez pas encore retiré de la société un service réel équivalent, comme c’était votre droit. Pour vous mettre à même de l’exercer, quand et comme il vous plaira, la société, par les mains de votre client, vous a donné une reconnaissance, un titre, un bon de la République, un jeton, un écu enfin, qui ne diffère des titres fiduciaires qu’en ce qu’il porte sa valeur en lui-même, et si vous savez lire, avec les yeux de l’esprit, les inscriptions dont il est chargé, vous déchiffrerez distinctement ces mots : « Rendez au porteur un service équivalent à celui qu’il a rendu à la société, valeur reçue constatée, prouvée et mesurée par celle qui est en moi-même. »

Frédéric Bastiat, Maudit Argent.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Honnêtement je ne pense pas que l'abonnement soit le principal frein, avoir une offre de transport bien fichue (horaires larges, bonne fréquence) est plus importante.

D'autant qu'en Ile-de-France (région donnée en lien dans le message auquel je répondais), les abonnements ne représentent que 30% du financement du service. Ça représente 3 milliards d'impôts à imaginer sur les 10 milliards de frais de fonctionnements. M'enfin la question à laquelle la personne répondait n'était pas, comment financer autrement les transports en commun, mais comment les rendre moins chers, ou plutôt pourquoi ne pas réduire le coût des abonnements ? Si la solution c'est : on prélève les 3 milliards ailleurs, je ne sais toujours pas si je dois rire ou pleurer.

Après pour les économies réalisées sur la gestion des abonnements, j'aimerais bien savoir combien il reste à l'arrivée sur ces 30%, mais à mon avis c'est peanuts et rien ne dit qu'elles ne seront pas absorbées par un possible surcoût lié à l'amélioration de l'offre (fréquence, horaires plus larges…). Et l'argument peut s'appliquer à d'autres services à usage illimité utilisés par une proportion encore bien plus grande de la population : téléphonie et internet. D'autant que sur ceux-ci, on peut également arguer, comme pour les transports, d'une contribution de la part des entreprises (elles l'utilisent, cela facilite le télétravail…). Pour choisir entre les services que l'on collectivise à 100%, on fait comment : on joue à pile ou face ? ça dépend du sens du vent ? là c'est différent, c'est une priorité écologique (c'est à la mode en ce moment) ? le politique fait une estimation de l'avantage électoraliste de la mesure ?

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Et pourquoi pas carrément rendre les transports gratuits pour les usagers comme c'est le cas à Aubagne depuis 2009 ?

Rien n'est gratuit dans la vie, sauf le don pour celui qui le reçoit. Ce genre de système ne fait que déplaçait la source de financement : c'est financièrement rentable pour l'usager si son voisin qui n'utilise pas les transports prend sur lui une partie de ce qu'il payait auparavant. Le vol collectivement et légalement organisé, voilà un projet de société intéressant. ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Taper donc pas trop fort svp.

Ici on ne tape pas fort, mais en rythme. Il existe même, sur la question, un outil de métrologie à la pointe de la technologie et de l'état de l'art, en différentes versions dont une du maître Jedi.

OpenTango pourrait suivre la même voie avec un portage de la clef usb avec différentes distributions de base. Nul doute que la version Arch Linux remportera la palme étant la seule à promettre de toujours rester à la pointe de l'état de l'art. :-D

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

Certes, mais la société et le propriétaire de l'animal considèrent que ce dernier est en mesure de pouvoir agir afin d'éviter une telle situation; si elle se produit alors c'est que les mesures de préventions n'avaient pas été prises et le propriétaire est considère a priori comme responsable. Dans le cas de la voiture totalement autonome, en dehors de ne jamais s'en servir (ce qui réduit grandement son utilité), je ne vois pas comment le propriétaire pourrait éviter le risque d'accident.

Sinon, au sens propre du terme, une machine ne prend pas de décision : c'est là une représentation quelque peu anthropomorphique de ce que l'on nomme improprement¹ intelligence artificielle. ;-)

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.