Bot trades with loss all the time. #189
Comments
|
I'm sorry you experienced some rough trades. It appears that (using GMT timezone?) it bought on the first big green candle here and sold on the first big red one:
That's a whipsaw, a bad signal followed by a corrective signal. At least the sell saved you from holding during the down period at the end there. All trading systems will have bad signals like this and there's no great way to filter them all out. The default strategy tries to filter them with a std. deviation ( If you haven't run sims, I'd really recommend doing so... the default settings are a rough starting point. Some altcoins that have 20-50% change per day, it's very risky to trade, manually or with a bot. I would focus on low volatility markets with strong uptrends, and avoid trading on downtrends. Also the graph could've easily gone the other way and the first buy would've returned profit, but there's no way to code a strategy that can predict the future :) I'm very open to ideas about improving the strategy. The higher the volatility the higher chance for bad signals I think. |
|
Thanks for the reply. I was already testing zenbot3 and I got kinda used to it. Still trying to grasp this one. But is it normal behavior that it sells at a lower price if the c.sell_stop_pct is set to 0 (disabled)? And how far does the bots memory go between restarts? Is it aware of a trade it did three days ago if I restarted it twice in the meantime? If he does not know he bought something at a certain price it would explain the selling at a lower price. (but with the NXT example there were no restarts). Strategy wise I am just playing around for now. For now I am trying to achieve that the bot buys, if price goes higher sell (80%), if it goes lower dont sell. I have the spend percentage set to 30% on the buy side and 80% on the sell side. So I always hold some coins on both sides. This actually saved me through this, if I gave it 99% the loses would be much higher. Performance wise it works great btw if you dont count poloniex having issues all the time... Edit: And no need to be sorry, we all read the disclaimer, use at your own risk :) Edit2: Would setting this c.max_sell_loss_pct to 0 prevent it from selling at a loss? |
the profit figure is the only thing that's carried over (if the balance is the same as the end of last session), it starts fresh with the my_trades, since the gap between stopping and starting the bot could cause unwanted stops to trigger.
No, that one is meant to be protection in case the price slips in a huge way during order execution, (and it actually holds despite sell signal) if the order takes too long or the exchange has maintenance (prices sometimes do wild stuff after maintenance). setting it to 0 disables that protection, but setting it to 0.1 would keep holding if any loss from last buy. That's dangerous because holding during a downtrend loses profit. If you set |
|
I have same case. |
|
@nao0811ta Still the same for me too, have a few more days of data now. Example ETC: At this pattern I assume it will sell again around 0.0062 😄 Pulled the code updates now and restarted all the bots. Also set c.max_sell_loss_pct to 0.1 like suggested by @carlos8f to prevent it from selling at a loss. Will report in a few days what happens. |
|
It seems my results are kinda the same as well. It seems to be consistently selling low, buying high, unless I'm missing something. I have tried both the default settings which had the same results, as well as the ones pasted above. @carlos8f thank you for all your work on zenbot; this is not criticism or a complaint, just trying to figure out how we can make this better! :) losing is part of the fun ;) |
|
With c.max_sell_loss_pct set to 0.1 I have seen a few positive trades, but still more exceptions than a rule. Plenty of trades where it buys higher and sells lower. Still an improvement, before not a single trade was positive. @carlos8f Shouldn't it hold no mater what if set to 0.1? Or did I misunderstand? |
|
@carlos8f For improving the strategy, I would suggest: Looking at the console output, the bot would make a decent profit if would do the exact opposite of what it is doing now, change the buy signals to sells and sell signals to buys: Current behaviour: Buy when ema value bottoms. On a 1h period for example, track last 12hours. If ema current is negative and smaller then ema n-1 DO NOTHING. If ema current is equal or is getting larger than n-1 then BUY. Sell when ema tops. If ema current is positive and larger than ema n-1 DO NOTHING. If ema current is equal or getting smaller than ema n-1 SELL. Of course evening it out a bit, looking at a few hours of ema values back, not just the last one to kinda catch the trend. What do you think? |
|
@krilson I will try experimenting with that, however I'm a little confused:
|
To be clear I don't recommend that as a setting (yes it should hold, unless you restart the bot in which case the trade memory resets) |
|
I should also note that
|
|
Live trading with Bitfinex gets similar negative results. Paper trading gives possitive with the same settings. |
|
hey guys, I posted a readme update for "known issues" relating to losses seen in live trading. I've been busy lately so it may take some time for improvement. Thanks! https://github.com/carlos8f/zenbot#known-issues-and-current-status |
|
Hi, I'm not an expert but just thinking out loud here. Would it be nice if the --period goes to, let's say from 30 to 10 minutes as soon as a buy was initiated? In this case the bot sells sooner? |
|
@rondijkstra this hold period is one that v3 had, it can end either good or bad. |
|
Ok! |
|
I know it's stupid, but try to test this with your setting. I've got better results in sim and paper with error rate below 30% (even 0%) - it seems that standard setting gives profit only in specific market conditions. |
|
I did some testing (SIM) with DGB that was rising pretty fast yesterday. The sim of standard setting gave me 42.6% profit. (5 day sim gave +103.97% VS 4.52% profit..) |
|
Results for about 30 hours paper simulation: 2017-06-05 18:24:00 0.00000164 BCN-BTC +0.0% 3.79m + 0.1005 0.7000 +0.6% 0.00 BCN 0.02604 BTC +30.2% +19.9% Results was also positive for the two, live, 15 minutes sessions. [Summary] |
|
I am getting positive results with this: --period=60m --min_periods=60 --trend-ema=40 --neutral_rate=auto conf.js // avoid trading at a slippage above this pct Gave it only 20% buy balance, to make it buy several times, otherwise it would spend the whole balance on one buy. This way it spreads the buys and usually gets a better price on average. I don't even bother with the simulation, the results are too different. |
|
My idea was along the line that the bot captures the curve of the ema and buy at bottom, sell at top. Both the number of ema captures and the period should be configurable by the user. A good period would be about 10/20 minutes from my experience. Also a hard limit on when to buy should be placed. Buy only when ema is bellow -0.15 and sell only if its above 0.15 (for example). An example when to buy, considering 12 periods: Here a buy would happen at ema8.
To sum up, while the ema is decreasing do not buy, wait for it to start evening out. Then buy. And the opposite for sell, do not sell until it is rising, sell when it starts evening out. Implementing this behavior would give good results from my experience. Fine tuning would be left to the user. Like what kind of margin to be allowed for the ema bottoming, period length, hard min/max ema to buy, last n number of emas to watch for the average. My test result at a 10min period, looking at past 5 values to determine a buy/sell is optimal. |
|
A live example of what I mean. BTC-ETC pair on poloniex: I have it set reverse now. The default signal would be buy here, but I changed it to sell. I am trying to show where the bot should sell, most of the sell signals here are too soon. I made the ones that fit my above mentioned strategy bold and the sell signal I would use is upper case "SELL HERE". You can see that the ema values go high, than stay in the relatively same value 4 periods, on the fifth period the bot would sell. 2017-06-11 08:40:00 0.00655029 ETC-BTC -0.6% 7749 + 0.0377 0.0392 I am having issues coding this, if any help would be appreciated. I was thinking about making a sub signal, that would then help to make the final buy/sell signal. Every period would have a value calculated from the previous period: A strategy could be built from these kind of subsignals like this for example: if last 3 periods are S1 and the preceding periods (lets say period n-4 to n-10, so 6 periods before) were S2 then sell now. And same for buying, if last 3 periods are S1 and the preceding periods were S3 then buy now. Does this make any sense to anyone? 😄 |
|
I'm testing macd strategy and default parameters on poloniex |
|
I gave the bot a try on default settings for a few days, clearly there's something wrong, it just flips the sell and buy (or so it seems). |
|
For what it's worth, I've left it running for about 3 hours with a small amount of ETC trading back and forth to ETH and I've made a not bad return. |
|
Seems so. |
|
Default settings and seeing same thing here, its opposite of what it should do, sells when it goes low and buys when its high..and this is on --paper trades too... if it was opposite of what its doing it might actually work good, |
|
@DeviaVir: A bit weird to close this as @carlos8f says this is it's highest priority on the README.md (linking to this exact issue):
|
|
Not sure if the bot is the issue or the exchanges. They react so slowly (especially when there a big changes with many trades), that a simulation has no comparison with the reality anymore. |
|
Probably quite a few people (like me) download the bot thinking it's a turn key solution when it's not. As pointed out by the OP.. "The default settings trade with a loss". You have to tune the thing. Almost on a daily basis to get it to work properly. I'd love to see a feature added that runs sims like the genetic backtester.. Then imports them into the bot on a scheduled interval. That way the bot can adapt to the current market changes. If anything the README.md should say in big bold neon red letters.. "THIS IS NOT A MINING RIG. A un-tuned bot will trade with a loss". |
|
@interbiznw I did exactly that. Just reversed the signals on the default trading strategy and its working "ok", still more room for improvement, but I am short on time to play with this, I just left it running for months now, and it didnt run out of money, it is slowly accumulating more. I would say it is right 70% of the time. Considering this crazy bull run in bitcoin its hard to say that it is making a profit, since it would be better to just leave it all in bitcoin, but I dont consider this a normal environment... |
|
Is really that simple to solve this problem by reversing buy/sell signals? Simply too easy to be true :p |
|
@krilson Could you share your file with modifications ? Thx |
|
@dukye Sure, here it is, very simple modification: krilson@66fc7fa#diff-c081f5fa7634cfc3a1254e982a748f9c My conf looks like this: // sell if price drops below this % of bought price (0 to disable) // Order execution rules: // avoid trading at a slippage above this pct // Misc options: // default # days for backfill and sim commands And I start the bot with this: I am experimenting now one pair with a 24h period. Experiment with the neutral rate a bit, depends how soon you want it to buy/sell. |
|
Thank you for sharing @krilson Would you mind sharing your statistics? My bot doesn't seem to be trading with very much with these settings |
|
@krilson when I install zenbot for the first time, are your changes already included or do I have to edit them in myself? Setting up a Raspi fresh, so asking in advance. thanks! |
|
@krilson thanks :) |
|
will the fix be merged? |
|
I was going to try this bot but then noticed this issue. Checking the code made me wonder, in the file mentioned above (
(I'm assuming
However, the code at line 59 doesn't seem to reflect this statement and it seems a logic error was made while putting it into code:
Let's say
So, I'm going to change line 59 to the following and then give this bot a spin!
Edit: Commit on hotfix branch: mathiasaerts@59eed42#diff-c081f5fa7634cfc3a1254e982a748f9c |
With this change in the simulation mode, the bot shows the worst result ... |
|
@mathiasaerts Great!. Did you already make some simulations comparing the result before and after your fix (same period, same options)? Can you do it ? |
Nope, you're wrong
So https://github.com/carlos8f/zenbot/blob/55d877a1998e65171c3efa544d8b3476ee11e61f/extensions/strategies/trend_ema/strategy.js#L51-L64 What I don't get is |
|
How did that work out?
…On Dec 12, 2017, 5:08 PM, at 5:08 PM, Mathias Aerts ***@***.***> wrote:
I was going to try this bot but then noticed this issue. Checking the
code made me wonder, in the file mentioned above
([`extensions/strategies/trend_ema/strategy.js`](https://github.com/carlos8f/zenbot/blob/master/extensions/strategies/trend_ema/strategy.js)),
the description at the top says:
> Buy when (EMA - last(EMA) > 0) and sell when (EMA - last(EMA) < 0).
_(I'm assuming `s.period.trend_ema_rate` represents `EMA` and
`s.period.trend_ema_stddev` represents `last(EMA)` here. Please correct
me if I'm wrong..)_
* On [line
51](https://github.com/carlos8f/zenbot/blob/master/extensions/strategies/trend_ema/strategy.js#L51),
`s.period.trend_ema_rate > s.period.trend_ema_stddev` **does** match
`(EMA - last(EMA) > 0)` (**→ Buy**)
However, the code at [line
59](https://github.com/carlos8f/zenbot/blob/master/extensions/strategies/trend_ema/strategy.js#L59)
doesn't seem to reflect this statement and it seems a logic error was
made while putting it into code:
* `s.period.trend_ema_rate < (s.period.trend_ema_stddev * -1)` **does
not** seem to match `(EMA - last(EMA) < 0)` (**→ Sell**)
Let's say `EMA` = `s.period.trend_ema_rate` = **`a`** and `last(EMA)` =
`s.period.trend_ema_stddev` = **`b`**
In this case, the description says we should **sell** when `a - b < 0`,
however it's clear that when we rewrite it to match the current format
in code, this does not add up:
> `a - b < 0`
> `(a - b) + b < 0 + b`
> **`a < b`, while in code, it currently says `a < -b`**
So, I'm going to change **line 59** to the following and then give this
bot a spin!
>`else if (!s.cancel_down && s.period.trend_ema_rate <
s.period.trend_ema_stddev) {`
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#189 (comment)
|
|
@smarzola Thanks for clearing that up. I was obviously drawing a conclusion way too fast. |
|
@smarzola The "acted_on_trend" part of the code does not make sense to me either. It seems like the code is trying to say "if the trend in the last period was not up, then we did not act on it", ie "act" on the first period with a buy signal. The way the code currently is, it seems like the acted_on_trend variable is a dummy variable that is not really doing anything. @krilson it would be very interesting to see this play out so that the bot does not whipsaw as much and does not enters/exit so suddenly. i may try playing with this Observations for neutral_rate: For using small periods like 2m or 5m, neutral_rate="auto" works well, but causes too many whipsaws. For larger periods (15m, 1h), neutral_rate="auto" does not trigger often thus some set the neutral_rate to an arbitrary .1 or .2 (i guess because this .1 or .2 is bigger than the trend_ema_stddev using a long period). I wonder if multiplying the trend_ema_stddev by a variable based on period size would work instead of setting it manually. To generalize, since neutral_rate and period are correlated, perhaps there is some variable "k" such that k*trend_ema_stddev smoothes the whipsaws, where k is larger for small periods and smaller for large periods. This would help filter out whipsaws for small-period trials and help pick up signals better for large periods trials using a variable neutral_rate. I hope the above is helpful in some way. If i implement the new trend or new neutral_rate strategy mentioned above I will post the code snippets (despite having ever coded in node.js). Thank you for devoting the time to developing and improving Zenbot, very amazing tool. EDIT (results): I tested multiplying the stddev by a constant - while it filters out whipsaws a bit for low periods, it makes the buy/sell trigger peaks less accurate, so there will always be that tradeoff; concluded that the default neutral_rate is great without the multiplier for low periods and ideally an arbitrary constant close to 0 for larger periods. Also briefly tested krilson's strategy - one can accomplish this using |
|
this might just be a layperson's observations of what's going on behind the scenes, but this is what i'm observing. current:
the way it SHOULD be:
other thoughts: strategies are also the wrong approach. strategies should be replaced with a library of technical indicators which one should be allowed to use in order to create strategies via simple equation logic. maybe provide a handful of out of the box "strategies" to show how they are utilized, but not depend upon them for continued or base utility. |
|
No news about this? |
|
Hey guys! I'm working on a new bot: Bot18, which will be more flexible, better execution, not TA-dependent. Hopefully will lead to much better profitability! However, exchange support will take a while to port over and implement for the new socket-based, realtime approach. Stay tuned!
~Carlos |
|
@shr00mie, those are my thoughts entirely, and I've implemented that approach already in Bot18. It's gonna be 🔥 ! |
|
@carlos8f so it sounds like this is going to be a lot more event driven than the on_period nature of zenbot (yay!). the approach i'm currently working around is standardization of api/websocket components to hopefully allow plug and play exchange connectivity. commands and URLs would be the variables while standardization of API/websocket/order workflow would be ubiquitous. what would you be replacing TA with any why? not following on the desire or move away from a standardized computational lib. something hand made or custom seems like it would be considerably more error prone. looking forward to seeing what you're doing with as well as how data is going to be stored compared to zenbot (which was pretty painful). i feel like the DB could have been considerably more utilized for things like trade history, user account storage (user app login&pass, encrypted API keys, etc). |
|
@shr00mie yes, bot18 will need to standardize the ws API workflow. bot18 doesn't have exchange abstraction yet, so i can focus on the maximum potential of the gdax api, my primary target. abstraction will come as soon as i get the foundation laid. I'm not replacing TA with anything, just moving TA to the background, one potential way to generate orders. The engine will be more low-level, so basically the commands are:
Then, if we're mimicking what Zenbot 4 does by default, the strategy says every 2m,
That way, the engine input is changed to 3 mix-and-match commands (you can now buy and sell at the same time with multiple orders on each side), instead of a vague "signal" which invalidates signals before it and doesn't differentiate between command 2 and 3 (you have to provide taker or maker as an arg) And the addition of command 1, which doesn't exist in Zenbot yet, will make market-making possible, and strategies will be able to maintain trailing stops directly. |
and others
Gave this a try, exchange poloniex, default settings, live trading (not sim).
The bot consistently without exception buys at price X and sells at a lower price. It is doing the opposite of what it should be doing. ( I am not kidding, every trade was with a loss, even in this crazy bull market we have now)
Even tried disabling c.sell_stop_pct = 0 but still it persists in doing this.
Example:
Buy NXT at 0.00003540 at 2017-05-24 02:13:05
Sell NXT at 0.00003449 at 2017-05-24 13:02:01
I will leave it running and keep up with the updates if the behavior changes maybe.
Edit: To also mention, I have it running on 10 pairs. Every trade that happened on any of the pairs was this way. Sold at a lower price. And it is running now for about 5 days. Maybe the long term result will be different.
The text was updated successfully, but these errors were encountered: