kmcintyre Elite    Posts: 890 Joined: 10/11/2012 Location: Portland, OR  User Profile | I was a bit terse in my last post. I don't want to beat this horse to death (maybe I do...) but here's what I think should be done. 1) Fix the existing "Max exposure % per symbol" logic. I believe the root of the problem is that logic in OV reduces the size of trades to meet this setting. The last trade to the bar gets whacked down to the remaining percentage for that symbol. Why is that bad? When Nirvana creates strategies it does extensive testing. Part of that testing appears to be what SIZE trades should be taken. Hence the "Average Alloc per Trade" and "Trade %" stats on the Strategy and Strategies pages, respectively. When an OV user creates portfolios and accounts, she sets an "Alloc %" for each strategy. (Perhaps through inheritance, but ultimately each strategy is assigned an allocation strength.) All the research the OV user performs to select the components of said account is predicated upon both the Strategy "Average Allocation Per Trade" (aka "Trade%" in concert with the weightings placed at the strategy and portfolio level. For a bit of "quick and easy" logic (Max Exposure % Per Symbol) to disregard trade size information and (arbitrarily) whack trades down to silly allocation levels is wrong. IMO "Maximum Exposure % Per Symbol" should only allow trades to pass if the ENTIRE trade can be purchased. Fixing this should eliminate silly sized trades. (And hence obviate the need for even more "quick and easy" logic to mask the effects of the existing "quick and easy" logic.) 2) Make sure the trade size calculator is working properly. If you will recall, the beta group (me) had numerous discussions about the way the trade size calculator (inherited from OT) needed to work. The legacy code calculated trade sizes based on remaining buying power, versus the actual account equity. Basing trade sizes on buying power caused trades to become smaller and smaller as the account became more and more invested. This allowed silly small trades to be taken when the account was near fully invested. (This is a particularly bad thing to do if trading RTM strategies which expect tiny % returns per trade, and hence can't cover the commission costs.) I believe (after much discussion, coding and testing) Nirvana fixed this issue by using account equity x (Account Settings | Buying Power %) to determine trade sizes. (I still contend trade sizes should only be calculated on account equity, without regard to margin...) If this logic is broken (again), fit it. And to reiterate, Maximum Exposure % Per Symbol logic should honor the trade size calculator, and not arbitrarily whack the size of the last trade to the bar for said symbol. And it is wrong (INHO) to and another layer of "quick and easy" code to mask logic errors that exist elsewhere in OV/TP. 3) If anything, add trade size limits at the Strategy level. Minimum trade sizes are required because the profit potential of the trade must exceed the cost of placing the trade in order for a trade to make money. Hence minimum trade size needs to be a function of profit expectancy of the trade, expressed in $s. Different strategies will have different % profit per trade expectations. Hence the size of trade required to achieve a specific minimum $ profit target will vary between strategies. Hence the place to enforce minimum trade sizes is at the Strategy level, and should be specified as a minimum $ trade size (predicated upon the commission costs). (I'd be fine with "Minimum trade size | Expected Profit = X x Commission" too...) Again, for an Account level "Maximum Exposure % Per Symbol" to ignore such trade instructions (if and when implemented) and arbitrarily whack the size of a trade is wrong. Adding logic to mask the effects of said whacking is not the solution. (I contend it would be a bad thing in the long run...) In summary, the issue of silly small trades is a symptom of anomalies in the existing code base. If those anomalies are not fixed they will fester and ultimately harm attempts to add good and significant logic to OV/TP. Cluttering the UI with every possible setting imaginable and throwing "quick and easy" logic at the wall to see what sticks is seldom the solution to elegant software. Fixing the problem right the first time leads to a solid foundation upon which enhancements can be built. Patches and bandaids lead to an unstable product that breaks in mysterious ways every time the code is touched. End of rant. Peace Keith [Edited by kmcintyre on 8/17/2013 9:13 AM] | |
