Profile Picture

Making it easier to write systems (Feedback requested)

Posted By dplaisted 11 Years Ago
Posted Thursday December 06 2007
One of the things we are going to focus on in the next release of RightEdge is ease of use.  Some of the feedback we have been getting is that it can be hard to figure out how to do what you want to when writing a system, and sometimes the interfaces are outright confusing.  So we are planning on making some changes to our interfaces to make system writing easier.  Listed below is what we are thinking about, and we welcome your feedback on these changes or anything else you think could be improved.

Symbol Strategies

When writing a system, you will create a "symbol strategy" class.  One copy of this class will be created for each symbol.  Most of your system logic will probably go in this class.  Code that would previously have gone in your System's NewSymbolBar method will go in your symbol strategy's NewBar method.  This will make it much easier to store symbol-specific data: instead of having to manage a dictionary and a separate class to store this data, you can simply declare a field in the symbol strategy class.

We will make it easy to access the data you want in the symbol strategy class.  For example, there will be a Bars property which will return the list of bars for the current symbol.  So where previously you had to specify something like SymbolBars[symbol][index], you will be able to use just Bars[index].  Indicators will work the same way, and for DnD indicators we are planning on automatically creating properties for each one, so instead of Indicators["SMA50"][symbol][index], you can just use SMA50[index].

You will still be able to have a System class that there is only one copy of.  You can use it to store non symbol-specific information, or put all of your logic in it if you don't want to use a symbol strategy class.  We're also not sure that "symbol strategy" is the best name for this class, so let us know if you have a better idea!

Position Management

We are going to make it easier to open and modify positions, and to manage orders.  The OpenPosition method will return a Position object instead of ReturnValue<string>.  The ReturnValue model may be a good idea for a team of programmers, but it is confusing and hard to explain to new users who may be novice programmers.  The Position object will have an Error property which contain the error string if the OpenPosition call was not successful, and will be null if it was.

The Position class will include properties and methods that will allow you to use the Position object directly instead of having to pass the position ID to a method in the PositionManager class.  Examples of such members are CloseAtMarket(), SetProfitTarget(), SubmitOrder(), ProfitTarget, Orders, etc.  Inside a symbol strategy, you could use the following code to close all open positions for a symbol:

foreach (Position pos in OpenPositions)

The Order class will be changed in a similar manner to the Position class.  (Actually we will rename the current Order class to BrokerOrder, and write a new Order class with the functionality we want.  The BrokerOrder class will still be used by broker plugins and internally by the position manager.)

Reversing Series Order

We are not sure if we are going to make this change because it is a major change which would probably require changes to all current systems and indicators.  If we do make this change then index zero would be the most recent value for indicators, bar lists, or other series, instead of the oldest value.

Systems and indicators are constantly accessing the most recent value, or the value from n bars ago.  They rarely, if ever, care what the very first value of a series was.  So it makes a lot more sense to use Bars[0] for the current bar and Bars[1] for the previous, instead of Bars[Bars.Count - 1] and Bars[Bars.Count - 2].  We think it will be easier for new programmers to understand.

This change will also make it easier to add support for running simulations on very large data sets down the road.  Right now, if you want to run a simulation on 1 minute bars for the past 10 years, all that data has to be loaded into memory, and it may not all fit.  Eventually we would like to support loading the data on demand and releasing it once it is not needed anymore.  If your system only needs to look at the previous 200 bars, then any data prior to that can be released.  This will be easier to manage if we change the way the series are indexed.

Please let us know what you think.  All of this is subject to change of course.  While the changes we are planning are fairly major, we will leave as much of the existing functionality in place as we can.  You probably will have to make some changes to your existing systems, but we certainly don't want to force you to rewrite them entirely.


Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)Supreme Being (70,147 reputation)
Posted Friday December 07 2007
Without hesitation I fully support this. Among other benefits, it will substantially reduce 'keystrokes' which also means strategies will be easier to read and maintain. It is never better to make these kinds of changes later, so now is the time. There may be some disruption, but moving to the better thing always outweighs the temporary scramble. I'm for it.

Posted Friday December 07 2007
I am curious as to what people think specifically about the last item on the list (swapping the index). 
Posted Friday December 07 2007
All sounds good to me. I also support the last suggestion re changing the index - this is more intuitive to most people and if it helps memory usage down the track then you should do it.
Posted Friday December 07 2007
This sounds really good. Any idea when this functionality will be available?
Posted Friday December 07 2007
In 1.2.  We just released 1.1 yesterday, so I don't think we give a confident 1.2 date yet.  I would say within the next 3-4 months, roughly.

jonjin (12/7/2007)
This sounds really good. Any idea when this functionality will be available?
Posted Saturday December 08 2007
I am for all three.

Doing bars(bars.count-1) always annoyed me.

Posted Saturday December 08 2007
I'd also like to add, if there is anything else that annoys or is needlessly difficult about system writing, please let us know.  This is the stuff that we came up with based on user feedback and our own feedback.  We know some are silent unless prodded. Smile
Posted Monday December 10 2007
> index zero would be the most recent value

I just read this and - I must say - I am shocked.
While this may look easier to a novice programmer (and is the way Tradestation does it, more or less) I think it is the wrong way to go.

I am so confused right now, I have just a few quick thoughts:

* everywhere in modern programming arrays, lists and the like start at 0 and grow to positive indices, a higher number meaning something later, newer.

* At least in my head this change would cause severe chaos. For me it is quite natural to say Count-2 when I mean "yesterday".

... need to calm down and think about it ...

Our Trading System at C2: Topaz
Posted Monday December 10 2007
I had the exact same reaction when Daniel proposed it.

I'll let Daniel chime in with more details, but I found the compelling reasons to switch to make this change are:

1) You're almost always dealing with the end of the array which is a bit different than most collections.  So you're always doing something like MyCollection[MyCollection.Count - 1];  Now you can do MyCollection[0];  You want one period back, MyCollection[1];  Just a lot easier to read.

2) This makes data drop off possible (for use with massive simulations).  So if you're running a massive simulation, the system won't have to anything different.

Similar Topics

Reading This Topic

2005-2018 © RightEdge Systems