Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc. - page 11

Nouveau commentaire
 
TheXpert:

C'est un crochet, aussi. En utilisant un interrupteur... et l'utilisation d'un modèle de machine à états sont deux choses différentes. On peut lire dans le texte qu'il n'y a pas de modèle, comme dans l'article que vous avez cité.

On peut y lire quelque chose comme "J'ai inventé un système de gain unique..." et ensuite une déclaration de Martin tordue.

O.K. Quelle est la différence fondamentale alors ?
 
C-4:
O.K. Quelle est la différence fondamentale alors ?
Et voilà. C'est ce que j'avais besoin de prouver :)
 
TheXpert:
Et voilà. C'est ce que j'avais besoin de prouver :)
Prouver quoi ? Ne prétendez pas être la seule personne à savoir quelque chose d'extraordinaire que vous ne direz jamais parce que vous pensez que c'est indigne de vous.
 
TheXpert:

Tu parles. En utilisant un interrupteur... et l'utilisation d'un modèle de machine à états sont deux choses différentes. Vous pouvez voir dans le texte qu'il n'y a pas de trace d'un modèle ici, ainsi que dans l'article cité.

Mais ne vous inquiétez pas, l'article sur la machine à états que vous avez donné le dit noir sur blanc :

Disons que Vasya réalise un projet en C# et qu'il a besoin d'une machine à états simple pour un type d'objets. Il écrit quelque chose comme ça :

private enum State { Disabled, Idle, Animating }

private State state;
 
void setState(State value) {
    state = value;
    switch (state) {
        case State.Disabled:
            ...
        case State.Idle:
            ...
        case State.Animating :
            ...
        break;
    }
}

Puis il continue à parler de divers cadres et de classes prêtes à l'emploi.

La conclusion de l'article est la suivante :

"Et puis Vasya en a eu marre et est revenu à la machine à états finis la plus simple du monde. Il l'a retravaillé un peu et a établi les règles pour y écrire du code."

 

Tout d'abord, je n'ai cité aucun article. :)

Deuxièmement, prendre un article comme la vérité en première instance juste parce que quelqu'un l'a cité et qu'il est sur Hubra est un peu... hum...

Une hache en pierre est aussi une sorte de hache.

 
TheXpert:

Tout d'abord, je n'ai cité aucun article. :)

Deuxièmement, prendre un article comme la vérité en première instance juste parce que quelqu'un l'a cité et qu'il est sur Hubra est un peu... hum...

Une hache en pierre est aussi une sorte de hache.

Oui, je suis désolé, il a été cité par Urain.

Si cet article décrit un modèle non étatique, alors qu'est-ce qu'un véritable modèle étatique ? Si tu peux avoir le topo... code au studio, nous allons en discuter.

 
C-4:
Eh bien... Je vais faire quelques recherches sur Google.
 
Voici une pensée intéressante.
C-4:
Une exception importante : la logique des algorithmes HFT est en fait décrite par la méthode d'exécution.

Je suis presque d'accord.

Sur cette base, je prévois d'intellectualiser davantage le driver de trading, c'est-à-dire de le doter de "cerveaux" pour une prise de décision indépendante dans des situations de tendance rapide.

// (ce qui ne fait que déplacer la limite arrière dans une "zone négative").

 
TheXpert:
Eh bien... Je vais faire quelques recherches sur Google.
Un nom familier est apparu sur le lien : A .A. Shalyto. Je crois que j'ai déjà entendu ça quelque part...
 
MetaDriver:
Voici une idée intéressante.

Je suis presque d'accord.

Sur cette base, je prévois d'intellectualiser davantage le pilote de trading, c'est-à-dire de le doter de "cerveaux" pour prendre des décisions indépendantes dans des situations de tendance rapide.

// (Ce qui, en fait, déplace simplement la limite arrière dans une "zone négative").

C'est-à-dire qu'il s'agit d'un robot dans un robot. Supposons qu'il existe un algorithme à moyen terme qui donne un ordre d'achat sur le marché. Un autre robot, de bas niveau, exécute cet ordre au meilleur prix en utilisant la technique du meilleur mouvement HFT.
1...456789101112131415161718...20
Nouveau commentaire