This is great!
Thanks
How do I set the name for a Trader?
Can you add something similar for Backtests as well, so one can have a collection of trading strategies? Right now bookmarking everything manually is kind of tedious ..
Topic: CryptoTrader.org - First Web-based Algorithmic Trading Platform for Bitcoin - page 7. (Read 37851 times)
July 31, 2013, 09:09:15 AM
July 31, 2013, 06:45:56 AM
New update
- fixed the problem with connection via websockets that caused poor performance and errors in many browser configurations.
- Live mode that provides very basic support for Paper trading. Any backtested algorithm can be executed in Paper trading mode by clicking 'Live' button. Once started, an algorithm(trader) handles real-time market data to simulate trading and trigger alerts. Trading algorithms can be managed at https://cryptotrader.org/live page.
- API: Email alerts - allows email messages to be sent from your code.
Quote
sendEmail(message) (only Live mode)
Sends an email message to the user who started the algorithm in Live mode. The user's email address must be valid and verified. In the simulation mode does nothing.
Example:
Sends an email message to the user who started the algorithm in Live mode. The user's email address must be valid and verified. In the simulation mode does nothing.
Example:
Code:
# simple price alert
handle: (contex,data)->
...
if data.btc_usd.price >= 100
sendEmail 'The price hit $100'
handle: (contex,data)->
...
if data.btc_usd.price >= 100
sendEmail 'The price hit $100'
July 24, 2013, 12:14:42 PM
As most candlestick generators assume open price to be equal the close price from the previous bar, it turns out the algorithms at Cryptotrader handle market data correctly.
In traditional trading (markets that open in the morning and close in the afternoon) it happens quite often that the close of the previous day is lower / higher than the open of the new day.
Markets like BTC/USD don't close at all but I have seen candles where the open and the close were not the same at all.
July 24, 2013, 10:11:06 AM
first. by lag I meant lag of executing signal after time period is closed and ready to calculate.
second. I prefer to use next bar price from the very clear reason: your buy/sell action price will be aggregated to the next bar period, not to the previous on which signal was calculated. "Open" price of the next bar should be more correct in your case. Another thing you should keep in mind that signal calculations might be much more time consuming than just EMA crossing and would not be executed right after the period is closed.
second. I prefer to use next bar price from the very clear reason: your buy/sell action price will be aggregated to the next bar period, not to the previous on which signal was calculated. "Open" price of the next bar should be more correct in your case. Another thing you should keep in mind that signal calculations might be much more time consuming than just EMA crossing and would not be executed right after the period is closed.
As most candlestick generators assume open price to be equal the close price from the previous bar, it turns out the algorithms at Cryptotrader handle market data correctly.
July 24, 2013, 09:32:38 AM
I think there has been misunderstanding about my explanation, as i tried to explain how internal calculation of a simulated purchase is done, but not how trends are detected.
Oops my bad, I read it to quick probably
July 24, 2013, 09:11:05 AM
Once the bar is closed, an algorithm handles it immediately.
if you will have bars in 1min or 30s? it will not be as immediate as it is now.you cannot buy for average price of current bar because that period is just closed, you buy on the next bar avg price, your trade is being aggregated to this next bar.
That's why you are counting the price as next bar. You can perform simulation based on real executed price of orders ~ estimated by both methods with lag/with no lag.
When you have 30 minutes bar the engine will trigger when a bar closes, within a very short amount the engine will determine whether it needs to change the portfolio (and if to buy or sell to reflect this). This will all probably happen within 1 second after the bar closed, with the low liquidity in the BTC market I really don't think the effects are big. And if they are I don't see how the average price of the next bar is any better price indicator as a lot can happen after in the 29 minutes and 59 seconds after the decision (maybe the open of the next candle would be a little better but I really don't see it right now).
About the lag: I don't know if this data is available at all, but it is not going to help you much: when there is a 10 second lag it means the trading engine is lagging 10 seconds behind. All orders from between 10 seconds ago and now are queued and they are probably not available, so they are unknown at the time you make your decision (not 100% sure, maybe there are in the order book already).
If I got your question correctly:
Remember, this is only a simulation so the formula does not consider slippage and other real trading costs.
Code:
Trade price = Close price for the current bar + Trading fee
Remember, this is only a simulation so the formula does not consider slippage and other real trading costs.
I don't agree on your price calculation: While the trading fee obviously needs to be payed while ordering, the alpha (EMA/MACD indicator) is only responsible for detecting the trend, you are now manipulating the data so that trends happening do not get properly detected IMO (difference is pretty small, but it's there).
This is a hard problem because the current alpha (a simple trend indicator) can't tell you anything about how long a trend will probably last (statistically) or how much the price will change. If you would have a model predicting this you can better determine if you should reposition your portfolio while taking fees into account. My bot only uses the fees to simulate the profit, it does not use them to determine what position to take.
second. I prefer to use next bar price from the very clear reason: your buy/sell action price will be aggregated to the next bar period, not to the previous on which signal was calculated. "Open" price of the next bar should be more correct in your case. Another thing you should keep in mind that signal calculations might be much more time consuming than just EMA crossing and would not be executed right after the period is closed.
July 24, 2013, 08:51:58 AM
I don't agree on your price calculation: While the trading fee obviously needs to be payed while ordering, the alpha (EMA/MACD indicator) is only responsible for detecting the trend, you are now manipulating the data so that trends happening do not get properly detected IMO (difference is pretty small, but it's there).
This is a hard problem because the current alpha (a simple trend indicator) can't tell you anything about how long a trend will probably last (statistically) or how much the price will change. If you would have a model predicting this you can better determine if you should reposition your portfolio while taking fees into account. My bot only uses the fees to simulate the profit, it does not use them to determine what position to take.
This is a hard problem because the current alpha (a simple trend indicator) can't tell you anything about how long a trend will probably last (statistically) or how much the price will change. If you would have a model predicting this you can better determine if you should reposition your portfolio while taking fees into account. My bot only uses the fees to simulate the profit, it does not use them to determine what position to take.
I think there has been misunderstanding about my explanation, as i tried to explain how internal calculation of a simulated purchase is done, but not how trends are detected. By default EMA is calculated based on Close price as it is suggested in TA-lib documenation:
Code:
instrument = data.btc_usd
result = talib.EMA
startIdx: 0
endIdx: instrument.close.length-1
inReal: instrument.close
optInTimePeriod: period
value = _.last(result)
result = talib.EMA
startIdx: 0
endIdx: instrument.close.length-1
inReal: instrument.close
optInTimePeriod: period
value = _.last(result)
However, in your algorithm at Cryptotrader you can use any market data from the past as the inputs for TA-Lib functions.
July 24, 2013, 06:54:09 AM
Once the bar is closed, an algorithm handles it immediately.
if you will have bars in 1min or 30s? it will not be as immediate as it is now.you cannot buy for average price of current bar because that period is just closed, you buy on the next bar avg price, your trade is being aggregated to this next bar.
That's why you are counting the price as next bar. You can perform simulation based on real executed price of orders ~ estimated by both methods with lag/with no lag.
When you have 30 minutes bar the engine will trigger when a bar closes, within a very short amount the engine will determine whether it needs to change the portfolio (and if to buy or sell to reflect this). This will all probably happen within 1 second after the bar closed, with the low liquidity in the BTC market I really don't think the effects are big. And if they are I don't see how the average price of the next bar is any better price indicator as a lot can happen after in the 29 minutes and 59 seconds after the decision (maybe the open of the next candle would be a little better but I really don't see it right now).
About the lag: I don't know if this data is available at all, but it is not going to help you much: when there is a 10 second lag it means the trading engine is lagging 10 seconds behind. All orders from between 10 seconds ago and now are queued and they are probably not available, so they are unknown at the time you make your decision (not 100% sure, maybe there are in the order book already).
If I got your question correctly:
Remember, this is only a simulation so the formula does not consider slippage and other real trading costs.
Code:
Trade price = Close price for the current bar + Trading fee
Remember, this is only a simulation so the formula does not consider slippage and other real trading costs.
This is a hard problem because the current alpha (a simple trend indicator) can't tell you anything about how long a trend will probably last (statistically) or how much the price will change. If you would have a model predicting this you can better determine if you should reposition your portfolio while taking fees into account. My bot only uses the fees to simulate the profit, it does not use them to determine what position to take.
EDIT: It appears I failed to read properly.
July 23, 2013, 06:25:20 PM
Once the bar is closed, an algorithm handles it immediately.
if you will have bars in 1min or 30s? it will not be as immediate as it is now.you cannot buy for average price of current bar because that period is just closed, you buy on the next bar avg price, your trade is being aggregated to this next bar.
That's why you are counting the price as next bar. You can perform simulation based on real executed price of orders ~ estimated by both methods with lag/with no lag.
July 23, 2013, 11:49:43 AM
what is the logical formula to estimate the price of executed buy/sell for particular buy/sell signals?
If I got your question correctly:
Code:
Trade price = Close price for the current bar + Trading fee
Remember, this is only a simulation so the formula does not consider slippage and other real trading costs.
Once the bar is closed, an algorithm handles it immediately. At this point:
- Close price is the most recent price (simulation engine uses it to calculate simulated purchase prices internally)
- The next bar is not calculated yet. Allowing an algorithm to access trading data from the future, contradicts the idea of technical analysis in my opinion.
By the way, we have an ongoing contest for those who are interested in algorithmic trading https://bitcointalksearch.org/topic/automated-trading-contest-prize-05-btc-best-automated-strategies-261086.
July 22, 2013, 03:26:07 PM
what is the logical formula to estimate the price of executed buy/sell for particular buy/sell signals?
If I got your question correctly:
Code:
Trade price = Close price for the current bar + Trading fee
Remember, this is only a simulation so the formula does not consider slippage and other real trading costs.
July 22, 2013, 12:25:06 PM
what is the logical formula to estimate the price of executed buy/sell for particular buy/sell signals?
If I got your question correctly:
Code:
Trade price = Close price for the current bar + Trading fee
Remember, this is only a simulation so the formula does not consider slippage and other real trading costs.
July 22, 2013, 11:12:42 AM
what is the logical formula to estimate the price of executed buy/sell for particular buy/sell signals?
July 21, 2013, 12:22:52 PM
Very interesting, the H4 almost doubles return over H2.
I think for the next few weeks / months we can still expect a bear market or at least a consolidation, so it doesn't make so much sense to backtest strategies on old data from pre bubble bull market times if your primary aim is to avoid losses rather than maximize profits. If you limit it to the past 2 months instead you will see that the H2 outperforms the H4 again, at least with your settings: http://cryptotrader.org/backtests/CaSqHQo4yMmWsfGDf
July 20, 2013, 09:11:50 AM
Very interesting, the H4 almost doubles return over H2.
July 20, 2013, 06:18:06 AM
Update
- Support for 2H bars
- Web client reloads gracefully upon the server restart
- Fixed bug in portfolio that caused wrong calculations for balanced portfolios
- API: Finalize - an optional hook method called after a simulation ends. Credit to Diabolicus for this idea.
- Documentation update
- Support for 2H bars
- Web client reloads gracefully upon the server restart
- Fixed bug in portfolio that caused wrong calculations for balanced portfolios
- API: Finalize - an optional hook method called after a simulation ends. Credit to Diabolicus for this idea.
- Documentation update
July 20, 2013, 03:44:55 AM
July 19, 2013, 10:42:49 AM
wohoo, works :-)
Here's another one:
Say I would want to output some kind of additional statistics at the end of the simulation (total number of trades, trades triggererd by each mechanism, number of successful / unsuccessful trades etc..) I could add context.counter values for each of these.
Is there a method that gets called at the end of the simulation to finally output these values?
Here's another one:
Say I would want to output some kind of additional statistics at the end of the simulation (total number of trades, trades triggererd by each mechanism, number of successful / unsuccessful trades etc..) I could add context.counter values for each of these.
Is there a method that gets called at the end of the simulation to finally output these values?
No, but i agree this is a feature worth adding.
July 19, 2013, 06:15:22 AM
wohoo, works :-)
Here's another one:
Say I would want to output some kind of additional statistics at the end of the simulation (total number of trades, trades triggererd by each mechanism, number of successful / unsuccessful trades etc..) I could add context.counter values for each of these.
Is there a method that gets called at the end of the simulation to finally output these values?
Here's another one:
Say I would want to output some kind of additional statistics at the end of the simulation (total number of trades, trades triggererd by each mechanism, number of successful / unsuccessful trades etc..) I could add context.counter values for each of these.
Is there a method that gets called at the end of the simulation to finally output these values?
July 19, 2013, 06:03:05 AM
Code:
...
buy instrument # Spend all amount of cash for BTC
if buy instrument #<< how do I check if a buy was executed this tick?
...
buy instrument # Spend all amount of cash for BTC
if buy instrument #<< how do I check if a buy was executed this tick?
...
As the 'buy' is a function, the above code make it called twice, so that the second call returns undefined value. The right way to do it:
Code:
...
orderId = buy instrument # Spend all amount of cash for BTC
if orderId
# a buy was executed
context.buy_price = instrument.price
...
orderId = buy instrument # Spend all amount of cash for BTC
if orderId
# a buy was executed
context.buy_price = instrument.price
...
Jump to: