Collaboration

[januson]

Hi there

Finally I've built the engine that receives and process ticks, I've created the compression logic for the different frequencies.

A frequency can be of either Time, Volume, Ticks or Range.

The system is 100% event driven and the architecture is based at a service bus for transportation between UI, Core and TickEngine.

I will not go into too much details right now.. not that anything is secret, but just because the project is driven in a very agile way.

Anyway....
Here goes the Strategy:
************************************************************
public class BuySMACrosses: TickEngine.Base.StrategyRunner
{
ICompression compression;
List<ISeries> barBuffer;
public override void StartUp()
{

-> Look at the compression... 100% fully flexible nice ehh...
this.compression = base.CompressionEngine<Time>(TimeSpan.FromSeconds(60));

-> we could easily use another compression.. ie.
this.compressionWith10Min = base.CompressionEngine<Time>(TimeSpan.FromMinutes(10));

-> or maybe...
this.compressionWithTick = base.CompressionEngine<Tick>(100);

-> these compressions can freely be mixed in the indicators and signals...

-> Just event subscriptions
this.compression.OHLCUpdated += new EventHandler(compression_OHLCUpdated);

this.compression.Close.CurrentChanged += new EventHandler(Close_CurrentChanged);

-> A barbuffer... not sure exactly what this is needed for. Maybe this should be handled from the initiator of this Strategy. I think it could be clever to share a bar buffer between different strategies...

Opinions?
this.barBuffer = new List<Common.Entities.ISeries>();

-> Some indicator... that uses the compression.Low, in this example 1 minut Bar Low
-> We can add as many as we like, based at different compressions

var sma9 = new Ballonprofit.Indicators.Trend.SMA(compression.Low, 9);
sma9.CurrentChanged += new EventHandler(sma9_OnChange);
}

void compression_OHLCUpdated(object sender, EventArgs e)
{
throw new NotImplementedException();
}

void Close_CurrentChanged(object sender, EventArgs e)
{
this.barBuffer.Add( this.compression.Close ); // add maybe to a shared buffer
}

void sma9_OnChange(object sender, EventArgs e)
{
System.Diagnostics.Trace.WriteLine("sma9_OnChange");
}

//why should we even want to do something like this?. Well I built it, but very influenced by people and their obsession with "do something on a tick"-thing
protected override void OnTick(Common.Entities.ITickData tickData)
{
System.Diagnostics.Trace.WriteLine("OnTick recieved");
}

}

************************************************************

I would like to discuss my approach to the subject how intuitive this is?, any pitfalls etc?

Something I do have in mind, but not yet developed is the different signals.. crossover, crossunder etc. could be done like the following:

var cross = sma9.Crosses(sma21);
cross.Signal += (s, e) => e.Symbol.PositionOpen(1);



What do you think?

 

[januson]

Nobody thinks anything hmmm...

I'm sorry I don't have the interest or for that sake manner to blow this up into tremendous dimensions as TickZoom was presented for the monkeys, but at least my presentation is at a technical level so everybody should be able too see that it's not bullshit.

 

[byteme]

Quote from januson:

What do you think?

Random thoughts:

who are you building it for? Yourself or for other people?

What is the USP over other open source projects like TradeLink or ActiveQuant?

How are you going to configure which instruments a strategy is driven by? Can it support multiple-instruments? If so, onTick needs to indicate which instrument the tick is for right?

The approach looks fine to me so far...but can't see the advantage over other frameworks so far...

If your strategy is going to be comprised of event handler delegates rather than implementing some sort of strategy interface then I can perhaps see how it could be more flexible than other frameworks out there at the cost of being less accessible to non-programmers. It depends what you're aiming for.

What happens when you have two strategies that need to run off the same compression for the same instrument? Do they duplicate the compression?

Personally, I prefer an architecture where the "compression"/bar factory/tick compressor sits in front of the strategy rather than being a composite of the strategy i.e. so that the strategy receives a stream of bars, ticks and other events from outside itself.

However, this preference could purely be a result of familiarity.

 

[januson]

Hi byteme,

thank you...

Well.. I'm building it for myself as a start, if the project succeeds I will release it I have no intention to aim it at non-programmers, but it could be excellent if it was intuitive enough.
One could always build a "builder" so that non-programmers could create a strategy

My thoughts was that one strategy supports one instrument, not sure why I should support more? Are you thinking about pairtrading? hmmm

The issue about duplicate compression hit me in the face yesterday, I was thinking about injecting it instead.... from a performance view it will be good

The reason for building my own is that none of the available applications work as they should imho. One is darn slow, one is bloated and another is very non-intuitive etc..

I've no experience in using a trading API to send orders, but I imagine it is fairly easy.. place order, wait for fill or eventually cancel operation.

 

[byteme]

There are many use cases where there is a need to monitor 2 or more instruments for a given strategy. Pairs trading and statistical arbitrage is just one example. Also, consider the scenario where you want to monitor the same instrument but in different timeframes...

All of this points to potentially needing to support one or more compression per strategy - either for the same instrument or for different ones. It might be worth considering support for multi-instruments more seriously before you move on rather than crudely bolting it on at a later date (NeoTicker circa 7 years ago, comes to mind)

On the topic of injecting the compression, i'm not sure how that solves the duplicate issue unless the container/factory is smart enough to hand out the same instance when required.

In principle yes, trade execution is also pretty straightforward. Your strategy will of course have to be notified (presumably with similar event handlers) when executions occur and also when orders are being worked. Partial fills are another use case that needs to be considered.

Things become interesting when you have two strategies trading the same instrument.

Consider the extreme example where one strategy goes long and the other goes short on the same instrument...how are the executions and positions reported to the strategies? Will your order manager be sophisticated enough to deal with it?

Another use case to consider: the strategy will trade a different instrument to the one(s) it's monitoring.

How will you parametetize the instruments for a strategy to facilitate backtesting on a basket of instruments?

Lots of questions. Hope it has given you some ideas/things to think about. I haven't even got started on multi-legged instruments like option spreads or synthetic instruments like custom indexes etc.