The PSAR (Parabolic Stop and Reverse) is a unique indicator.
When above the price bar its lowest value can only be the bar's high.
When below the price bar its highest value can only be the bar's low.
It can never have a value between the bar's high and low.

As the image above shows it sometimes gets a value between the high and low. This is wrong. Please fix.
[Note: The issue is only with PSAR, not with Parabolic2.]
1
581
Solved
10 Replies

Bookmark

Sort
Thanks, we'll take a look. Marked for investigation.
0
I don't have my Wells Wilder book with me but I'm sure that the very original formula is:

PSAR[bar+1]= PSAR[bar] + alpha(EP - PSAR[bar])

so I believe the current implementation is correct where the calculation from the previous bar is for the current bar that can therefore experience a bar that overlaps the value.

I have used it this way for years. I leave it to Eugene and Cone and Glitch to decide but I would not like to see a change to this specific indicator.
1
PSAR *cannot* be plotted inside the price bar, only above or below, hence its use as a Stop.
0
Plotting is one thing, but the issue here is that we have to use real world rules when dealing with indicators. Like psimmons' formula above suggests, you calculate the SAR for the next bar based on the prices for the current bar. This is the way stop and limit orders are applied in backtesting and of course, live trading.

Let's take this example, not unlike yours above, which is even more obvious -

The SAR calculated on 9/13/2022 was 391.0396. This is the value you use for your stop price in the market tomorrow. The 391.12 low on 9/14/2022 did not trigger the stop, so you calculate the SAR for the next bar - 392.6948. Remember, you still don't know where the market will be tomorrow and this new value will be used on the next bar.

On 9/15, the market opened at 392.89 and triggered the 392.6948 stop that was calculated on 9/14, and this is where the position reverses. The new SAR value is set to the high attained by the previous SAR series.

Does that make sense now?

The real way to look at it is in a Strategy and plotting the stop orders on the bar on which they're active.

```CODE:using WealthLab.Backtest;
using System;
using WealthLab.Core;
using WealthLab.Indicators;
using System.Drawing;
using System.Collections.Generic;

namespace WealthScript123
{
public class PSARStrategy : UserStrategyBase
{
public override void Initialize(BarHistory bars)
{
_psar = PSAR.Series(bars, 0.02, 0.2);
PlotStopsAndLimits(5);
StartIndex = 1;
}

public override void Execute(BarHistory bars, int idx)
{
if (OpenPositions.Count == 0)
{
}
else if (HasOpenPosition(bars, PositionType.Long))
{
}
else
{
}
}

PSAR _psar;
}
}```

And here's the corresponding sequence of trading used for the example -

0
While I think what I said was correct, I see that Glitch implemented a change to PSAR, so let's say this is still under investigation.
0
The PSAR (same parameters) plotted on same stock (SPY) at 2 brokerages:

Fidelity:

At no point does the indicator violate the price bar, it simply reverses - like its supposed to.
0
You're right, we've detect a problem or two in the calculation and we'll get it worked out.
0
Apologies to psimmons, but this is changing for Build 18.

One of the main problems we had was adding acceleration for every bar of the trade, but it should only be increased when a new high/low in the trade direction occurs.

0