API REST / STREAM

j'ai mis le body plus haut. ... (url : https://demo-api.ig.com/gateway/deal/positions/otc)

Là je sèche ...

J'ai également un rejet avec TakaScalper, raison : UNKNOWN

Et tout semble correct avec l'epic :

brent.png (31.6 Kio) Vu 997 fois

Effectivement la requête semble Ok par rapport à la référence.
tu postes sur la v1 ou la v2 du service ?

Sur le v2 du service, trailingStop n'est pas contraint à être différent de null mais il y a des contraintes sur la requête en elle-même. Je le renseignerai à false si v2.
J'envoie aussi mes lots en flottant ("1.0" et non "1") mais je ne pense pas que cela soit ça.

j'ai essayé V1 et V2

float ou integer même combat

J'ai fait quelques tests :
Je reproduis ton problème sur le brent 1€ : les ordres au marchés, avec ou sans stop/limite ne s'exécutent pas. L'erreur est REJECTED/UNKNOWN (en fait IG remonte plus "précisément" que "Rejeté: Cet ordre au marché ne peut être exécuté.")
Cela ne marche d'ailleurs pas non plus sur le brent en dollar sans échéance.

Par contre aucun souci pour passer des ordres au marché sur les futures du brent :

Code : #

2015-08-05 15:07:10.1879 | INFO | Creating new position request: EN.D.LCO.FWS3.IP MARKET until OCT-15 ...
2015-08-05 15:07:11.0680 | INFO | Retrieving open positions...
2015-08-05 15:07:11.3884 | INFO | Found an open position EN.D.LCO.FWS3.IP (2015/08/05 14:07:06:000)
2015-08-05 15:07:11.3884 | INFO | Retrieving open positions...OK (found 1)
2015-08-05 15:07:11.3884 | INFO | Creating new position request: EN.D.LCO.FWS3.IP MARKET until OCT-15 ...

Donc il y a bien un souci côté IG sur ce dérivé du brent sans échéance.

Oui mais le contenu est très pauvre : trois classes seulement...

Pour être franc la seule partie qui mérite un dev' externe c'et la partie lightstreamer car c'est la plus casse-bonbon, le REST(e) c'est ultra simple avec une pauve requête web et analyse de la réponse, pas besoin d'un SDK pour ça à mon humble avis.

D'ailleurs dans le dev des programmes la difficulté est plus dans la gestion de l'information que la communication avec les serveurs d'ig (sauf quand ça déc0nne bien entendu).

Personnellement je ne suis pas complètement d'accord avec vous.

Pour l'API REST ça peut être intéressant de mettre en cache les requêtes (afin d'éviter de saturer les serveurs d'ig et se faire
fermer la porte pendant un certain temps).
En Python, ça peut être sympa de renvoyer les résultats des requêtes sous forme de DataFrame Pandas (ou de Panel)...
et non sous la forme de dictionnaires, de listes, ...

donc non un SDK pour la partie REST en Python n'est à mon humble avis pas inutile.

Quel est l'intéret de mettre en cache sachant que l'on est sur de lacommunication quasi synchrone ? là ça m'échappe ???
A part éviter de faire sauter le quota de requêtes REST eventuellement ... mais dans ce cas là :
- Soit tu demandes à ig d'augmenter ton quota
- Soit ta façon d'utiliser REST dans le programme n'est pas la meilleur ...

Si tu as un script qui récupère l'historique des prix (pour faire des backtests) chaque fois que tu le (re)lances tu fais
une requête "pour rien".

Après c'est clair qu'il faut mieux stocker dans une base de données les prix et éviter de faire des requêtes.

Par contre le second point me semble plus important (récupérer des "objets" facilement utilisables comme les DataFrames)

Hey !

Simple curiosité: c'est quoi les avantages d'utliser pandas ?

Avoir des jolis tableaux pour faire des stats (cumul, max, ...), faire du rééchantillonage... En plus c'est Numpy qui est utilisé derrière donc c'est du C... c'est rapide.
Quelques bons bouquins (Python for Data Analysis de Wes McKinney, Learning Pandas de Michael Heydt et d'autres...)
Pandas ça permet d'avoir les concepts du langage R (très utilisé en économétrie, analyse stat...) dans un language plus généraliste qu'est Python

Alalalala R ... c'est le truc qui me fait mourir de rire car les différentes implémentation sont incapable de tenir la charge sur du bigdata .... là ou python/perl seront certainement plus à l'aise (oups je ferme la parenthèse)

Pour Python Pandas il y a Blaze qui peut être sympa http://blaze.pydata.org/

Il semble que l'on puisse interfacer R avec Hadoop
https://www.packtpub.com/big-data-and-business-intelligence/big-data-analytics-r-and-hadoop

Avec Spark aussi https://spark.apache.org/docs/latest/sparkr.html
donc il ne faut quand même pas dénigrer non plus

Par contre je ne suis pas fan de la syntaxe de R... Python est quand même plus "humainement" compréhensible.

L'intérêt de R c'est quand même la communauté autour, les gens qui l'utilise, etc... (plus que le langage en lui même
et ça compte quand même un peu !) car il y a du coup une masse de paquets spécialisés que l'on ne trouve pas nécessairement
ailleurs.

Bonjour FemtoTrader.
Puisque tu sembles bien discuter avec nos gars, il faudrait que tu te présentes afin qu'on sache un peu qui tu es.
La présentation est une étape obligatoire avant de poster.
Merci de respecter la nétiquette en te présentant ici:
presentation-des-membres.html
A tout de suite.

Bonjour Amarantine,

message reçu
ma présentation est ici femto-t10237.html

Rapide comme l'éclair! Merci Femto.

Ok merci pour la réponse.
Effectivement ça peut être intéressant pour des historiques uniquement, pour les requêtes types /markets/ ou /positions/ je vois pas trop l'intérêt...

Faire des calculs sur tes positions ouvertes pour gérer ton risque c'est quand même pas inutile, non ?

Si si carrément. En fait je me suis mal exprimé.
J'ai juste du mal a imaginé comment passer d'un JSON à un dataframe.
Pour moi le dataframe c'est pour des gros jeu de données type historique, par contre pour les positions en cours ou autres quelle est l'avantage du dataframe par apport au dictionnaire ?