- ago
I am coding a strategy using the new Synthetic Option methods and noted some unexpected exit signals. To troubleshoot, I compared the crossing signals on the chart to the debug output.

The first thing I noticed is that the debug tab is organizing the event under a similar but incorrect underlying symbol. It's placing the BABA underlying signal under BA, and UNG under U. Both BA and U are real symbols. This is not just a cosmetic issue, however, as the code is using SMA1 and SMA2 values from BA and U as the values shown below match their charts.

Even more strangely, while BA is a symbol in my dataset, U is not. I don't know how the SMA1 and SMA2 values for U are coming from, but it appears they might be accurate for that underlying.

I haven't noticed anything like this before and don't know if this is related to using Synthetic Options or something more general.

QUOTE:
---BA---
7/13/2023 Signal to Close Position
7/13/2023!BABA231020C90 Death Cross SMA1 = 212.78 SMA2 = 212.94


QUOTE:
---U---
8/11/2023 Signal to Close Position
8/11/2023!UNG231020C10 Death Cross SMA1 = 42.66 SMA2 = 42.71
0
368
8 Replies

Reply

Bookmark

Sort
Glitch8
 ( 12.53% )
- ago
#1
Can’t really guess about what’s happening here without seeing the strategy code.
0
- ago
#2
QUOTE:
Even more strangely, while BA is a symbol in my dataset, U is not. I don't know how the SMA1 and SMA2 values for U are coming from, but it appears they might be accurate for that underlying.


This was an error on my part. I didn't realize that U is indeed one of the Dataset symbols.
0
- ago
#3
As further evidence of the premise stated here, I removed symbols BA and U from Dataset, and re-ran backtest. BABA and UNG correctly traded based on their symbols.
1
Glitch8
 ( 12.53% )
- ago
#4
This looks like a bug in your (pretty complex) Strategy. Cone is taking a look now.
0
Glitch8
 ( 12.53% )
- ago
#5
Specifically, it's your substring matching logic.

CODE:
         pos = OpenPositionsAllSymbols.Where(p => p.Symbol.Substring(1, symLen) == bars.Symbol                || p.Symbol.Substring(0, symLen) == bars.Symbol).FirstOrDefault();


So yeah, if there is no BA option position then the code will still match an existing BABA option position.
0
Cone8
 ( 6.17% )
- ago
#6
Try changing that line to this.

CODE:
pos = OpenPositionsAllSymbols.Where(p => OptionsHelper.ParseSymbol(p.Symbol).Item1 == bars.Symbol).FirstOrDefault();

Item1 is the Underlier symbol found in the option symbol. It will work for all option formats. See the QuickRef for OptionsHelper.
0
Cone8
 ( 6.17% )
- ago
#7
It just occurred to me that you need to make sure it's an option symbol, otherwise the ParseSymbol would thrown an exception. For your purpose, probably as long as the symbol length is more than 8 characters. you can use OptionsHelper.ParseSymbol.

CODE:
pos = OpenPositionsAllSymbols.Where(p => (p.Symbol.Length > 8 && OptionsHelper.ParseSymbol(p.Symbol).Item1 == bars.Symbol)).FirstOrDefault();

Probably it would be more useful just to return an "String.Empty" for the underlier symbol if it couldn't be parsed as an option.
I'll make that change for the future.
0
- ago
#8
Thank you, Cone & Glitch. It had just dawned on me that my Lambda expression was a possible cause of this problem, and I proved it, but I didn't know how to fix it. I was just starting to search for something like the parser method.
0

Reply

Bookmark

Sort