With the new "arrow" information I was able to find and fix the churning bug. It was related to the minimum order size. Previously if the algorithm suggested a trade below the minimum order size the application would up the trade size to the minimum. This was causing lots of "minimum order trades" up and down the trendline thereby diluting profits (and losses).
I have it bailing out now at that point and saying "There isn't enough momentum to trade at this time.", which is the truth.
Running it now, will report my results in a few hours.
That explains the behavior I've seen. Using the settings maxbtc 25, minbtc 0.01, maxusd 75, minusd 0.01, risk 0.50, and the high risk option I have a loss of about $0.60 usd after 12 hours.
You have stated you ran multi year backtests to reach the current strategy, why then are you modifying that strategy opposed to running exactly what performed well in the backtest?
You have stated you do not have enough spare funds to properly forward test the strategy, why not just add a few lines to have ATP log simulated trades, btc/usd price, time, and all the various information that would allow you to see the strategies performance without risking any btc?
I assume you are aware it is easy to create a strategy which is form fitted to a set of historical data, which then performs horribly in forward testing. Without any of the hard numbers and results from your map reduce testing there is no way to determine if this is the case. There are enough customizable variables (min/max, risk tolerance, etc) that widely varying results should be seen. I am still not clear which set of these variables performed well against historical data.
While the strategy may not be the long lost holy grail I have certainly had fun toying with it. Once new commits are made I will update and let it continue to run.
It comes down to an issue of algorithmic translation and peculiarities of java math.
It's one thing to say
weight = trendArrow + bidArrow / ticker.size and expect a fractional weight.
But if trendArrow and bidArrow are integers and you divide them it's not a fraction, it's 0.
If you take a weight of 0 and multiply it by your balance it's going to be 0.
I believe I have now corrected those issues and I'm forward trading on my own account to see the difference in performance and on the whole it seems to be working again.
Sep 17, 2012 1:49:32 PM org.open.payment.alliance.isis.atp.TradingAgent run
INFO: Ticker Size: 178 | Trend Arrow: 4.0 | Bid Arrow: 9.0 | Ask Arrow: 0.0 | VWAP: USD 11.89337
Sep 17, 2012 1:49:38 PM org.open.payment.alliance.isis.atp.TradingAgent evalAsk
INFO: Weight is 0.07262569832402235
Sep 17, 2012 1:49:39 PM org.open.payment.alliance.isis.atp.TradingAgent evalAsk
INFO: Attempting to sell 0.165061124189944149231963066437600673452834598720073699951171875 of 2.27276471 BTC available
Sep 17, 2012 1:49:39 PM org.open.payment.alliance.isis.atp.TradingAgent marketOrder
INFO: Successfully sold 0.165061124189944149231963066437600673452834598720073699951171875 at current market price.
Sep 17, 2012 1:49:39 PM org.open.payment.alliance.isis.atp.TradingAgent marketOrder
INFO: Current P/L: BTC -0.15723529 %-6.47058800
Sep 17, 2012 1:49:39 PM org.open.payment.alliance.isis.atp.TradingAgent marketOrder
INFO: Current P/L: USD 1.85987 %6.50200
Sep 17, 2012 1:49:39 PM org.open.payment.alliance.isis.atp.TradingAgent marketOrder
INFO: AccountInfo [username=isis, wallets=[Wallet [balance= BTC 2.27276471], Wallet [balance= USD 30.46546], Wallet [balance= EUR 0.09964], Wallet [balance= GBP 0.07921], Wallet [balance= AUD 0.22792], Wallet [balance= CAD 0.21845], Wallet [balance= CHF 0.10945], Wallet [balance= JPY 9.773], Wallet [balance= CNY 0.72304], Wallet [balance= DKK 0.7253], Wallet [balance= HKD 9.80315], Wallet [balance= NZD 0.15005], Wallet [balance= PLN 0.36728], Wallet [balance= RUB 3.59428], Wallet [balance= SEK 0.757], Wallet [balance= THB 3.90461]]]
It's a stupid mistake and I wouldn't have made it, but I wasn't familiar with this "BigMoney" class that's being used by the API and assumed that it was truncating the display value, but that the actual value would be essentially correct. I was wrong. But that's why the huge disclaimer and the fact that you need to pass a command line option to enable live trading.
So to answer your question, the algorithm as implemented is not the same algorithm as tested.
In the process of discovering that fact, I've also found permutations of the algorithm that according to my handy dandy calculator should show dramatically different (perhaps better) results. However I don't have the resource to sit and devote to this, but I'm the kind of person who can't resist a challenge either.
