Zerolag (almost) EMA gives a good indicator of "close" trend. Many are familiar with the fast/slow ema crossing strategy. Try using this zerolag_ema as the fast runner. You will see improved and more reliable crossovers..
In general, when the zero_lag ema is above the EMA the instrument is in a bull mode and when the zero_lag ema is below the EMA the stock is bearish.
Great indicator.
Could you make n option to add another two EMA settings to it so i can use your 10 and my 66 and 189.
So looking for you to create a script that is actually 3 EMA with this one built in PLEASE
unknown_me
⋅
Thank you LazyBear for all your indicators.
grotto1364
⋅
Any chance you have this in a strategy for back testing? Thanks!
steveday72
⋅
Also known as DEMA.
Where: DEMA = ((2 * ema1) - ema2)
This: LB_ZLEMA = ((ema1-ema2) + ema1) ... or (ema1 + (ema1-ema2))
(The net result is you have two ema1's with a single ema2 subtracted.)
Theoretically, LazyBear's version could be faster to execute, because it doesn't use a slow multiplication process. Though, I guess the execution speed all depends on the compiler optimizations.
- If the compiler was smart enough it would see a fixed 2* multiplication and just add the number to itself (*1), rather than calling on the CPU's floating point "mul/fmul" instruction which takes more cycles.
*1: In assembly language/machine code (*2) it's much faster to double a number by removing the leftmost pos/neg sign bit using an AND instruction, then shifting everything else to the left by 1-bit (making 1=2, 2=4, 4=8, etc), then using an OR instruction to add the sign-bit back in. (.. and accounting for any carry bits resulting from the shift of course).
*2: For those that don't know, machine code (AKA: machine language / ML for short) is the only language a CPU understands. All other higher-level languages (C++, Python, Java, etc.) have to be compiled into it before they can be executed. Assembly language is machine lanuguage in text form for easier editing. It includes macros, user defined jump/loop labels & variables (rather than direct memory addresses), plus external libraries to keep the code concise (something that TradingView just introduced this week in Pine Script v5). Assembly language has to be "compiled" into raw machine language - though the process is more like a convertor than a compiler, since it already understands the instructions.
My history with machine language:
I learned to program machine language when I was 14 on my 8-bit Commodore 64/128 (then a 16-bit Commodore Amiga, then an 8088 Intel instruction set PC). It was great fun wringing out every last bit of performance from the Commodore 64/128 and pushing them way beyond their design limitations! (I spent thousands of hours coding directly in machine language on my Commodore 128 without any "fancy" compilers. I found the challenge of solving problems to be great fun, but once computers started to become more powerful the challenge wore off.
Now I've found a challenge with Pine Script's limitations, and am constantly coming up with new ideas for indicators (right now I'm exploring if fuzzy-math could be useful for use in charting).
crypteisfuture
⋅
@steveday72, Thanks, will be intretesting to see some ideas from you!
nogk18
⋅
Thank you for sharing!!
BTW are there lags when we use an indicator or a strategy, caused by redundant codes or whatever??
I have never thought of that before. Unless extremely long, codes should be running on TradingView's server within almost no time, isn't it true?
Great indicator.
Could you make n option to add another two EMA settings to it so i can use your 10 and my 66 and 189.
So looking for you to create a script that is actually 3 EMA with this one built in PLEASE