Isis ATP [Automated Trading Platform] - Discussion

[BCB]

where is the account config file.

With the latest version overwrite it after cloning?

[1714103233]

1714103233

[1714103233]

1714103233

[RicRock]

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.

But I'm having trouble finding it on my Mac

[zaj]

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=true
nullException 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(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa
der.java:58)
Caused by: java.lang.NullPointerException
        at org.open.payment.alliance.isis.atp.Application.showAgreement(Applicat
ion.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.jar
nullException 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(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa
der.java:58)
Caused by: java.lang.NullPointerException
        at org.open.payment.alliance.isis.atp.Application.showAgreement(Applicat
ion.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

[isis]

Its dash dash debug dash live equals true
Need both dashes at the front and the one in the middle.

[zaj]

Its dash dash debug dash live equals true
Need both dashes at the front and the one in the middle.

yes just found out at the same time, im a retard

[nedbert9]

For fun I decided to create a new branch and modify the application to look at crosspair arbitrage.

Let me know if anyone is interested in testing this branch.  

I'm interested.

[RicRock]

I've just been letting it run since yesterday afternoon ( I did apply the latest commit this AM).

My account to start:

0.12669580 BTC $0.00 USD

Currently:

0.15651580 BTC  $2.05721 USD

Really hope to get a chance to dig into this this weekend.

Thanks to Isis for an interesting project!

Still trying to find my prefs file on my Mac 

[Raoul Duke]

I'm down 0.30 BTC. No profit whatsoever =/
The only one profiting so far is MtGox lol

[isis]

I'm down 0.30 BTC. No profit whatsoever =/
The only one profiting so far is MtGox lol

Psy, what's the Euro volume looking like and what does the application say the market looks like and what's the application vwap vs the mtgox vwap?

[Raoul Duke]

I switched to USD.
It was odd seeing it selling and buying EUR but showing me USD tickers. lol
Also 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

[isis]

I switched to USD.
It was odd seeing it selling and buying EUR but showing me USD tickers. lol
Also 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

Code:

weight = new BigDecimal((bidArrow + trendArrow) / ticker.size());

The low risk algorithm is unchanged.
Low Risk

Code:

weight = new BigDecimal((bidArrow / ticker.size()) * (trendArrow / ticker.size()));

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.

[isis]

I switched to USD.
It was odd seeing it selling and buying EUR but showing me USD tickers. lol
Also 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

Code:

weight = new BigDecimal((bidArrow + trendArrow) / ticker.size());

The low risk algorithm is unchanged.
Low Risk

Code:

weight = new BigDecimal((bidArrow / ticker.size()) * (trendArrow / ticker.size()));

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.

[Raoul Duke]

Probably that's the reason I'm down those 0.3 BTC, as most of the trades did in fact got upped to the minimum order and executed.

[BCB]

Is that the reason I keep seeing.  I have set min=1; max=10;

Code:

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

[Raoul Duke]

Is that the reason I keep seeing.  I have set min=1; max=10;

Code:

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

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

[Ignatius]

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.

[isis]

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.

Code:

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.

[isis]

Trade sizes appear to be corrected.

Code:

  Order Filled at: Mon 17 Sep 2012 08:08:54 PM GMT
        Amount: 0.06323842 BTC
        Price: @$11.94901
        Total: $0.75564

        Order Filled at: Mon 17 Sep 2012 08:09:54 PM GMT
        Amount: 0.06022707 BTC
        Price: @$11.94901
        Total: $0.71965

[nedbert9]

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

It's an interesting experiment.

[isis]

Anyone else notice that the Ask price hasn't budged in several hours?