Should i contact to HP printer support for printing solution. What is the process to getting a bit coin?
I am making a bit of code that might be considered as a bitcoin printing press… The will is there at least. Time will telll
That’s a great name for your bot Mr Crash Gutenberg!
Will get back to doing more code soon, but something I always wanted to build in was an API call to Google Trends to evaluate sentiment with something along the lines of:
Could be interesting and open up the bot to some easy AI data.
Been working a little on the Google Analytics, it has been interesting, some data below:
When the BTC price goes down, the number of searches for “buy bitcoin” goes up.
There is other correlations where the number of searches for bitcoin trends up hours before a price increase.
Some cool stuff here, but time to get back into things for this new year!
I came across this announcement from Google related to crypto indexing at minute 18:35 by Ivan on Tech that will help with gauging “sentiment” and other goodies: https://youtu.be/A23uFiUc7zM
Quick update and I’m going to let you in on some of my secrets.
Based on our current “Follow the Trend” code, you may have noticed (as @mwlang has with all his screenshots a while back), that the bot makes some good choices, but also makes some bad choices.
This is because it is missing a signal we call the “Trade BIAS”.
The Trade BIAS is a signal on the Long Moving Average. We take last last 9 LMA values and create an average. If the average is above the LMA, then our Trade BIAS is “Go Long”, whereas if the average is below the LMA, then our Trade BIAS is “Go Short”. This is similar to the MACD indicator and gives us an idea if the price action is bullish or bearish.
Then we also need some logic on the Short Moving Average and Medium Moving Average as well, plus we need to have more logical values than just guessing what they should be.
So here are the secrets.
The Short Trend should be a small value, the Medium Trend should be the Short Trend times 4 and the Long Trend should be the Medium Trend times 6. Our BIAS indicator should always be 9.
As the Short trend moves to crossing the Medium Trend when in a price dip, then as it approached this area, the price action going down should be at a diminishing rate.
IE: for each iteration of the price, the difference between the current price and the previous price should be reducing - or compressing, which indicates that the sell pressure is dropping and the bulls are taking the reigns.
The Short Trend should be calculated as the number of iterations between the time it takes for the short trend to cross the medium trend and back (a full cycle).
Then logic starts to be geared around: If the Trade BIAS is “Go Long” then “Do trades”, otherwise don’t do trades and wait. Then the “Do trades” is when the short and medium cross with the good indication of price action compression.
I hope this makes sense and I will try and get code together to show how this works and why it works and how it makes the bot execute in a much more positive way with significantly less stop losses.
However, my values and logic secrets are out
After putting together some code and reviewing my old code, I realised that statement above is wrong.
I will provide the correct method once I make sure my code is right
Awesome. That write up was indeed a missing piece of the puzzle here. I know from my own experimentation that we needed to be trading with the trend but finding a good method of calling the bias as you termed it – that’s been a huge challenge all in all. So I definitely look forward to learning how you approached this with code.
One other critical piece of the puzzle, which I think you allude to in the above excerpt, that is missing in the current scripts is dynamically measuring cycle lengths so as to adaptively set short, mid, and long term durations. To that end, since you’ve been quiet, I’ve been studying and learning about cycles vs. trend mode from John Ehlers’ books on the subject and using his techniques for dominant cycle measurements. So I get a “DC” value (for dominant cycle) that looks something like this:
Once I had this, I started calculating RSI and momentum from the DC value and it’s working fairly well. The main problem is during extended down-trend, profits indeed are eroded and I recognized even before your post about trend bias that I needed to not be trading when overall trend is down/flat AND volatility is also low.
I am still working to understand cycle measurement and what values are the ideal values to use for tracking trends, so I hope you’ll address cycle lengths as they pertain to setting the short, mid, and long durations.
For others reading this, my Ehlers code for computing dominant cycle length is in Ruby, not PHP. I’ve privately given this code out to pub members in the discord channel for trading-bots, but if others are keenly interested in this same code, let me know. If interest levels are high enough, I may try to pull together into a proper open source project – please be aware, the code is ONLY what’s needed to measure the dominant cycle and a few other of Ehlers indicators as described in his two books,
- Rocket Science for Traders: Digital Signal Processing Applications
- Cybernetic Analysis for Stocks and Futures: Cutting-Edge DSP Technology to Improve Your Trading
It’ll be up to you to take such and turn it into profitable trading strategies or adapt to Fishy’s PHP scripts, so please only ask if you’re truly interested in doing what it takes to build your bots.
For those of you learning to code in any language and interested in Ruby, check out the following for how to get started: https://infinum.co/the-capsized-eight/becoming-a-ruby-on-rails-developer
The Dominant Cycle is an interesting method, mine was significantly more simple
I simply waited for period of sideways action and looked at how long it took for to go from a low to a high and back, which is generally around 25-27 minutes on average. I then took this number of iterations and divided by 4 for the ST and multiplied by 6 for the LT. Since my code wasn’t all that smart, it would not adjust it again until the next day.
Also, I wrote:
The Short Trend should be calculated as the number of iterations between the time it takes for the short trend to cross the medium trend and back (a full cycle).
That should have read the Medium Trend and during a sideways action period. When you can “guess” the timings of the other bots, you can work with them and ride the waves.
I’ve been out with several friends lately devising the business plans for this year and it’s involved a lot of Baijiu, so my brain is a bit mush still
It looks to me that with a combination of dynamically tunable dynamic factors and some logic to assess market direction then you have the functionality of a pretty dam good bit of code.
My concerns come down to two main areas:
- Indicators - somewhat relieved by the last few posts
- Bid management - I have had some advice to just use market orders to ensure that it goes and to keep placing them if it doesn’t complete.
I am still making my way through Crash Course on python. Its a good book. Really enjoying it.
I wouldn’t use market orders unless its a deep market with liquidity. Even then, market orders are dangerous. Perhaps use a stop limit order that bids over the last offer (if getting long). Good order management is part of your edge. Paying the spread adds up over time.
This is why the pub is so good! You have just given me one hell of an idea. Thanks for your input. Just need to predict as well as I can the cycles and set up the stop loss at that point and if it keeps going long cancelling the stop loss. Its going in the correct way.
Definitely some food for thought. Thanks for a very succinct response.
I use market orders in my code, but there is a LOT of code for managing the orders.
Using Market buys/sells, does fairly much guarantee the orders complete, but you have to be careful and query the orders to see how much they are and the quantities.
For example, you want to buy 100 of something. If the lowest sell order is $1 and has a quantity of 25, then the next sell order is $1.10 and has 25, then the next one is $1.50 and has 25 with finally the last one at $1.75 with a quantity of 25, then you have to process that to see the average price you bought for.
Market orders tend to be ok on small quantities, but on large quantities, it is worth the effort to code some order management. Setup your buy orders (that you are hoping someone will sell to) and adjust them over a time period that suits the speed of the bot, then cancel any incomplete or partially complete and deal with the outcome.
There is always more trades which can be done, so trying to complete every order is a lower priority than getting the right price.
Same for me for the mainline trading strategies. I check the order book depths for a given quantity desired and know the synthesized price from however many rows on the order book would be consumed with my order. I’ve heard the term “slippage” in trading parlance, so I tend to think of the difference between last traded price and the synthesized price as the “slippage” and will skip the trade (or reduce order to consume only the N rows to keep this slippage percentage below a arbitrarily set threshold.
I do use limit orders for some of those CDA’s where stop/loss hunting is happening, but I’m placing the order to a predicted estimate of where the next stop/loss hunt will reach in the order books, so it’s kind of an “out of the money” style of trading. As long as the CDA is going largely side-ways, works great, but if it turns south in a big way, can end up forcing a stop/loss sell.
I have been putting together code and testing, but going to hold off sharing at the moment as it is kinda buggy and doesn’t quite perform how it should.
Plus, every time you write some code and test it, you always find a way in which it can be better LOL
During some of the testing, I have figured out a method that can be an easy and effective indicator to trade on, so I’m going to iterate on the code more to make something more useful with a modified strategy (that just seems to work right in theory, but when you put it into practise, you find all the gotchas).
Anyway, just an update to say I’m still working on a new unique strategy and code and will post it up once I’m reasonably happy with it.
I don’t know if you guys are testing stuff, but I have been.
During the last BTC sell off, not only did the Binance GUI have timeouts, so did the API.
I was getting timeouts on the API for a good 15 mins.
One of the risks of trading, the system you are trading on is not infallible.
However, on the ST, MT, LT strategy, the bot would have sold almost 1.5 hours before the issue and not bought any back due to the downtrend leading up to the sell off.
The bigger issue I noticed was that Buy Orders were being cancelled at a very rapid rate, so if you were doing a Market Sell, there would have been no knowing what price you would have got. Couple this with Market Sells not completing during the period, if you were late in your stop loss, you probably would have lost quite a bit.
There was plenty of indications that the dump was coming though and the standard ST, MT, LT trend trading with a 30min MT strategy, would have caught it 1.5 hours prior to the dump.
While trying out my new strategy, it would have been ok as well, but the works is still in progress. It is nice to have this action to test with though
Yup, still here and still testing and iterating. I’ve mostly been working on strategies based around John Ehlers’ stuff since there’s a lot he published about it and I’m learning more about “being a trader” from his materials than anywhere else. There’s so much background information and knowledge distilled in his papers, not to mention a “engineer’s perspective” taken on the whole topic that highly appeals to my own engineering mind-set.
As for me, I didn’t really know how to put together the ST, MT, and LT strategy into a consistently profitable one, so I fell back to studying what other traders who’ve published are doing. Ehlers has really cracked the coconut for me with the whole cycles vs. trends and using signal processing concepts from radio, TV, and sonar fields to apply those methodologies into turning discrete data (i.e. market data) into signals that can be interpreted by a computer with simple rules. I still, to this day, don’t fully grok all the math he uses, but I’ve learned enough from him to be able to build my own indicators and employ the tools he’s given me – things like automatic gain control, roofing filters, super smoothers, hilbert transforms, and so on, to extract signals from the noise and then build trading strategies from those signals. These tools alone are absolute gold to those of you wanting to automate any trading strategies.
What I focused most on since your last code update was learning to measure cycles and then using that info to extract other information from the charts more accurately and “responsively” – for example, since your last code update, one thing I learned about RSI is the ideal look back window on RSI is half the dominant cycle (that is the peak to trough to peak distance divided by two). When it’s half the cycle, it’ll swing from 100 to 0 and back. When it’s not matched to the cycle length, it can be “muted” in it’s responsiveness, or worse, over-zealous in swinging between 0 and 100.
To me, simple stuff like this is knowledge is gained from years of experience trading, or in my case, extensive research to learn from other accomplished traders in the field who’ve published and it makes a huge difference between simply automating any ole’ strategy and actually understanding what exactly you’re trying to accomplish!
As for catching the recent sell off, the bot I have running presently did indeed successfully catch this, but my approach was with Ehlers’ simple decycler oscillator as discussed here:
The main goal for me in the interim since your last post was to accurately identify when I’m trading with the trend and when I’m trading against the trend and it took a HUGE amount of trial and error and reading and researching to find a good solution that works in all conditions with minimal lag in marking turning points. At the end of the day, it was Ehlers’ decycler oscillator that has proven most robust and dependable for this for me.
This is a snapshot of the last 900 minutes (15 hours) of trading on BNB/USDT pair:
Basically, I’m in a tradeable zone when the short range decycler enters into the long range decycler and stays above it and that is shown in the highlighted areas on the chart. When the short range crosses down below the lower bound of the long decycler, I’m back in a “no trade” zone and no new position are opened. If a position happens to be open, the current strategy attempts to ride it out, which it seems from back testing to survive about 75% of the time if the market is moving sideways, otherwise stops out around 3% loss.
Identifying trending zones alone has done more than anything else to “preserving profits” earned over the long haul (i.e. not squandering in “catch the falling knife” scenarios of down-trend trading) and proves the old adage, “never trade against the trend” that we hear over and over.
Also, if you notice in the screenshot, I’m leaving some profits on the table, esp. where there was a big divergence between the short decycle and long decycle in the middle (that peak, if captured, would’ve been a 16% gain instead of the eventual 10.9% gain it closed at. And therein is one of the challenges of figuring out a balance between riding the wave and getting out with profits. Also, if you note, buy #11 stopped out at -3.3% loss, but if it had been allowed to ride, it would’ve eventually turned profitable. The trick here, for me is also another balancing act, as that same -3.3% stop/loss saved me on sell #13 when the big sell off down-trend kicked in. So the big question is where to draw the stop/loss lines and/or if there’s a better way to manage stop losses in general.
I really cannot complain though, because over the last week, this trading strategy did result in a 55% performance:
But before anyone here goes all “gah-gah” over these numbers, keep in mind the past week has been a great one for cryptos in general! and I’m still working on making this strategy profitable (or at least not bleeding profits already gained) in all weather conditions.
All this is to say, I still have a lot of work to do to refine the bot’s trading. I’m happy with the progress I’m making and there’s a lot going into this to make it robust across constantly changing market conditions, which is perhaps the most ambitious of goals I’ve set out to conquer here. It’s one thing to write bots that you can turn on and off as you see market conditions suitable for each one – its quite another to build one that can ride this crazy world of crypto full of shenanigans (including the exchange going down!).
@Mike_Fishy, I owe you a huge thanks for opening this thread, sharing code and generally helping to push me in the right direction for building solid trading strategy. You definitely gave me the seeds that led to where I am now. Although our tactics are clearly very different, the conceptual approach of finding the up trends and trading only within those “safe zones” are, for all intent and purposes, the same and you put me solidly onto that path with your examples and educational pops.
I, for one, definitely look forward to your next update! Keep 'em coming; keep us learning!
ADDENDUM: To the above post, I thought it would be good to mention another of Ehlers’ indicator called the Universal Oscillator. LazyBear has implemented such on TradingView, but it has a bug you’ll want to fix in which degrees must be converted to radians.
However, it’ll produce nearly the same trend identification as my two decyclers and if you compare the times the UO is above zero against the highlighted regions of my chart above, you’ll see they’re quite similar:
So this is a good way to get your feet wet with one of Ehlers trend detecting indicators without getting into coding your own bot!
As for the degrees vs. radians bug, copy LazyBear’s script then open and edit and change line #16 to this:
b1= 2.0a1 * cos((1.414180 /bandedge)*3.14159/180)
Now you’ll be able to adjust the Band Edge setting without it going all wonky on ya.