Recherche dans les paquets matriciels - page 5
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Super, c'est mon premier jour d'apprentissage de R, répondez à mes questions s'il vous plaît, je veux comparer les possibilités de R et Matlab. Mais sans bavardage, de manière équilibrée et calme :).
1. Oui.
2. Pourquoi ? Vous avez besoin d'un seul MT4R.dll qui est la passerelle pour transférer les données vers R et récupérer les résultats.
3. A toutes les bases de données existantes. De plus, Microsoft et Oracle ont tous deux intégré R dans leurs bases de données.
4. R dispose de diverses options d'interface avec Matlab, allant du simple échange de fichiers Matlab à l'exécution de fonctions Matlab depuis R. Si vous avez de l'expérience dans ce domaine, vous pouvez implémenter une excellente interface Matlab-MTterminal avec R.
5. Dans R, les paquets pour toutes les directions d'une science et d'une technique et prenant en compte les dernières réalisations sont réalisés. Vous pouvez commencer par là.
6. Il y en a plus d'un. Le plus courant est le ff.
En général, je suis surpris. Tu es au milieu de nulle part. Consultez les articles 1 et 2 de ce site. Vous ne comprendrez pas grand-chose mais vous aurez une idée du fonctionnement de la langue.
Je suis en train de terminer le deuxième article sur l'apprentissage profond que j'espère vous envoyer demain pour révision. Les exemples seront joints aux experts... S'il y a un intérêt, je pense que j'écrirai plusieurs articles sur le niveau initial (filtrage, décomposition, prédiction etc.). Et bien sûr, continuez à creuser sur l'apprentissage profond, d'autant que Google a ouvert sa bibliothèque TensorFlow à tous. Et il en existe d'autres non moins intéressants et prometteurs (mxnet, pyBrain).
Si un groupe de passionnés se réunit, nous pouvons organiser une branche d'utilisateurs du langage R.
Bonne chance
Veuillez décrire plus en détail le processus de travail de cette DLL. Et où l'obtenir ?
Discutons de la manière dont nous pouvons améliorer l'intégration avec R ?
C'est un sujet intéressant et il peut être bien développé.
Salut.
Je vais ajouter à ce qui a été dit auparavant.
L'option 1 est privilégiée pour plusieurs raisons :
Dans cette variante, nous assurons simplement le transfert de données au processus R et recevons des données de celui-ci. Ce qui est fourni dans MT4R.mqh est plus que suffisant pour le moment.
La seule chose que nous aimerions voir ajoutée est l'obtention de devis par demande du processus R en contournant le terminal. Peu importe que ce soit à partir des fichiers/buffers locaux du terminal ou directement à partir du serveur d'une société de courtage. Mais ce n'est pas un souhait crucial.
Mon opinion non professionnelle est que lavariante 2 nécessite des changements cardinaux non seulement dans le terminal, mais aussi dans l'éditeur. Et je me souviens avec un frisson du dernier remaniement cardinal de l'aérogare. Cette variante peut être développée simultanément à la réalisation de la première variante et mise en œuvre lorsque la plupart des clients s'y habituent, et surtout lorsqu'ils voient les avantages de l'utilisation de ce langage. Bien entendu, l'idéal serait une intégration complète du terminal et de l'éditeur avec le langage R.
Je suis heureux que vous ayez prêté attention à cette direction.
Bonne chance
Discutons de la manière dont nous pouvons améliorer l'intégration avec R ?
Il s'agit d'un sujet intéressant qui pourrait être bien développé.
Je me suis toujours demandé pourquoi MT n'est pas inclus dans R ?
Si vous regardez les 15 ans de MT, il s'agit d'un développement évolutif, où les fonctionnalités se sont développées, mais où l'élément principal - le client - est resté le même. Il s'agit d'un pseudo-trader utilisant le TA comme outil.
1. L'inclusion de la TA dans R vous permettra de rejoindre la communauté professionnelle des traders, ces organisations qui comptent non seulement des centaines mais des milliers de traders utilisant des outils professionnels sous forme de statistiques, d'économétrie, d'apprentissage automatique .....
2. Il n'est pas indifférent que l'inclusion de la TA dans R permette d'utiliser la TA dans le processus d'enseignement. À une époque, pour enseigner les systèmes de trading mécanique en tant qu'outil, j'ai choisi Quick et Metastock, bien que je connaissais MT, mais il avait un langage qui devait être enseigné aux étudiants, et il n'était pas fourni dans le programme. L'incorporation de la TA dans R avec le langage algorithmique R comme outil d'écriture de l'EA, supprime tous les problèmes d'apprentissage - R s'apprend en dehors de la connexion aux terminaux.
La façon dont je le vois :
1. MT doit être une interface graphique en R (des exemples sont disponibles, ainsi qu'un outil pour construire de telles interfaces graphiques - shiny). Il est très souhaitable que cette interface graphique soit une copie d'un des terminaux, ou mieux des deux.
2. le langage algorithmique R. Les conseillers experts sont écrits dans le langage R, et toutes les fonctions spécifiques de négociation sont mises en œuvre sous forme de paquet. Dans ce cas, pour autant que je sache, la syntaxe d'appel des fonctions spéciales restera la même. Il s'agit d'une solution standard, car les performances seront déterminées par le langage et la qualité de l'écriture de ces fonctions, et celles-ci, étant écrites en C, et testées depuis de nombreuses années, donneront des résultats comparables à ceux des fonctions existantes. Je tiens à souligner que la vitesse d'exécution d'autres algorithmes intensifs en R sera maximale et non inférieure à leur mise en œuvre dans d'autres langages algorithmiques, puisqu'un programme en R fait généralement appel à des paquets, qui ne sont pas mis en œuvre en R pour les algorithmes intensifs. Il faut ajouter à cela que la pratique habituelle de réalisation d'algorithmes à forte intensité de calcul exige le chargement de tous les cœurs de l'ordinateur.
3. Selon mon opinion non professionnelle, les coûts de main-d'œuvre ne seront pas très élevés, étant donné la relation très amicale entre R et C et la cuisine interne, que l'on ne voit pas, peut être transférée du terminal existant au nouveau terminal.
4. la partie du terminal détenue par les courtiers reste inchangée.
DÃ?s que les paquets mentionnés sont inclus dans les miroirs CRAN, les métacquotes obtiennent une publicité étroite dans des cercles larges au lieu d'une large publicité dans des cercles étroits. Le terminal Metakvot n'aura pas de concurrents, car le seul terminal R disponible est IBrokers, qui est lié à certains courtiers payants.
Je me suis toujours demandé pourquoi MT n'est pas inclus dans R ?
Et je me suis toujours demandé pourquoi ils ont commencé à développer eux-mêmes un compilateur de type C (je veux parler des débuts de MQL4) au lieu de se procurer un compilateur C++ gratuit tout fait comme GCC.
J'ai travaillé pour de grandes entreprises occidentales et personne n'a jamais pensé à développer de toutes pièces son propre compilateur C++ pour diverses applications embarquées. Ils ont toujours pris gcc et fait un portage pour un processeur spécifique.
Et à en juger par le fait qu'un portage très réussi vers un DSP à 4 processeurs avec l'architecture NEON (jusqu'à 6 instructions par horloge par cœur) a été réalisé en 2006, ce compilateur est plutôt flexible pour l'adaptation. C'est-à-dire que le compilateur a vraiment mis en parallèle les opérations avec une moyenne de 2-4 opérations par horloge par cœur, seuls les goulots d'étranglement ont dû être optimisés sur asm.
Et maintenant, rappelons la chose merdique qu'était MQL4 jusqu'à la version 600.
Maintenant sur le sujet. Comme Renat l'a expliqué, la raison était un désir maniaque de faire un compilateur avec la protection contre les fous et les intrus. Bien que ça ne sentait même pas comme ça avant la version 600, c'était un pépin sur un pépin.
Mais, si l'on prend ses paroles au pied de la lettre, à quoi ressemble R du point de vue de la sécurité ? Je suis assez novice en la matière, je travaille avec Matlab depuis 2000, alors n'hésitez pas à m'expliquer, si vous savez quelque chose. Peut-il crypter les fichiers de sortie comme les compilateurs MQL4/5 ?
En outre, pour autant que j'aie compris, R reste un interpréteur, ce qui signifie qu'il sera encore plus lent que l'ancien MQL4 et certainement plus lent de plusieurs ordres de grandeur que le MQL5 d'aujourd'hui.
Je me suis toujours demandé pourquoi ils ont commencé à développer un compilateur de type C (je veux dire les premiers MQL4) au lieu d'utiliser un compilateur C++ libre comme GCC.
J'ai travaillé pour de grandes entreprises occidentales et personne n'a jamais pensé à développer de toutes pièces son propre compilateur C++ pour diverses applications embarquées. Ils ont toujours pris gcc et fait un portage pour un processeur spécifique.
Et à en juger par le fait qu'un portage très réussi vers un DSP à 4 processeurs avec l'architecture NEON (jusqu'à 6 instructions par horloge par cœur) a été réalisé en 2006, ce compilateur est plutôt flexible pour l'adaptation. C'est-à-dire que le compilateur a vraiment mis en parallèle les opérations avec une moyenne de 2-4 opérations par horloge par cœur, seuls les goulots d'étranglement ont dû être optimisés sur asm.
Et maintenant, rappelons la chose merdique qu'était MQL4 jusqu'à la version 600.
Maintenant sur le sujet. Comme Renat l'a expliqué, la raison était un désir maniaque de faire un compilateur avec la protection contre les fous et les intrus. Bien que ça ne sentait même pas comme ça avant la version 600, c'était un pépin sur un pépin.
Mais, si l'on prend ses paroles au pied de la lettre, à quoi ressemble R du point de vue de la sécurité ? Je suis assez novice en la matière, je travaille avec Matlab depuis 2000, alors n'hésitez pas à m'expliquer, si vous savez quelque chose. Peut-il crypter les fichiers de sortie comme les compilateurs MQL4/5 ?
De plus, pour autant que je sache, R reste un interpréteur, ce qui signifie qu'il sera encore plus lent que l'ancien MQL4 et certainement plus lent de plusieurs ordres de grandeur que le MQL5 actuel.
Lisez mes posts sur la vitesse. En bref. R est en grande partie un shell et les problèmes que vous soulevez n'ont rien à voir avec R - tous ces problèmes sont résolus dans des fonctions implémentées dans d'autres langages. Si nous parlons de cryptage, cela n'a certainement rien à voir avec la mise en œuvre prévue du terminal - vous pouvez prendre tout ce qui existe.
J'ai l'habitude de lire les messages précédents, donc le conseil n'est pas pour moi :))
**************************
Je dois essayer de traduire certains de mes programmes Matlab en R pour comparer la vitesse. Si j'arrive à trouver une solution d'ici le week-end, je le ferai et je vous le ferai savoir. Matlab est assez lent, je fais beaucoup de choses en C# ou C++ et je les intègre dans une DLL pour plus de rapidité.
R lui-même est trois fois plus retardé. C'est un interprète. Pas de problème de débogage du tout, au début j'ai commencé à utiliser un débogueur, puis il s'est avéré inutile.
En ce qui concerne la vitesse R, il y a plusieurs points à prendre en compte.
1. on peut le traduire en byte-code, mais c'est un cataplasme
**************************
Réalisez-vous que MQL4/5 sont des langages compilables ? Et que pour votre rêve d'un terminal R semblable à MT, Metakvotam devra réaliser un compilateur R ?
Mais, si l'on prend ses paroles au pied de la lettre, à quoi ressemble R du point de vue de la sécurité ? Je suis assez novice en la matière, je travaille avec Matlab depuis 2000, alors n'hésitez pas à m'expliquer, si vous savez quelque chose. Peut-il crypter les fichiers de sortie comme les compilateurs MQL4/5 ?
De plus, si je comprends bien, R reste un interprète, ce qui signifie qu'il sera encore plus lent que l'ancien MQL4 et certainement plus lent de plusieurs ordres de grandeur que le MQL5 actuel.
1. Tout est crypté de différentes manières fiables.
2) C'est fondamentalement faux. Tous les calculs lourds sont écrits en C et en parallèle.
Essayez et apprenez.
Bonne chance
Soyons réalistes.
Aujourd'hui, le terminal MT4 avec l'EDITOR fonctionne sans aucun problème (du moins pour moi). Nous avons juste besoin d'ajouter la plus petite chose pour interagir avec R.
Les développeurs ont une meilleure idée de la manière de procéder. L'essentiel est de le faire rapidement et sans casse-tête pour les utilisateurs.
Bonne chance