trading
in [Mathematica]
|
Prev: Subscript in AxesLabel
Next: Assign value to variable
From: Jimmy S. Lim on 24 Jul 2010 05:06 Hi, I'd like to be able to connect to live data feed for charting and analytics + Order routing(trade futures and possibly become an Introducing Broker) but have no idea how to implement these. i also just bought mathematica recently and so wish to obtain some suggestions from you guys. is this task something to huge for a single person to undertake, in which case, would appreciate to be pointed to the right direction. Joel posted rithmic, i'm not quite sure i understand how this works... thanks in advance. jim
From: Chris Degnen on 25 Jul 2010 02:00 On Jul 24, 10:06 am, "Jimmy S. Lim" <onward...(a)gmail.com> wrote: > Hi, > I'd like to be able to connect to live data feed for charting and analytics > + Order routing(trade futures and possibly become an Introducing Broker) but > have no idea how to implement these. i also just bought mathematica recently > and so wish to obtain some suggestions from you guys. > > is this task something to huge for a single person to undertake, in which > case, would appreciate to be pointed to the right direction. Joel posted > rithmic, i'm not quite sure i understand how this works... > > thanks in advance. > > jim Some links that may be of interest: StockCharts http://library.wolfram.com/infocenter/MathSource/7526/ Bloomberg http://library.wolfram.com/infocenter/MathSource/7357/ (commercial) DDFLink http://forums.wolfram.com/mathgroup/archive/2010/Feb/msg00531.html
From: Andreas on 26 Jul 2010 07:23 Jimmy, It depends. Our hedge fund uses Mathematica as our core analytics engine in a fully automated trading environment, so yes one can lots with it, but it also depends upon what you want to do. >From our point of view one needs 3 basic things to trade: 1. market data 2. analytics 3. trade execution Let's look at each of them briefly. Market data, while Mathematica has the ability to scrape data from free online sources, one has to evaluate their own analytics, time sensitivity, and strategy to determine whether they can productively use this kind of data. It typically has significant drawbacks including errors and delays. These services typically get data directly from exchanges or third party suppliers that don't have the redundancy and error correction infrastructure of the 3 high end data suppliers. The same drawbacks come with data from online brokerages (i.e. Interactive Brokers has some of the most robust technology, but they don't have Bloomberg's or Reuter's error correction). So, if you need intraday day data you may need to pay for it and it means dealing with one of the vendors' API's and probably MathLink or J/Link to access the data and get it into Mathematica. I'll leave aside a discussion of whether you need a database or whether you employ some RAM based persistence scheme (perhaps the fastest solution). In our case we trade intraday, but we don't employ high-frequency trading approaches. This led us to the decision to use Reuters. They have a rather antiquated, but robust data feed. I also recommend that you evaluate the technical and operational redundancy of any data supplier, all have frightening single points of failure in their infrastructures. It only makes sense to use Bloomberg if you already pay for and use their terminal service, very pricey otherwise. You also need to make decisions about continuous and/or consolidated data feeds, they both have their strengths and weaknesses, you just need to balance them relative to your approach. We have a relatively simple Java process which captures data from a Reuters API, all of the rest of our code resides in Mathematica. Analytics -- Here Mathematica soars above anything else I've seen. We use it for R&D, and rely heavily on its parallel processing capabilities in our production trading environment. Fast, elegant, smart. Nothing else comes close. Trade execution -- Once you generate trading orders you need to get them to an execution platform. This typically involves another API. This could look as simple as manual entry into an online trading system if your approach can live with it. Probably better to connect through an online broker's API. Interactive Brokers again has a useful API for this. Goldman does too with its Redi system, and if you don't meet Goldman's assets under management requirements some mini-prime brokers like Wall Street Access can provide access to Goldman's platform through one of their programs. e-Trade? Maybe. I'd approach all retail platforms suspiciously. The best solution involves connecting directly with one or more brokers/exchanges via the financial information exchange (FIX) protocol. You certify and run your own FIX server, generate your orders in the FIX format directly out of Mathematica, basically creating your own Mathematica to Fix API. Setting up and maintaining a FIX box takes some infrastructure knowledge. One needs to establish 2 or more VPN tunnels to the broker's/exchange's corresponding box, typically one for outgoing and one for incoming messages. Nothing particularly hard about this, it just takes time. Clearly Wolfram has an interest in supplying tools to this market and I believe that wide spread adoption of Mathematica in the industry could help address some systemic risk due to frail platforms for models (way to much of the industry still runs on Excel spreadsheets). To my mind, rather than pack the application with more stock charting options and financial engineering tools for pricing derivatives and such (almost all of which proceed from terribly flawed assumptions) it would serve them and the industry better to construct: 1. marketData/Link - A universal professional market data connector - something like DB/Link, but for market data streams rather than database connectivity. They could easily adapt it to the 3 major suppliers, and directly to exchanges. The interface could have subscription credentials, where required for paid services. 2. FIX/Link API. These two pieces would then allow users of Mathematica to focus on their analytics and trading strategies. (Mike H. hope you're listening ;-) Just my 2 cents. Best, A
From: Jimmy S. Lim on 1 Aug 2010 04:55 Hello Andreas thanks so much for your insights. and i totally agree with you and hope Wolfram is listening regarding your suggestions. It is exactly what i'm looking for. although i'm a relative newbie to this, i'd like to be able to link to the Singapore exchange, that's why a universal market data link is what i'm looking for. Chris, thanks too for the links. Jim On Mon, Jul 26, 2010 at 1:39 PM, Andreas <aagas(a)ix.netcom.com> wrote: > Jimmy, > > It depends. Our hedge fund uses Mathematica as our core analytics > engine in a fully automated trading environment, so yes one can lots > with it, but it also depends upon what you want to do. > > >From our point of view one needs 3 basic things to trade: > > 1. market data > 2. analytics > 3. trade execution > > Let's look at each of them briefly. > > Market data, while Mathematica has the ability to scrape data from > free online sources, one has to evaluate their own analytics, time > sensitivity, and strategy to determine whether they can productively > use this kind of data. It typically has significant drawbacks > including errors and delays. These services typically get data > directly from exchanges or third party suppliers that don't have the > redundancy and error correction infrastructure of the 3 high end data > suppliers. The same drawbacks come with data from online brokerages > (i.e. Interactive Brokers has some of the most robust technology, but > they don't have Bloomberg's or Reuter's error correction). So, if you > need intraday day data you may need to pay for it and it means dealing > with one of the vendors' API's and probably MathLink or J/Link to > access the data and get it into Mathematica. I'll leave aside a > discussion of whether you need a database or whether you employ some > RAM based persistence scheme (perhaps the fastest solution). > > In our case we trade intraday, but we don't employ high-frequency > trading approaches. This led us to the decision to use Reuters. They > have a rather antiquated, but robust data feed. I also recommend that > you evaluate the technical and operational redundancy of any data > supplier, all have frightening single points of failure in their > infrastructures. > > It only makes sense to use Bloomberg if you already pay for and use > their terminal service, very pricey otherwise. You also need to make > decisions about continuous and/or consolidated data feeds, they both > have their strengths and weaknesses, you just need to balance them > relative to your approach. We have a relatively simple Java process > which captures data from a Reuters API, all of the rest of our code > resides in Mathematica. > > Analytics -- Here Mathematica soars above anything else I've seen. We > use it for R&D, and rely heavily on its parallel processing > capabilities in our production trading environment. Fast, elegant, > smart. Nothing else comes close. > > Trade execution -- Once you generate trading orders you need to get > them to an execution platform. This typically involves another API. > This could look as simple as manual entry into an online trading > system if your approach can live with it. Probably better to connect > through an online broker's API. Interactive Brokers again has a > useful API for this. Goldman does too with its Redi system, and if > you don't meet Goldman's assets under management requirements some > mini-prime brokers like Wall Street Access can provide access to > Goldman's platform through one of their programs. e-Trade? Maybe. > I'd approach all retail platforms suspiciously. > > The best solution involves connecting directly with one or more > brokers/exchanges via the financial information exchange (FIX) > protocol. You certify and run your own FIX server, generate your > orders in the FIX format directly out of Mathematica, basically > creating your own Mathematica to Fix API. Setting up and maintaining > a FIX box takes some infrastructure knowledge. One needs to establish > 2 or more VPN tunnels to the broker's/exchange's corresponding box, > typically one for outgoing and one for incoming messages. Nothing > particularly hard about this, it just takes time. > > Clearly Wolfram has an interest in supplying tools to this market and > I believe that wide spread adoption of Mathematica in the industry > could help address some systemic risk due to frail platforms for > models (way to much of the industry still runs on Excel spreadsheets). > > To my mind, rather than pack the application with more stock charting > options and financial engineering tools for pricing derivatives and > such (almost all of which proceed from terribly flawed assumptions) it > would serve them and the industry better to construct: > > 1. marketData/Link - A universal professional market data connector - > something like DB/Link, but for market data streams rather than > database connectivity. They could easily adapt it to the 3 major > suppliers, and directly to exchanges. The interface could have > subscription credentials, where required for paid services. > > 2. FIX/Link API. > > These two pieces would then allow users of Mathematica to focus on > their analytics and trading strategies. > > (Mike H. hope you're listening ;-) > > Just my 2 cents. > > Best, > A > > > > > > -- cheers! Jim
|
Pages: 1 Prev: Subscript in AxesLabel Next: Assign value to variable |