OpenCL : de vrais défis - page 3

Nouveau commentaire
 
TheXpert:

Y a-t-il une différence significative ?

Si vous pouvez l'optimiser, vous n'aurez peut-être pas besoin d'utiliser OpenCL du tout.

La différence est la suivante...

Il est plus pratique d'utiliser MQL5, Illyaz a déjà tout lié, alors qu'en C++ vous devez tout lier vous-même.

Si vous voulez optimiser, vous devez d'abord déterminer si vous devez utiliser OpenCL.

 
TheXpert:

Projet de studio.

La méthode la plus difficile est FeedPatterns.

Je l'ai téléchargé. Je vais regarder. :)
 
Urain:
... En C++, vous devez tout lier vous-même...

En c++, vous pouvez utiliser amp - plus simple et plus pratique, je pense.

 
kazakov.v:

En c++, vous pouvez utiliser amp - plus simple et plus pratique, je pense.

Pourquoi pas ? En outre, il constitue une base pour la parallélisation, notamment sous Win8;7, et il fait partie intégrante de Net 4.5. De plus, j'ai lu quelque part qu'il s'agissait d'un complément pour OpenCL, est-il ajouté d'une manière ou d'une autre au code ?
 
kazakov.v:

En c++, vous pouvez utiliser amp - plus simple et plus pratique, je pense.

Finalement, je vais le transférer sur MQL.
 
TheXpert:
Je vais le porter sur MQL éventuellement.

Puis ré-exécutez le projet dans MQL5 (ce sera plus rapide pour vous comme pour l'auteur). Et vérifie tout ce qu'il y a dessus.

Pour l'instant, mql4++ est incassable. Et plus tard, nous pourrons passer de F à B (dans un mois).

Tant que le projet est petit.

 
Urain:

Puis ré-exécutez le projet dans MQL5 (ce sera plus rapide pour vous comme pour l'auteur). Et l'utiliser pour tout vérifier.

Je n'ai pas encore le temps. J'ai encore un bug dans le principe de liaison des synapses... c'est pourquoi je te le dis plus tard. Mais le code affiché se suffit à lui-même.
 
TheXpert:
Il n'y a pas encore de temps. Il y a un autre bug dans le principe de construction des connexions de synapses pour réparer... c'est pourquoi je te le dis plus tard. Mais le code affiché se suffit à lui-même.
Ok, pas de problème, on va le faire nous-mêmes.
 
Urain:
Ok, pas de problème, fais-le toi-même.

Fondamentalement, seul <vector> devrait être écrasé ici, c'est un analogue de ArrayObj de la bibliothèque standard.

Vous pouvez simplement réécrire en tableaux, ou implémenter <vector> une fois pour toutes dans MQL5 (la manière fondamentale, pour ainsi dire).

 
Urain:

Fondamentalement, il n'y a que <vector> à réarranger, c'est un analogue de ArrayObj de la bibliothèque standard.

Je pourrais simplement passer aux tableaux, ou implémenter <vector> dans MQL5 une fois pour toutes (la manière fondamentale, pour ainsi dire).

Slava est lent avec les classes paramétrées. Ça fait déjà un an que je suis épuisé.

En principe, il est possible de l'écrire incorrectement, comme ceci (jusqu'à des temps meilleurs) :

#define  FF_STD(FFClassName, FFEnumName)                                           \
   class FFClassName:Ccl_FF_Functor                                               \
     {                                                                            \  // Примерно в таком стиле
     public:                                                                      \
       virtual bool CalcFF(const Ccl_Flex2dArray &Test_Res_,double &FF_[],int i_) \
          { FF_[i_]=Test_Res_.Get(i_,FFEnumName); return true; }                  \
     }
//+------------------------------------------------------------------)
//|   Реализации стандартных фитнес-функторов                       (   Дальше алгоритм использования этой хрени:
//+------------------------------------------------------------------)

// возвращает общий профит с учётом спреда (в спредах)
FF_STD(CFF_ProfitTotal_s, FF_ProfitTotal_s);

// возвращает мат-ожидание профита с условной единичной сделки с учётом спреда (в спредах)
FF_STD(CFF_ProfitPerLot_s, FF_ProfitPerLot_s);

// возвращает полный проторгованный объём сделок ((куплено+продано)/2) за тестируемый период 
FF_STD(CFF_VolumeTotal, FF_VolumeTotal);
...........
...
Tout se compile et fonctionne.
12345678
Nouveau commentaire