This code is open source under the MIT license. If you have any improvements or corrections to suggest, please send me a pull request via the github repository https://github.com/casey-bowman/sar
For more details on the initial script, see , where the quotes are from Section II of J. Welles Wilder, Jr.'s book New Concepts in Technical Trading Systems (1978)
"The Parabolic Time / Price System derives its name from the fact that when charted, the
pattern formed by the stops resembles a parabola, or if you will, a French Curve. The system
allows room for the market to react for the first few days after a trade is initiated and then the
stop begins to move up more rapidly. The stop is not only a function of price but also a function
"The stop never backs up. It moves an incremental amount each day, only in the direction which
the trade has been initiated."
"The stop is also a function of price because the distance the stop moves up is relative to the
favorable distance the price has moved... specifically, the most favorable price reached since the
trade was initiated."
A. The calculation for a is:
Tomorrow’s SAR = Today’s SAR + AF (EP - Today’s SAR )
"Acceleration Factor ( AF ) is one of a progression of numbers beginning at 0.02 and ending at
0.20. The AF is increased by 0.02 each period that a new high is made" (if long) or new low is
made (if short).
EP is the "Extreme Price Point for the trade made so far. If Long, EP is the extreme high price for
the trade; if Short, EP is the extreme low price for the trade.”
Most websites will provide the above calculation for the but almost all of them
leave out this crucial detail:
B. "Never move the SAR into the previous day’s range or today’s range
"1. If Long, never move the SAR for tomorrow above the previous day’s low or
today’s low. If the SAR is calculated to be above the previous day’s low or
today’s low, then use the lower low between today and the previous day as
the new SAR . Make the next days calculations based upon this SAR .
"2. If Short, never move the SAR for tomorrow below the previous day’s high or
today’s high. If the SAR is calculated to be below the previous days’ high or
today’s high, then use the higher high between today and the previous day
as the new SAR . Make the next days calculations based upon this SAR ."
When a SAR is broken then it gets placed at the SIP (significant point) of the prior trend.
In otherwords it is placed above the current candle and at the price that was the SIP.
The inverse is true for the first SAR .
"This system is a true reversal system; that is, every stop point is also a reverse point." If breaking
through a SAR (one above price) that simultaneously signals to close a short and go
You have this:
reversal_state = 0
if reversal_state == 0
//Do Stuff A
else if reversal_state == 1
// Do Stuff B
// Do Stuff C
I'm having trouble understanding how B or C is ever executed. I'm new to Pine, so I'm probably missing some idiosyncrasy of the language. Can you help me to understand?
Additionally, if those legs of code were capable of being executed, it seems there would be a separate problem because of the "==" used on lines 117 and 124 (instead of ":=").
Are the "==" at lines 117 and 124 not an issue? I thought that those were just boolean expressions.
Lo and behold, user-defined variables are rolled back at each update on a realtime candle to the their state at the opening of that candle. Therefore, there is no way to convey information from one update to the next on the same realtime candle. Thus there is no way to implement the idea I had to address multiple intra-candle reversals.
Happily the code runs the same path as before, as in the initial version from July, if there are such rollbacks for each realtime candle's updates and the code stays in "leg A".
The only other change that's been made to the Lucid SAR since July is to encapsulate the code into a function, which for the Lucid SAR was based on a change sent to me by davzuchy via Telegram https://github.com/casey-bowman/sar/commit/a59bf5b381a15b57d71776fb6bfb3e4a0ae6b445
So the code should behave the same as before. When I release a new version, I'll remove this attempt to handle repeated intra-candle reversals. There seems to be no way to do this given PineScript's current capabilities. I also would like to simplify the function call now that I look at it again.
Thank you for asking questions!!