thoasm a écrit 9459 commentaires

nous fait chier!

Tu parles pour qui ?

Ouaip, surtout sur linuxfr, un journal à la fois mal écrit, HS, et supposant que tout le monde partage son avis et bourré de sous entendu, avec de la propagande de mauvaise qualité, ça commence quand même à faire beaucoup.

Les webservices répondent pas mal à ton besoin, dans l'esprit.

Une API pour accéder à certaines ressources, t'as un certains nombres de sites web qui en proposent, ça passe les proxys, ça peut même être filtré au besoin, tu peux développer des clients comme tu l'entends.

La standardisation est un but plus difficile à atteindre, certe, mais c'est pas impossible. Pour des ressources "simples", les API devraient être relativement similaires donc c'est pas forcément un gros problèmes, pour d'autres types de ressources on peut imaginer un standard "de fait". Ou encore des attributs "sémantiques" plus ou moins standardisés pour espérer un peu de généricité dans ce bordel, but qui me semble presque plus facilement atteignables que des API standardisées parce que la diversité des ressources à accéder est énorme pour ce type d'API, dans l'absolu ou même en pratique ...

Tu reproche de pas pouvoir faire de correspondance Objet-Relationnel vers un modèle qui n'est pas relationnel, c'est évident ;)

D'autre part les nouvelles bases de données sont plus proches du modèle objet dans l'esprit, la correspondance devrait être plutôt facilitée ... genre tu écris presque directement l'objet dans la base de données.

Tu peux faire le même genre de truc avec du duck typing dynamique, des gens ont implémentés des monades en python, par exemple.

Pas vraiment, si je me trompe pas en Haskell la sémantique des méthodes n'est cohérente que si tu le veux bien, et par convention : les monades sont supposées repecter certains axiomes, mais rien dans le langage ne peut t'interdire de ne pas les respecter, faudrait que les axiomes soient explicitement déclarés dans le langage et qu'il existe un moteur de preuve.

Sinon, j'ai simplifié, ce n'est pas simplement un nom de méthode, le duck typing, c'est aussi la signature, même si la signature est forcément moins informative que dans un système à typage plus contraignant.

Non. Typage statique c'est qu'une variable reste du même type tout au long de son cycle de vie. Typage dynamique c'est qu'une variable peut être réaffectée à n'importe quel type.

Le duck typing c'est encore autre chose : le type est défini par un l'ensemble des méthodes et/ou attributs et leur signature d'un objet.

Deux objets sont compatibles au niveau des types si ils sont compatibles au niveau de la signatures des méthodes, par exemple si t'as une fonction, ce qui est requis pour "variable" c'est d'avoir un type qui fournit la méthode cacul, et rien de plus. Son type est défini par ça -> elle fournit une méthode cacul.
Ça peut être du typage statique si tu peux plus lui réaffecter n'importe quoi derrière, et c'est du "duck typing".

fun fonction(variable) -> retourne variable.calcul()

Regarde aussi inférence de types, c'est une technique qui permet de typer statiquement une variable à la compilation, même si quand tu écris ta méthode tu ne précise pas le type de ses paramètres. C'est une manière de faire de la généricité.

Un facteur 60, comme tes premiers résultats à peu prêt, c'est cohérent.

Sinon si tu veux augmenter les temps de calcul pour y voir plus clair et rendre un peu moins important le temps de démarrages, tu peux augmenter le nombre de paires amicales à trouver, les algos sont rarement linéaires donc ça peut grossir les écarts assez facilement.

Le redessinage des barres et des sliders, ce serait pas pour gérér les barre de scrolling avec des couleurs différentes qu'on voyait autrefois ? Juste comme ça, en passant, si ça peut aider ...

(je viens de me rendre compte qu'on parlait des attributs XML, et qu'un dictionnaire est pas en général une structure adaptée pour stocker les balises, moinssez moi)

Pense à du XHTML, ou un système de formattage de document, si t'as un ensemble de paragraphe tu veux forcément conserver l'ordre.

Dans les DTD tu pouvais décrire l'enchainement des sous balises, éventuellement mélangées à du texte, par une regex.

C'est la magie des maths, on s'en fout un peu :)

42 est rationnel, par définition. Le truc qu'il a pas dans la base pi c'est une représentation finie. Note que même en base 10 1/3 n'a pas de représentation finie, bien que rationnel.

Bon du coup par contre tu perds effectivement l'unicité de représentation, cf.
http://mathworld.wolfram.com/Base.html

Cela dit on l'avait déja pas à la base puisque 1=0.999999... en base 10.

Je répondais juste à la question de savoir décrire une base autrement que par un nombre.

Cela dit je pense que la base pi ne pose pas de problème particuliers, tu utilise la suite

(pi, pi², pi^3,...)

Comment on représente une base autrement que par un nombre ? Par une suite !
je cite

Depuis que l'Homme a 10 doigts et sait compter, il compte en base 10 : ainsi, quand on parle du nombre écrit "124", on parle du nombre 4×1 + 2×10 + 1×100. La suite référence de la base 10 est ainsi (1, 10, 100, 1000, ...), ie, la suite des puissances de 10.
Changer de base revient à changer de suite de référence. La base 2 correspond par exemple à la suite des puissances de 2 (1, 2, 4, 8, 16, 32, ...). En binaire, le nombre 101 101(2) signifie alors 1×1 + 1×4 + 1×8 + 1×32, soit 45 (en base 10). Le nombre 5021(2) signifie donc 1×1 + 2×2 + 5×8, soit 45 également. Par souci d'unicité, on limite les chiffres permis à 0 ou 1 (L'écriture 5021 n'a alors plus lieu d'être, et chaque nombre possède son écriture en base 2)

Mais aucune raison de se limiter à une suite de puissances. On peut prendre... la base factorielle, par exemple. La suite de référence est alors (1, 2, 6, 24, 120, ...), la suite des factorielles (1, 1×2, 1×2×3, ...). Un nombre comme 1300(f) signifie alors 3×6 + 1×24.
Dans le même souci d'unicité que précédemment, il faut limiter les chiffres à utiliser : le chiffre des unités ne doit être que 0 ou 1, celui des 2-aines doit être 0, 1 ou 2, celui des 6-aines doit être entre 0 et 3, etc. (Celui des n!-aine doit être entre 0 et n). On peut alors compter en base factorielle :

1, 10, 11, 20, 21, 100, 101, 110, 111, 120, 121, 200, 201, 210, 211, 220, 221, 300, 301, 310, 311, 320, 321

On peut voir que le nombre 119(10) s'écrit 4321(f), mais surtout, le nombre 50(10) s'écrit... 2010(f) !

http://eljjdx.canalblog.com/archives/2010/01/03/16369282.htm(...)

Vois ça comme un genre d'énigme plutôt. Tu te dis "WTF" au début, et tu comprends ...

Je doute qu'Aristote parlait de liberté du logiciel.

Et puis bon dire qu'ergonomie de l'interface ou qualité techniques sont deux notions orthogonales à la liberté du logiciel ou de l'utilisateur, ça n'en rend pas la liberté moins importante.

En résumé, tu peux reconnaître "ce logiciel a une interface super" et enchaîner avec "mais je l'utiliserai pas parce que je veux pas filer mes mails à un tiers".

... des contributions. (entre autre).

Et on ne peut à mon avis que noter que le libre ne serait probablement pas ce qu'il est sans les contributions d'IBM and co.

Que ce passerait-il si ils arrêtaient ? Le libre "retrouverait" l'état dans lequel il était avant leur arrivée, modulo leur contributions qui de toutes façon resteront libres.

La question devient alors que serait le libre si ils n'avaient jamais contribué ?

Pour la petite histoire, Stallman a écris un article de recherche intitulé
Forward Reasoning and Dependency-Directed Backtracking in a System for Computer-Aided Circuit Analysis.
Donc rien d'étonnant dans ce que tu dis :)

Sinon, tu peux probablement exprimer ton problème dans un langage de programmation par contrainte, et le résoudre sans doute plus rapidement qu'en prolog "de base" ...

Tiens c'est marrant, je viens de tomber là dessus de manière complètement indépendante, et c'est pile dans le topic, donc je poste ici.

En gros ça ressemble à la version moderne et 'achement plus balaise, à première vue ... j'ai pas encore regardé en détail, donc je peux pas en dire plus ...

http://bienbienbien.net/2010/06/21/watson-lordinateur-le-plu(...)

D'un aute côté on parle d'une approche d'il y a 30 ans, c'est pas neuf.

J'ai un peu l'impression qu'on a pas mal abandonné l'idée de faire des requêtes en langage naturel, par exemple. Ici le truc c'est que tu fais ta requête avec une grammaire super contrainte dans un langage qui ressemble a de l'anglais, mais qui au final est à peu prêt identique au SQL et au requêtes qu'on peut faire sur des bases rdf.

Pour le requetage, même chose, quand la question est imprécise, on utilise plus des approches genre logiques floues, ou alors des approches de "guidage" de l'utilisateur avec des trucs tout faits pour construire l'utilisateur, ou des arbres de décisions ou des choses comme ça.


Globalement l'IA a fait le chemin suivant, à mon avis : ils ont commencé par des approches "universelles" qui feraient toutes la chaîne de traitement, des interactions avec les humains jusqu'aux raisonnement, typiquement une approche comme celle du journal. Ensuite ils se sont rendus compte qu'il y avait du travail à tous les niveaux pour arriver à faire un truc pareil, et l'IA a éclaté en plein de sous disciplines qui visent à résoudre des sous problèmes du problème global (typiquement le traitement du langage pour l'analyse de requête), qui ont vécues leur vie plus ou moins indépendemment.

Traitement du langage, représentation des connaissances, requêtes dans les connaissances avec la logique floue, moteurs d'inférences dans la continuité de Prolog, et pleins d'autres. C'est contrairement à ce que tu sembles dire une réponse plutôt pragmatique, et au moins nécessaire, dans l'objectif initial de l'IA tout au moins.

Ces approches ont plus ou moins d'utilité en pratique suivant l'avancement des domaines, la difficulté des problèmes, ... mais l'enjeu, c'est à mon avis de réintégrer ensemble toutes ces techniques une fois qu'elles seront suffisament matures.

Mais à mon avis si on cherche dans l'IA une méthode automagique qui marcherait immédiatement on se trompe : l'IA a la démarche d'essayer de résoudre une classe très large de problèmes, quand une approche ingénierie "classique" a plutôt pour but de résoudre efficacement un problème assez défini, ce qui est dans un premier temps largement plus simple et pragmatique ...

Si tu veux partir sur ce genre de trucs, tu peux te pencher sur RDF par exemple.

Les requêtes s'expriment dans des langages comme SPARQL, et sûrement plein d'autres
PREFIX abc: <nul://sparql/exampleOntology#> .
SELECT ?capital ?country
WHERE {
?x abc:cityname ?capital ;
abc:isCapitalOf ?y.
?y abc:countryname ?country ;
abc:isInContinent abc:Africa.
}


pour la partie traitement des requêtes ...

Ça donne l'avantage qu'il existe déja des ressources existantes et abondantes pour la bases de données, comme les trucs qui font de l'extraction de wikipedia (à partir des infobox notamment) ...

http://en.wikipedia.org/wiki/Resource_Description_Framework

C'est très bien aussi, les accesseurs ... dans un cas comme ça, tu te contente de rajouter des accesseurs, et t'as rien à modifier.