Is-PSAR-miscalculated

Thanks, we'll take a look. Marked for investigation.

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.

PSAR *cannot* be plotted inside the price bar, only above or below, hence its use as a Stop.

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)
         {
            PlaceTrade(bars, TransactionType.Buy, OrderType.Market);
         }
         else if (HasOpenPosition(bars, PositionType.Long))
         {
            PlaceTrade(bars, TransactionType.Sell, OrderType.Stop, _psar[idx]);
            PlaceTrade(bars, TransactionType.Short, OrderType.Stop, _psar[idx]);
         }
         else
         {
            PlaceTrade(bars, TransactionType.Cover, OrderType.Stop, _psar[idx]);
            PlaceTrade(bars, TransactionType.Buy, OrderType.Stop, _psar[idx]);
         }
        }

      PSAR _psar;
    }
}

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

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.

The PSAR (same parameters) plotted on same stock (SPY) at 2 brokerages:

Fidelity:



TD Ameritrade:



At no point does the indicator violate the price bar, it simply reverses - like its supposed to.

You're right, we've detect a problem or two in the calculation and we'll get it worked out.

👍

Thanks for fixing it in latest build (b18)!