Simple curiosité: c'est quoi les avantages d'utliser pandas ?
Hey !
Simple curiosité: c'est quoi les avantages d'utliser pandas ?
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
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.
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.
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.
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...
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 ?
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 ?
Déjà je souhaite corriger une de tes idées. Non le dataframe n'est pas pour des "gros" jeu de données" (du moins pas les "très gros"). Il faut quand même que ça tienne en mémoire. Par exemple pour des ticks avec un historique très long ça risque quand même d'être très compliqué d'utiliser les dataframes (d'où des projets comme Blaze http://blaze.pydata.org/ quand on passe à du "big data")
Pour ce qui est des positions ouvertes que tu en ais 0, 1 ou 100 le problème reste le même.
Avoir tes positions ouvertes et les récupérer dans un DataFrame te permet par exemple de cumuler les plus (ou moins) values latentes.
Si avec l'API tu récupères dans un dataframe nommé df_pos tes positions et que les plus/ou moins values sont dans la colonne "Profit" tu peux alors faire df_pos['Profit'].cumsum() (par exemple)
Si tu as plusieurs positions pour un même actif (Hedging par exemple), tu peux les grouper par actif (si le nom de l'actif est dans la colonne "epic" par exemple à l'aide de "groupby" df.groupby("epic")["Profit"].cumsum() et tu obtiens une Pandas Series avec comme index les epic et comme valeur les profits (plus ou moins val) cumulés.
En fait, même pour des requêtes de types /markets/, renvoyer un DataFrame a un intérêt (ou du moins un dictionnaire dont certaines clés sont associées à un DataFrame) car ça permet avec le boolean indexing de filtrer sur un critère donné.
Si le résultat d'une requête de type /markets renvoie une liste de "Market data" qui est transformé par la lib en un DataFrame (nommé par exemple df_markets) tu peux ainsi faire
df_markets[df_markets["instrumentType "]=="CURRENCIES"] pour n'avoir un dataframe avec que les devises (par exemple)
Pour ce qui est des positions ouvertes que tu en ais 0, 1 ou 100 le problème reste le même.
Avoir tes positions ouvertes et les récupérer dans un DataFrame te permet par exemple de cumuler les plus (ou moins) values latentes.
Si avec l'API tu récupères dans un dataframe nommé df_pos tes positions et que les plus/ou moins values sont dans la colonne "Profit" tu peux alors faire df_pos['Profit'].cumsum() (par exemple)
Si tu as plusieurs positions pour un même actif (Hedging par exemple), tu peux les grouper par actif (si le nom de l'actif est dans la colonne "epic" par exemple à l'aide de "groupby" df.groupby("epic")["Profit"].cumsum() et tu obtiens une Pandas Series avec comme index les epic et comme valeur les profits (plus ou moins val) cumulés.
En fait, même pour des requêtes de types /markets/, renvoyer un DataFrame a un intérêt (ou du moins un dictionnaire dont certaines clés sont associées à un DataFrame) car ça permet avec le boolean indexing de filtrer sur un critère donné.
Si le résultat d'une requête de type /markets renvoie une liste de "Market data" qui est transformé par la lib en un DataFrame (nommé par exemple df_markets) tu peux ainsi faire
df_markets[df_markets["instrumentType "]=="CURRENCIES"] pour n'avoir un dataframe avec que les devises (par exemple)
Merci pour tes explications très très complètes.
Je comprends bien l'avantage des dataframes maintenant, tu m'as convaincu
Seul point négatif selon moi: il me semble que la lib panda n'est pas livré avec python à moins d'utiliser une distribution type Canopy/anaconda, pour faire un SDK "grand public" ça peut poser problème... ou pas
Merci encore
Je comprends bien l'avantage des dataframes maintenant, tu m'as convaincu
Seul point négatif selon moi: il me semble que la lib panda n'est pas livré avec python à moins d'utiliser une distribution type Canopy/anaconda, pour faire un SDK "grand public" ça peut poser problème... ou pas
Merci encore
Non il FAUT utiliser une distribution scientifique de Python (surtout si on veut faire du trading donc de l'analyse de données
Je conseille Anaconda car tu peux facilement switcher entre Python 2 et Python 3. De plus Continuum soutient beaucoup l'écosystème scientifique de Python (PyData, ...)
Le projet avec l'API Stream d'ig tourne (chez moi) désormais en Python 2 et Python 3.
Il faudrait que Weswit (qui développe Lightstreamer accepte un Pull Request pour faire de https://github.com/Weswit/Lightstreamer-example-StockList-client-python une bibliothèque et pas un simple exemple)
https://github.com/Weswit/Lightstreamer-example-StockList-client-python/pull/6
S'il ne le fait pas je forkerai pour avoir donc une blibliothèque client Lightstreamer Python
ça devrait permettre de virer igls.py qui ne tourne pas avec Python 3 et qui me semble bien complexe pour pas grand chose
Et ça donne ça au final...
https://github.com/ig-python/ig-markets-stream-api-python-library/issues/10
Et lorsqu'on s'abonne à deux actifs tout arrive bien dans la même fonction
voir on_price_update
où on récupère l'identifiant de l'actif (item_update["name"])
mais aussi les prix *item_update["values"]["BID"] par exemple
Je conseille d'utiliser Python 3 par ce que c'est plus propre (gestion de l'unicode notamment).
Et avoir un environnement secondaire en Python 2 que l'on crée via
conda create -n py2 python=2.7 anaconda
on peut basculer sur Python 2 via
source activate py2
puis revenir en Python 3 via
source desactivate
Je conseille Anaconda car tu peux facilement switcher entre Python 2 et Python 3. De plus Continuum soutient beaucoup l'écosystème scientifique de Python (PyData, ...)
Le projet avec l'API Stream d'ig tourne (chez moi) désormais en Python 2 et Python 3.
Il faudrait que Weswit (qui développe Lightstreamer accepte un Pull Request pour faire de https://github.com/Weswit/Lightstreamer-example-StockList-client-python une bibliothèque et pas un simple exemple)
https://github.com/Weswit/Lightstreamer-example-StockList-client-python/pull/6
S'il ne le fait pas je forkerai pour avoir donc une blibliothèque client Lightstreamer Python
ça devrait permettre de virer igls.py qui ne tourne pas avec Python 3 et qui me semble bien complexe pour pas grand chose
Et ça donne ça au final...
https://github.com/ig-python/ig-markets-stream-api-python-library/issues/10
Et lorsqu'on s'abonne à deux actifs tout arrive bien dans la même fonction
voir on_price_update
où on récupère l'identifiant de l'actif (item_update["name"])
mais aussi les prix *item_update["values"]["BID"] par exemple
Je conseille d'utiliser Python 3 par ce que c'est plus propre (gestion de l'unicode notamment).
Et avoir un environnement secondaire en Python 2 que l'on crée via
conda create -n py2 python=2.7 anaconda
on peut basculer sur Python 2 via
source activate py2
puis revenir en Python 3 via
source desactivate
Ah oui ce serait pas mal comme évolution.
As-tu testé combien de sous-jacent peuvent être souscrits dans une seule Table LS ?
As-tu testé combien de sous-jacent peuvent être souscrits dans une seule Table LS ?
Non je n'ai pas testé ça
Mouais enfin là tu y vas un peu fort je trouve. Pour faire toute les variantes de soft de trading ... les limitations aux-quelles nous avons du fair face n'était pas tellement dans le traitement de donnée mais plutot dans la bonne interaction avec les serveurs d'IG.FemtoTrader a écrit :Non il FAUT utiliser une distribution scientifique de Python (surtout si on veut faire du trading donc de l'analyse de données ...
Peut-être que le programme de Béni qui fait de l'analyse est plus enclins à utiliser ce genre de distribution.
bonjour
sans parler de compatible ou pas avec python 3
je ne comprends pas la difference avec ce qu'il y a actuellement, aujourd'hui si on souscrit a plusieurs actifs tout arrive dans la meme fonction, avec l'identifiant et les data demandes non ? Le resultat est le meme
Les dataframes (que je ne connais pas du tout
) sont peut etre plus parlant mais en terme de performace qu'est ce que ca donne ?
si on veut pouvoir reagir au tick par tick, il faut pouvoir finir son cycle de calcul entre 2 ticks et souvent la lisibilite/facilite ne va pas de pair avec la rapidite ... pour optimiser mon code, suivant les situations je suis avec des listes/dict ou des tableaux numpy (par ex perf de la fonction min en fonction de la taille des tableaux)
sans parler de compatible ou pas avec python 3
je ne comprends pas la difference avec ce qu'il y a actuellement, aujourd'hui si on souscrit a plusieurs actifs tout arrive dans la meme fonction, avec l'identifiant et les data demandes non ? Le resultat est le meme
Les dataframes (que je ne connais pas du tout
si on veut pouvoir reagir au tick par tick, il faut pouvoir finir son cycle de calcul entre 2 ticks et souvent la lisibilite/facilite ne va pas de pair avec la rapidite ... pour optimiser mon code, suivant les situations je suis avec des listes/dict ou des tableaux numpy (par ex perf de la fonction min en fonction de la taille des tableaux)
Non,
aujourd'hui tu as un thread par table
avec la syntaxe de Femto, tu as X epic dans un thraed
aujourd'hui tu as un thread par table
avec la syntaxe de Femto, tu as X epic dans un thraed
de mémoire on récupérait aussi avec igls les données sont la forme d'une liste
ici ça arrive sous la forme d'un dictionnaire. C'est plus facilement pour savoir qui est qui.
ici ça arrive sous la forme d'un dictionnaire. C'est plus facilement pour savoir qui est qui.
Falex> Non je ne pense pas, reprends les syntaxes sur l'autre file (script-api-ig-stream-rest-t10091-20.html) ou simplement dans la nouvelle version de la L3 (fait un print au debut de priceUpdate), je pensais aussi qu'on "ecrasait" l'ancienne table mais en fait non.
Dans igls en fait il ajoute ta nouvelle table a la liste interne a igls des tables a updater mais les anciennes ne sont pas detruites ( la fonction delete d'igls n'est jamais appelee)
Tu commences avec un epic mais quand tu changes d'epic tu recois les deux et ainsi de suite au fur et a mesure que tu changes d'epic
(je voulais te le signaler hier mais pas je n'ai eu le temps)
Dans igls en fait il ajoute ta nouvelle table a la liste interne a igls des tables a updater mais les anciennes ne sont pas detruites ( la fonction delete d'igls n'est jamais appelee)
Tu commences avec un epic mais quand tu changes d'epic tu recois les deux et ainsi de suite au fur et a mesure que tu changes d'epic
(je voulais te le signaler hier mais pas je n'ai eu le temps)
Sujets similaires
ig rest api - heure des ouvertures et clotures quotidiennes
par falex » 22 avr. 2015 14:50 (3 Réponses)
par falex » 22 avr. 2015 14:50 (3 Réponses)
clarification signification "#" et "" dans les flux stream
par musicae » 23 sept. 2016 15:01 (3 Réponses)
par musicae » 23 sept. 2016 15:01 (3 Réponses)
Trader au Stream Deck avec ProRealTime : une révolution
Fichier(s) joint(s) par Benoist Rousseau » 04 déc. 2019 12:00 (75 Réponses)
Fichier(s) joint(s) par Benoist Rousseau » 04 déc. 2019 12:00 (75 Réponses)
