Voir les messages sans réponses | Voir les sujets actifs Whitelist Whitelist    Nous sommes le Mer 19 Sep 2018 00:53



Ce sujet est verrouillé, vous ne pouvez pas éditer de messages ou poster d’autres réponses.  [ 22 messages ]  Aller à la page Précédente  1, 2
[NOTATIONS] Un langage informatique descriptif des combos 
Auteur Message
Pen Spinner
Avatar de l’utilisateur

Inscription: Sam 11 Oct 2008 12:15
Messages: 253
Whitelist: 0 (0%)
Message Re: Un langage informatique descriptif des combos
Lindor a écrit:
Mais, et je le redis, c'est surtout l'exercice intellectuel et théorique qui me motive.


Là je suis rassuré, parce que j'ai l'impression que la conception d'un tel logiciel serait un travail gigantesque (à la limite construire un interpréteur ça doit se faire, mais ensuite faire la modélisation je préfère pas imaginer) et son intérêt me semble très limité. Tu prends l'exemple de Georges (prénom assez invraisemblable en 2020 d'ailleurs) qui veut savoir à quoi ressemble un certain trick. Bon tu tapes le nom du trick sur Google tu trouves directement une vidéo, si c'est pour faire une base de données de tricks je pense que faire une vidéo par trick serait plus rapide. La seule utilité que je vois c'est si quelqu'un qui connaît la syntaxe du langage imagine un enchaînement qu'il ne sait pas faire, qu'il ne sait pas breaker, et dont il a envie de montrer les composantes à une autre personne.
Mais bon si ça reste un travail théorique alors la question de l'utilité ne se pose plus et ça peut être intéressant de se pencher sur le problème.

Après j'ai l'impression que pour qu'il n'y ait pas d’ambiguïtés il faudrait être très précis. Quelques exemples :
Qu'est-ce que ça veut dire qu'un doigt est sur le mod ? Si je renverse la main c'est le mod qui est sur le doigt ? Si c'est ça alors il faut préciser dans quel sens est la main. Et s'il est sur le mod, à quel endroit sur le mod et quelle partie du doigt est en contact ?
Qu'est-ce que ça veut dire que deux doigts sont en contact ? Sur toute la longueur ? Aux extrémités ? Côte-à-côte ? L'un au-dessus de l'autre ? Croisés ? Tu as un opérateur qui permet de dire que deux objets sont croisés, mais ils peuvent l'être si on ne précise pas s'ils le sont ou pas.
Pour un TA rev par exemple, comment tu décris l'index recourbé sur le stylo ?
Comment tu décris la position de départ de l'anti-gravity ?
Je me demandais aussi comment différencier un TA d'un TA FL, mais finalement ce n'est peut-être pas nécessaire dans ce projet de les différencier. Je trouve ça tout de même un peu gênant.
Tous ces problèmes peuvent être résolus en étant suffisamment précis dans la description d'un enchaînement, quitte à rajouter des attributs ou des opérateurs à ce que tu as présenté, mais c'est juste pour donner une idée de la complexité que peut représenter l'écriture de certains enchaînements. Par exemple réussir à décrire de façon suffisamment précise un twisted cobra bite pour que quelqu'un qui ne connaisse pas la figure sache à quoi elle ressemble me semble assez difficile.

Pour ce que tu dis Skatox, je n'ai pas l'impression que le fait qu'un programme soit physiquement réalisable soit un problème, le but étant simplement de couvrir l'ensemble des enchaînements réalisables. L'utilisateur verra de lui-même si un enchaînement est réalisable ou non.

_________________
La vie d'une personne souffrant d'amnésie antérograde, c'est un processus de Markov.

Une suite de Cauchy veut aller à une soirée no limit. En arrivant devant le videur, celui-ci lui dit "Désolé, c'est complet".


Dim 18 Déc 2011 11:00
Profil Site Internet
Pen Spinner

Inscription: Jeu 9 Oct 2008 00:18
Messages: 48
Whitelist: 0 (0%)
Message Re: Un langage informatique descriptif des combos
en y regardant de plus près, et outre l'aspect orienté objet de ta notation, l'utilisation qu'on peut en faire ressemble très fortement à celle des expressions régulières (je pense que ça ne t'a pas échappé), ou plus généralement des grammaires de type PEG (Parsing Expression Grammar) ou autres joyeusetés.

C'est assez intéressant, et tu proposes un jeu d'opérateurs viables, mais à mon avis beaucoup TROP expressifs. Ce qui me frappe, c'est que tes opérateurs servent un peu à tout et n'importe quoi : définir les points de contact, définir les positions relatives des objets... C'est utilisable, mais si tu veux décrire un mouvement très contraint -- déjà c'est possible, alors +1 mais, il va nécessairement falloir introduire de la redondance dans ta notation, avec plusieurs apparitions des mêmes termes, pour autant qu'un objet possède plusieurs contraintes.

Là on est dans le problème de la "linéarité" de l'écriture face aux possibilités des schéma-plans ou spatiaux, mais pas seulement je pense. Si tu trouves un moyen de le faire, FACTORISE tes attributions d'opérateurs, là ça peut devenir très bon. :smile:


Mar 20 Déc 2011 15:34
Profil
Wikititeur
Avatar de l’utilisateur

Inscription: Ven 10 Oct 2008 16:50
Messages: 838
Localisation: Paris
Whitelist: 0 (0%)
Message Re: Un langage informatique descriptif des combos
Skatox a écrit:
en y regardant de plus près, et outre l'aspect orienté objet de ta notation, l'utilisation qu'on peut en faire ressemble très fortement à celle des expressions régulières (je pense que ça ne t'a pas échappé), ou plus généralement des grammaires de type PEG (Parsing Expression Grammar) ou autres joyeusetés.
J'ai pas compris en quoi.

Citation:
C'est assez intéressant, et tu proposes un jeu d'opérateurs viables, mais à mon avis beaucoup TROP expressifs. Ce qui me frappe, c'est que tes opérateurs servent un peu à tout et n'importe quoi : définir les points de contact, définir les positions relatives des objets... C'est utilisable, mais si tu veux décrire un mouvement très contraint -- déjà c'est possible, alors +1 mais, il va nécessairement falloir introduire de la redondance dans ta notation, avec plusieurs apparitions des mêmes termes, pour autant qu'un objet possède plusieurs contraintes.
Je trouve ces inquiétudes raisonnables.

_________________
Citation:
[01:12:34] <Lindor> En même temps, les autres sont tous bêtes
[01:12:43] <Lindor> soit dit sans vouloir les rabaisser, bien sûr


Mer 21 Déc 2011 02:01
Profil Site Internet
Pen Spinner

Inscription: Jeu 9 Oct 2008 00:18
Messages: 48
Whitelist: 0 (0%)
Message Re: Un langage informatique descriptif des combos
Phlogistique a écrit:
Skatox a écrit:
en y regardant de plus près, et outre l'aspect orienté objet de ta notation, l'utilisation qu'on peut en faire ressemble très fortement à celle des expressions régulières (je pense que ça ne t'a pas échappé), ou plus généralement des grammaires de type PEG (Parsing Expression Grammar) ou autres joyeusetés.
J'ai pas compris en quoi.

Le style orienté objet occulte un peu cette ressemblance, mais basiquement, utiliser des mots terminaux (ici, doigts, mods) et des opérateurs dessus (V, ||, /, etc) pour décrire un langage d'objets (ici, des tricks/combos), c'est le principe des expressions régulières, et plus généralement de toute grammaire "productive" en informatique. De plus Lindor a proposé dans son second post une utilisation à base d'éléments variables (les doigts) de façon à transformer un nom de trick en une fonction [ensemble des doigts]^N => [ensemble des tricks], où N est un nombre dépendant du trick, et ainsi transformer chaque objet "trick"-même en un ensemble. une utilisation similaire peut-être faite des expressions régulières, (et d'autres systèmes de différente expressivité mais utilisant le même concept)... Je sais pas si je suis très clair ceci dit.


Mer 21 Déc 2011 03:50
Profil
Pen Spinnerette - 2 avertissements
Avatar de l’utilisateur

Inscription: Ven 10 Oct 2008 17:54
Messages: 5143
Whitelist: 0 (0%)
Youtube: http://www.youtube.com/user/lindorspin?feature=mhe
Message Re: Un langage informatique descriptif des combos
Citation:
notamment parce qu'on travaille avec un nombre d'objets finis (à part l'infinité de tricks ou combos qu'on peut décrire)


C'est justement l'infinité des tricks qui m'a fait préférer l'usage de l'orienté objet, puisqu'on peut créer à volonté des objets pouvant être à loisir des tricks, des enchaînements ou des schémas de tricks.

Citation:
et que la syntaxe objet classique (objet.methode(args)) n'est pas forcément la plus attrayante.


Dans quel sens ? Tu veux juste dire par là qu'elle ne te plait pas ? Je rappelle que mon écriture n'est pas censée être facilement lisible par un oeil humain - je trouve qu'assez peu de langages de programmation sont "attrayants" pour un non-initié.

Citation:
Par contre, la quantité d'infos que tu arrives à caser en quelques dizaines de caractères grâce à cette notation, tout en restant un minimum verbose, est assez intéressante !

Comme tu le dis, nos objectifs diffèrent. En particulier, ma notation n'était pas faite pour être interprétée par une machine, mais bien par un oeil humain et a priori non-programmeur. Et le fond est différent aussi car l'approche et les fondations descriptives ne sont pas les mêmes.


Merci, et je requote ça parce que c'est en effet le point fondamental : je n'essaye pas de définir un système de breakdown.

Citation:
on système ne décrit que les transitions, sans représenter les états. Peut-être que c'est fiable, mais peux-tu le garantir ? Peux-tu être sûr de ce que tu décris lorsque tu ne décris que les différentes actions à effectuer, sans introduire de "checkpoints" ? J'aimerais croire que tu es dans ton droit, mais j'ai du mal


Soit c'est moi qui comprend mal ton message, soit c'est toi qui a zappé une partie de mon post. Justement, j'introduis la distinction entre les objets statiques et les objets dynamiques (entre parenthèse, cette distinction n'existe que pour aider à se le représenter, pour un ordinateur elle n'a pas de sens) :

Les objets statiques sont des positions de la main, des états, si tu préfères.
Les objets dynamiques sont des mouvements, ou des transitions, pour reprendre ta terminologie.

J'ai précisé que dans ce langage, un trick pouvait se représenter ainsi :

Position (objet statique), puis mouvement (on applique une méthode à cet objet).

La seule position non précisée est la position finale... Et j'ai bien précisé qu'on pouvait tout à fait la rajouter. Il me semble inutile de préciser la position finale pour décrire un TA, par contre si ce TA est dans un enchaînement, je rajouterai bien sûr un objet qui indique la position de la main et du mod après le TA, et donc juste avant le trick suivant.

On peut à volonté représenter des états ou des transitions, je ne vois pas ce qui bloque...


Citation:
Là je suis rassuré, parce que j'ai l'impression que la conception d'un tel logiciel serait un travail gigantesque (à la limite construire un interpréteur ça doit se faire, mais ensuite faire la modélisation je préfère pas imaginer) et son intérêt me semble très limité. Tu prends l'exemple de Georges (prénom assez invraisemblable en 2020 d'ailleurs) qui veut savoir à quoi ressemble un certain trick. Bon tu tapes le nom du trick sur Google tu trouves directement une vidéo, si c'est pour faire une base de données de tricks je pense que faire une vidéo par trick serait plus rapide. La seule utilité que je vois c'est si quelqu'un qui connaît la syntaxe du langage imagine un enchaînement qu'il ne sait pas faire, qu'il ne sait pas breaker, et dont il a envie de montrer les composantes à une autre personne.
Mais bon si ça reste un travail théorique alors la question de l'utilité ne se pose plus et ça peut être intéressant de se pencher sur le problème.


ça me rappelle mon prof de maths à qui on demande l'utilité d'un théorème (qui donne le point depuis lequel on doit se positionner pour regarder une ellipse lorsqu'on est dans un espace de dimension 3 et être sûr que c'est une ellipse et non un cercle - parce qu'en perspective, ellipse et cercles, on voit pas la différence), et qui prenait l'exemple pratique de cosmonautes dans l'espace croisant un vaisseau extraterrestre infiniment long, et souhaitant déterminer si la section de ce vaisseau était elliptique ou circulaire.

Tout ça pour dire que je ne m'intéresse vraiment pas aux applications pratiques éventuelles, c'est simplement un jeu pour moi =)

Citation:
Qu'est-ce que ça veut dire qu'un doigt est sur le mod ? Si je renverse la main c'est le mod qui est sur le doigt ? Si c'est ça alors il faut préciser dans quel sens est la main. Et s'il est sur le mod, à quel endroit sur le mod et quelle partie du doigt est en contact ?


C'est arbitraire et sans réelle importance : le "logiciel" aurait une position de la main par défaut (disons palm down), et "sur" serait définit par défaut dans cette position (par exemple : au dessus du stylo, entre le stylo et l'utilisateur). Ensuite, si on introduit une nouvelle position de la main pour un autre trick (disons palm up), "sur" serait interprété de façon inversée. Mais ce n'est pas au programmeur de se soucier de ça : il utilise l'opérateur "sur" de façon intuitive, et le logiciel l'interprète en fonction de la position de la main indiquée. Je ne me suis pas du tout penché sur la partie interprétation par le logiciel, mais je doute que ça pose problème.

Citation:
Qu'est-ce que ça veut dire que deux doigts sont en contact ? Sur toute la longueur ? Aux extrémités ? Côte-à-côte ? L'un au-dessus de l'autre ? Croisés ? Tu as un opérateur qui permet de dire que deux objets sont croisés, mais ils peuvent l'être si on ne précise pas s'ils le sont ou pas.


Il y a une autre notation : collé. Deux doigts sont en contact si on souhaite préciser, pour une raison ou pour une autre, que deux portions de ces doigts se touchent. Si les doigts sont collés, on utilise l'opérateur adéquat. Et oui, les doigts peuvent être croisés si l'on ne le précise pas : Généralement, ce sera absolument sans importance (doigts croisés ou non, un TA reste un TA). Si on veut décrire un trick dans lequel les doigts ne doivent pas être croisés, il suffira de rajouter un " !X ". Et la valeur "par défaut" peut logiquement être fixée à "décroisés".

Citation:
Pour un TA rev par exemple, comment tu décris l'index recourbé sur le stylo ?
Comment tu décris la position de départ de l'anti-gravity ?


J'ai précisé que le langage actuel était une base simplifiée. Il me semble avoir aussi précisé que l'une des extension serait de définir des sous-objets de la classe "doigt" qui seraient les classes associées au phalanges d'un doigt (trois sous classe par doigt, sauf pour le pouce). ça prend trois secondes de les définir, et définir la position de départ de l'antigravity est immédiat ceci étant fait. Rentrer dans les détails me semblait inutile dans le premier post.

Citation:
Je me demandais aussi comment différencier un TA d'un TA FL, mais finalement ce n'est peut-être pas nécessaire dans ce projet de les différencier. Je trouve ça tout de même un peu gênant.


Tu mets le doigt sur une caractéristique de mon langage, et je vais te répondre tout en répondant à ta question sur le Ta rev :

Je l'ai précisé dans le premier post, ce langage décrit le trick, mais pas la façon dont il est exécuté. Tout mouvement du poignet ayant pour but de lutter contre la gravité peut être négligé, par exemple. Pour décrire un TA rev, je dirais ceci :
1) le mod est sur l'index
2) l'index et le mod sont croisés (peut-être est-ce facultatif ?)
3) La phalange de l'extrémité de l'index est en contact avec le mod

Inutile d'être plus précis : le langage ne donne pas d'indication sur la façon dont on réalise physiquement le trick.

De là, il me semble évident que le langage se fiche de la distinction entre TA et FL TA : la seule distinction se fera dans la description de la position de départ. Un FL TA rev sera décrit comme un TA rev pour lequel le mod est posé sur les deux phalanges extrêmes de l'index : bref, l'index n'est pas positionné en contact avec le mod dans l'optique de le pousser. Mais l'impulsion n'est pas décrite.

Entre parenthèse, la notion de fingerless a créé un sacré bazars dans le système de breakdown, avec les backs qui s'opposaient aux arounds, les neobacks aux shadows... Cette notation est plus gênante qu'autre chose. C'est juste un descriptif d'impulsion, très imprécis en soit...

Citation:
Pour ce que tu dis Skatox, je n'ai pas l'impression que le fait qu'un programme soit physiquement réalisable soit un problème, le but étant simplement de couvrir l'ensemble des enchaînements réalisables. L'utilisateur verra de lui-même si un enchaînement est réalisable ou non.


De même, je peux écrire des programmes qui ne font rien d'utile ou de cohérent dans n'importe quel langage : c'est éventuellement un travail à laisser à la plate forme utilisée pour coder que de détecter des points qui ne vont pas dans le code. Mais je ne me suis absolument pas penché sur le problème, et faire détecter par une plate forme la réalisabilité réelle d'un enchaînement me semble difficile.

Citation:
C'est assez intéressant, et tu proposes un jeu d'opérateurs viables, mais à mon avis beaucoup TROP expressifs. Ce qui me frappe, c'est que tes opérateurs servent un peu à tout et n'importe quoi : définir les points de contact, définir les positions relatives des objets... C'est utilisable, mais si tu veux décrire un mouvement très contraint -- déjà c'est possible, alors +1 mais, il va nécessairement falloir introduire de la redondance dans ta notation, avec plusieurs apparitions des mêmes termes, pour autant qu'un objet possède plusieurs contraintes.

Là on est dans le problème de la "linéarité" de l'écriture face aux possibilités des schéma-plans ou spatiaux, mais pas seulement je pense. Si tu trouves un moyen de le faire, FACTORISE tes attributions d'opérateurs, là ça peut devenir très bon.


J'avais pensé à ça, mais je voulais rester simple dans le premier post, donc je ne suis pas parti sur des systèmes de description simplifiés d'enchaînement complexes... Oui, ça ne doit pas être difficile d'imaginer un système de factorisation pour les opérateurs. Mais la redondance ne me gêne pas trop en elle même, on ne recherche pas l'écriture épurée au maximum du trick, on en cherche juste une écriture. Si je n'ai pas la flemme, j'y réfléchirai malgré tout. C'est une bonne remarque.

Citation:
l'utilisation qu'on peut en faire ressemble très fortement à celle des expressions régulières (je pense que ça ne t'a pas échappé), ou plus généralement des grammaires de type PEG (Parsing Expression Grammar) ou autres joyeusetés.


Si si, ça m'a échappé puisque je ne sais pas ce que c'est. J'ai commencé l'informatique il y a 3 mois, mes notions sont approximativement nulles en ce domaine.

_________________
Je vous aime tous, sauf un.


Mer 21 Déc 2011 04:10
Profil
Pen Spinner
Avatar de l’utilisateur

Inscription: Mar 21 Oct 2008 18:19
Messages: 127
Whitelist: 4 (100%)
Youtube: http://www.youtube.com/user/ThePainspleener?featur
Message Re: Un langage informatique descriptif des combos
Si le but c'est un programme, regardez comment est fichu le code d'un jeu de skate ou de snow pour l’enchaînement des figures. Ça doit être intéressant pour vous je suppose. Et pour pas partir de zéro.


Sam 3 Mar 2012 21:53
Profil
est innocent !
Avatar de l’utilisateur

Inscription: Dim 24 Oct 2010 09:12
Messages: 2297
Whitelist: 52 (100%)
Message Re: Un langage informatique descriptif des combos
Non, c'est pas le but. Mais dans l'idée, c'est sous une forme de logiciel dont ce code servirait de base et qui créerait un combo une fois le code entré.


Sam 3 Mar 2012 22:02
Profil
Afficher les messages postés depuis:  Trier par  
Ce sujet est verrouillé, vous ne pouvez pas éditer de messages ou poster d’autres réponses.   [ 22 messages ]  Aller à la page Précédente  1, 2

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages

Rechercher:
Aller à:  

Shoutbox

© Breizh Shoutbox v1.3.0

You must enable Javascript to view the Shoutbox.

You must enable Javascript to view the Shoutbox.

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Traduction par: phpBB-fr.com
phpBB SEO
[ Time : 0.129s | 26 Queries | GZIP : On ]
Contact