SmartQuant Discussion

Automated Quantitative Strategy Development, SmartQuant Product Discussion and Technical Support Forums
It is currently Sat Dec 14, 2019 3:57 am

All times are UTC + 3 hours




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Sep 18, 2009 9:46 am 
Offline

Joined: Wed Sep 16, 2009 6:26 pm
Posts: 27
I was wondering if it is possible to fetch what type of order has gone through. TT outputs type of order (whether it was Buy or Sell) but SmartQuant seems not recognizing it.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 18, 2009 9:54 am 
Offline

Joined: Tue Aug 05, 2003 3:43 pm
Posts: 6816
There always is a buyer and a seller in a trade, so I guess there can't be "buy" or "sell" trade.

Regards,
Anton


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 18, 2009 10:08 am 
Offline

Joined: Wed Sep 16, 2009 6:26 pm
Posts: 27
Of course there is always a buyer and a seller, but one of them is showing the offer (or bid) and the other one takes the offer (or bid) hitting the market. TT on its time and sales indicates which of them was market buy and which was market sell. That would be great if you could include it in SmartQuant...
Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 18, 2009 11:46 am 
Offline
Site Admin

Joined: Thu Jul 17, 2003 10:39 am
Posts: 1478
Hi,

Which TT plugin do you mean? TT API or TT FIX?

Regards,
Alex

_________________
SmartQuant Development Team


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 18, 2009 2:17 pm 
Offline

Joined: Wed Sep 16, 2009 6:26 pm
Posts: 27
I am using TT API. Is there any difference? And by a difference I mean class implementation...


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 4:54 pm 
Offline

Joined: Wed May 11, 2011 5:56 pm
Posts: 13
Guys,
any news about this? It's still a foundamental aspect to determinw in which direction the market is moving.

Regards


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 5:00 pm 
Offline

Joined: Tue Aug 05, 2003 3:43 pm
Posts: 6816
I guess you don't mean an order, you mean a trade record (OQ Trade object), right?


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 5:19 pm 
Offline

Joined: Wed May 11, 2011 5:56 pm
Posts: 13
Anton,
TT has a box called Time & Sales, which in the API returns the object Trade. That object contains also the "direction" of the trade, which can either be buy or sell. As a trader I can tell you that is very usefull to have a clear view regards the market, if people are hitting the bid or lifting the offer. I've seen an implementation on TT API developer's forum, and I think it shouldn't be too complicated to have also this property in OQ.

Regards


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 5:29 pm 
Offline

Joined: Tue Aug 05, 2003 3:43 pm
Posts: 6816
Yes, I know, but the problem is that the trade object in the underlying framework doesn/t have this field and to add it we need to update the entire data propagation / storage chain.

We are currently working on a new version of the framework. Perhaps we should include more information into the trade (time and sales) record. On the other hand it's also important to keep this object as lightweighted as possible. This affects memory requirements, backtesting speeds, latency, etc. If you look at the raw TAQ (NYSE) time and sales data, you will see that on e trade record has tens of different fields apart from price and size. Should we reserve space for all of them?

Cheers,
Anton


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 5:35 pm 
Offline

Joined: Wed May 11, 2011 5:56 pm
Posts: 13
Dr. Anton Fokin wrote:
Yes, I know, but the problem is that the trade object in the underlying framework doesn/t have this field and to add it we need to update the entire data propagation / storage chain.

We are currently working on a new version of the framework. Perhaps we should include more information into the trade (time and sales) record. On the other hand it's also important to have this object as lightweight as possible. This affects memory requirements, backtesting speeds, latency, etc. If you look at the raw TAQ (NYSE) time and sales data, you will see that on e trade record has tens of different fields apart from price and size. Should we reserve space for all of them?

Cheers,
Anton


Anton,
speed is a very important characteristic of OQ, and it shouldn't be changed. Anyway you can simply leave the Trade category as it is, while creating a new richer "Trade" category, called ie. Time&Sales, SuperTrade or whatever, which can handle more datas, like you said for the NYSE datas. In this way you can preserve speed, but giving the opportunity for people less relaiant on speed a way to trade that kind of datas.

Kind Regards


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 5:37 pm 
Offline

Joined: Wed May 11, 2011 5:56 pm
Posts: 13
MarySun wrote:
Anton,
TT has a box called Time & Sales, which in the API returns the object Trade. That object contains also the "direction" of the trade, which can either be buy or sell. As a trader I can tell you that is very usefull to have a clear view regards the market, if people are hitting the bid or lifting the offer. I've seen an implementation on TT API developer's forum, and I think it shouldn't be too complicated to have also this property in OQ.

Regards


/// <summary>
/// This function is called when an instrument udpate
/// occurs, however, this data is not coalesced.
///
/// NOTE: Fired when DeliverAllPriceUpdates is enabled.
/// </summary>
/// <param name="pNotify">TTInstrNotify object</param>
private void m_TTInstrNotify_OnPriceListUpdate(XTAPI.TTInstrNotify pNotify)
{
try
{
if (pNotify != null)
{
//Set variables
string sMsg = null;
string direction = null;
double ltp = 0.0f;
int ltq = 0;

foreach (XTAPI.ITTPriceUpdate priceUpdate in pNotify.PriceList)
{

//Loop through PriceEntries in PriceUpdate
foreach (XTAPI.ITTPriceEntry priceEntry in priceUpdate)
{
switch (priceEntry.PriceID)
{
//Calculate Last Traded Price
case XTAPI.enumPriceID.ttLastTradedPrice:
ltp = priceEntry.toDouble();
break;
//Calculate Last Traded Quantity
case XTAPI.enumPriceID.ttLastTradedQty:
ltq = (int)priceEntry.toDouble();
break;
//Calculate Hit or Take
case XTAPI.enumPriceID.ttHitTake:

if (priceEntry.toDouble() == Convert.ToDouble(XTAPI.enumTradeIndicator.TRADE_INDICATOR_HIT))
{
direction = "Hit"; //Sell
}
else if (priceEntry.toDouble() == Convert.ToDouble(XTAPI.enumTradeIndicator.TRADE_INDICATOR_TAKE))
{
direction = "Take"; //Buy
}
else if (priceEntry.toDouble() == Convert.ToDouble(XTAPI.enumTradeIndicator.TRADE_INDICATOR_UNKNOWN))
{
direction = "Indeterminate"; //Indeterminate
}
break;
}
}

//Get timestamp of PriceUpdate
string timestamp = priceUpdate.TimeStamp.Substring(0,8);


//Write message
sMsg = m_Cnt + "," + timestamp + "," + priceUpdate.Instrument.Exchange + "," + priceUpdate.Instrument.Product + "," + priceUpdate.Instrument.get_Get("Expiry") + "," + direction + "," + ltp + "," + ltq;

//Add sMsg to ListBox
lboPriceList.Items.Add(sMsg);
//Increase count
m_Cnt = m_Cnt + 1;
}
}
}
catch (Exception ex)
{
Console.WriteLine(ex.Message + "," + ex.StackTrace);
}
}

This is the TT Code, as you can see is just a comparison between quotes side and where the trade hit the book. It shouldn't be so difficult to implement. Anyway I can write a DLL to add this feature if anyone is interested!

Regards


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 5:49 pm 
Offline

Joined: Tue Aug 05, 2003 3:43 pm
Posts: 6816
Yes, it's easy to get. The problem is that we have no place to put this information in ...


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 5:52 pm 
Offline

Joined: Wed May 11, 2011 5:56 pm
Posts: 13
Dr. Anton Fokin wrote:
Yes, it's easy to get. The problem is that we have no place to put this information in ...


Don't worry I've got an idea. I'm writing a DLL with an integrated small database (OQ Stile!) to store those informations. Thanks for the suggestion, I will eventually post my results if anyone is interested!

Regards


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 6:05 pm 
Offline

Joined: Tue Aug 05, 2003 3:43 pm
Posts: 6816
If you write a custom plugin for TT API (we can give you the code for the built-in plugin, but I doubt it would help since our plugin is developed for the underlying framework, i.e. it's not derived from OQ UserProvider), you can probably use a sign at Trade.Price / Size to send trade direction alone with trade data... Negative size is take, positive is hit... Just an idea...


Top
 Profile  
 
PostPosted: Sun Jun 19, 2011 6:26 pm 
Offline

Joined: Wed May 11, 2011 5:56 pm
Posts: 13
Dr. Anton Fokin wrote:
If you write a custom plugin for TT API (we can give you the code for the built-in plugin, but I doubt it would help since our plugin is developed for the underlying framework, i.e. it's not derived from OQ UserProvider), you can probably use a sign at Trade.Price / Size to send trade direction alone with trade data... Negative size is take, positive is hit... Just an idea...


Good suggestion Anton!! Well, simply on your plugin, once I have EmitTrade() trigger on a trade event I can add this code as part of the process, invoking another event, ie. OnErrorEvent with a custom error ID to store the trade direction! Or is that possible to add an event to OQ? In that case it would be much simpler!

Btw do you think is possible to add this feature also for the IB plugin? As I don't know too well IB API's I would like to know from your previous experiences.

Regards


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC + 3 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group