Is-there-a-way-to-modify-one-bar-of-an-indicator-in-Execute

Well, let's get the code right first. Here's the correct code.

CODE:
   public class MyStrategy : UserStrategyBase
   {
      IndicatorBase sar;
      
      public override void Initialize(BarHistory bars)
      {
         sar = new PSAR(bars,0.02,0.2);
         PlotIndicator(sar, default, PlotStyle.Dots);
      }

      public override void Execute(BarHistory bars, int idx)
      {
         sar[idx] = PSAR.Value(idx,bars,0.02,0.2); //There's no .Value method for PSAR
      }
   }

The next problem is that there isn't any .Value method for the PSAR indicator. And that's the real issue here. I "think" that's because the next value for PSAR is a function of the previous value. And when singling out a value, there isn't any previous value. So how do you propose to "guesstimate" the previous PSAR value so you can compute the next SPAR value you want?

And I have no idea how WL6 PSAR.Value method "guesstimated" this. (Are you even comfortable betting your money on a guesstimation like this?)

---
The other issue is that it's bad programming practice to "doctor" values from some other class object (such as PSAR)--don't do it. Your calling program (In this case, your strategy.) should add an IF statement so it's clear there's a weird exception being executed here.

What's the real goal here in your WL6 code? Let's code this so it makes sense.

---
One really wacky solution is given below. But I'm sure there's something much simpler.

CODE:
   public class MyStrategy : UserStrategyBase
   {
      IndicatorBase sar1, sar2;
      TimeSeries sarComposite;
      
      public override void Initialize(BarHistory bars)
      {
         sar1 = new PSAR(bars,0.02,0.2);
         sar2 = new PSAR(bars,0.04,0.3);
         PlotIndicator(sar1, default, PlotStyle.Dots);
         TimeSeries booleanCondition = bars.Close > SMA.Series(bars.Close, 20);
         sarComposite = TimeSeries.BooleanTest(booleanCondition,sar1,sar2);
      }

      public override void Execute(BarHistory bars, int idx) { }
   }

If you want to work with a SAR just create the indicator like normal in the Initialize method, then access its value as needed in Execute. It sounds like the WL6 code just needs a slight refactor.

superticker,

Yes, I understand your point about poor programming practice in a modern language but the concept is a holdover from work I did many moons ago (way before Dion even had the concept for WL! 😉 ) that I wrote in C. I guess I need to get with the times! 😁

Glitch,
In several strategies I used information about trades to adaptively modify all sorts of indicators (yes, it was poor practice, but it worked well). I was just looking to see how the concept might translate to WL8. I understand that you designed WL to avoid bad programming practices, but for some of "ol' timers" that is a hard habit to break. 😉

You’re under no restrictions to not modify indicator values after they’re created. Just create the indicator in Initialize. In Execute you can change its value at the current index “idx” or any index.

sar.Values[idx] = someNewValue;

QUOTE:
I used information about trades to adaptively modify all sorts of indicators

But the question remains, what conceptually are you trying to do with that paradigm? My "guess" is that you are trying to account for random price volatility. If that's the case, this is how I account for that.

CODE:
   public class MyStrategy : UserStrategyBase
   {
      IndicatorBase atr15;
      const double atrFactor = 0.35;

      public override void Initialize(BarHistory bars)
      {
         atr15 = ATR.Series(bars, 15); //Chandelier Exit long for 15 trading days
      }

      public override void Execute(BarHistory bars, int idx)
      {
         if (HasOpenPosition(bars, PositionType.Long))
         {
            //sell conditions below
            double limitPrice = bars.Close[idx] - atr15[idx]*atrFactor;
            PlaceTrade(bars, TransactionType.Sell, OrderType.Limit, limitPrice, "limit Sell");
         }
         else
         {
            //buy conditions below
            double stopPrice = bars.Close[idx] + atr15[idx]*atrFactor;
            PlaceTrade(bars, TransactionType.Buy, OrderType.Stop, stopPrice, "stop Buy");
         }
      }
   }

superticker,

It turns out for day trading there is info contained in slippage which can be used successfully. I am revisiting a program I provided to a client a long time ago which I am attempting to code in WL8 as a learning exercise.

QUOTE:
there is info contained in slippage which can be used

Start a new topic and tell us about what kind a information is available in slippage. You'll need to correct for the stock's beta to factor out any contribution that index variation (S&P500?) has to do with the observed slippage. Obviously high-beta stocks will inherently slip more than others--we know that.

And the indicator itself has little to do with slippage, although some indicators might slip slightly more than others. I would leave the indicator out of this slippage model. But the slippage itself would be worth characterizing to gauge the strength of the position; we all agree with that. With the stock's beta factored out, maybe you can craft a slippage indicator; sounds doable.

All my indicators are highly adaptive. The presence and degree of slippage can tell the user a lot about the book and all of the hidden icebergs hiding there. These insights require that the adaptive indicator, which uses slippage as one of the inputs, needs to be altered. In the past instantiation I just recalculated the indicator starting a couple of dozen bars back to incorporate this info and could move on from there forward. As I see now WL8 does not make this easy in the existing framework (Dion wasn't designing WL for this type of a crazy process). This is not a limitation of WL in any way for its intended use.

QUOTE:
WL8 does not make this easy in the existing framework

I would invite you to take a look at both the SmartMoney and LastHour WL indicators. They would certainly quantitate slippage. However, their implementation is around Daily bars, and your application requires intraday bars. So they won't be appropriate for your day-trading requirements.

But I suggest studying them because you (or the WL developers) may be able to re-implement them to work with intraday bars. The WL6 docs may document them further.

It's great talking to you. Happy computing.