Is there a way to edit the config using a text editor?It's a pain to config everything when you just want to change the algorithm or a single value.Or maybe that's just the way I'm used to do stuff lol

Yes on linux it will be in the .java folder under your home directory

Code:

~/.java/.userPrefs/org/open/payment/alliance/isis/atp/prefs.xml

For windows it's going to be somewhere in the registry, just search for your API key.

for me it has been selling 0.01 coins for the 10 hours all time, that is normal behaviour i hope? :p

If you're running the latest version which was uploaded a few hours ago and its still doing that you may need to restart with --clear-config=true since there are some new options.Make sure maxbtc is a reasonable level. If you have it set to 0.01 its going to trade a single bitcent ad nauseum forever.

If it is still doing it, check your btc balance and make sure you actually have some.In the current market as of this moment, anything less than 10btc and it will be trading at the minimum. The current trend has been treading water for about the last 8 hours, in my case more sells than buys. But then again I didn't start with much to begin with.

i've reset it but if i launch it now it does nothing :x

Code:

C:\Program Files\Java\jdk1.6.0_21\bin>java -jar isis.jar debug-live=truenullException in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)Caused by: java.lang.NullPointerException at org.open.payment.alliance.isis.atp.Application.showAgreement(Application.java:112) at org.open.payment.alliance.isis.atp.Application.start(Application.java:76) at org.open.payment.alliance.isis.atp.Application.main(Application.java:54) ... 5 more

C:\Program Files\Java\jdk1.6.0_21\bin>java -jar isis.jarnullException in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)Caused by: java.lang.NullPointerException at org.open.payment.alliance.isis.atp.Application.showAgreement(Application.java:112) at org.open.payment.alliance.isis.atp.Application.start(Application.java:76) at org.open.payment.alliance.isis.atp.Application.main(Application.java:54) ... 5 more

I switched to USD.It was odd seeing it selling and buying EUR but showing me USD tickers. lolAlso because the EUR market has a very low volume.I took the opportunity to switch currency when I was all-in on BTC.

I've been checking and the app VWAP is most of the time 0.05 BTC above the MtGox VWAP

I switched to USD.It was odd seeing it selling and buying EUR but showing me USD tickers. lolAlso because the EUR market has a very low volume.I took the opportunity to switch currency when I was all-in on BTC.

I've been checking and the app VWAP is most of the time 0.05 BTC above the MtGox VWAP

I've added the ability to see all the market indicators we use to trade.

Code:

INFO: Trend Arrow: 1 | Bid Arrow: 5 | Ask Arrow: 0

I've also modified the weight calculation for the "High Risk" trading algorithm to be much more aggressive (curve elastic) and more in line with the algorithm I originally used on day 1.

(substitute askArrow for bidArrow depending on if we are looking to sell (bidArrow) or buy (askArrow)High Risk

I switched to USD.It was odd seeing it selling and buying EUR but showing me USD tickers. lolAlso because the EUR market has a very low volume.I took the opportunity to switch currency when I was all-in on BTC.

I've been checking and the app VWAP is most of the time 0.05 BTC above the MtGox VWAP

I've added the ability to see all the market indicators we use to trade.

Code:

INFO: Trend Arrow: 1 | Bid Arrow: 5 | Ask Arrow: 0

I've also modified the weight calculation for the "High Risk" trading algorithm to be much more aggressive (curve elastic) and more in line with the algorithm I originally used on day 1.

(substitute askArrow for bidArrow depending on if we are looking to sell (bidArrow) or buy (askArrow)High Risk

The hope is that this will cause more curve capture towards the peaks and valleys of the curves while minimizing the churning we've been seeing.

I've split my balances 50/50 @ USD 11.94290 which was the current market at the time I restarted my bot.

I'll report the PL in a few hours, if it's doing good I'll make a commit with the new algorithm.

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.

INFO: Attempting to sell 0.00000000 of xxxx.22053628 BTC availableSep 17, 2012 7:22:21 PM org.open.payment.alliance.isis.atp.TradingAgent evalAskINFO: 0.00000000 was less than the configured limit of 1Increasing order size to 1

INFO: Attempting to sell 0.00000000 of xxxx.22053628 BTC availableSep 17, 2012 7:22:21 PM org.open.payment.alliance.isis.atp.TradingAgent evalAskINFO: 0.00000000 was less than the configured limit of 1Increasing order size to 1

Yeah, that's the exact same thing I'm seeing. It's trading without a good enough signal.

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 fit 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 have not seen it mentioned which set of these variables performed well against historical data.

While the strategy may not be the holy grail I have certainly had fun toying with it. Once new commits are made I will update and let it continue to run.

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 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.

...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.