QQQ is getting close to it’s 13 week simple moving average for the first time since the end of April. The last time it crossed from above was in late February, also after about 5 months above. The short term bull case that SPY is bottoming here remains rational but shaky.

SMH and SOXL are interesting.

More or less the same chart, except the high to low loss on SOXL is 100 and SMH is 20. The losses all came in a 3 day period which was not trivial to avoid.

The algorithm looks at signals and doesn’t do subjective judgments. That’s an issue, but there is no clear way to tell it not to do that and increase returns at the same time. Personally, I don’t see this as something that requires immediate mitigation.

Anyway, assume you are long SOXL the morning after 311. The trader has a decision to sell at the negative open, that is not easy to do. If you hold it all day, that is a tough sell at the close because it has pulled back to support and has excellent chances of rebounding. Day 2 is even more difficult. The algorithm sells after day 1, it has one disastrous day but that is twice as good as buy and hold in this case which has two.

The other side is that the buy signal at 211 should be taken, and that is tough to follow, especially if the trader has just taken a substantial loss.

3 thoughts on “9/18/20 – Probable x00, Possible x30”

Hi Josef – Thank you for your work. I have no technical background, so it’s been challenging (but fun) trying to figure it out. After many nights trying to understand and reverse-engineer your strategy, I think I finally have my em13 signals matching yours (at least back to 9/1). I know trend following wasn’t active, so I’ll go back farther to check that piece, but could you confirm I’m not over-simplifying here:

The four binary digits (in order) for today’s hex character are calculated as:

The piece I'm most unsure about are the 3rd and 4th digits. I guessed my way into those calculations based on your comment "at least one of the averages is in a worse situation than yesterday relative to price". I'm not confident that my calculation of "worse' would always match yours.

Your example is close to OK, taking into account that something odd happened when you entered the comment.

I’ve been working on modifying/understanding my own underlying logic for about a week and will publish something on it soon.

Currently, WPrice – Avg is checked for positive or negative for the 8 and 4 bits. I also divide that difference by WPrice. That number is either positive or negative. I’ve also tried dividing by Avg instead of WPrice; that seems to make no difference.

The Up/Down compares todays numbers with yesterday and the 2 and 1 bits are set based on today being higher or lower.

I’m also looking at using natural logs to define the differences more accurately, that also has the advantage that a positive or negative number is produced without having to subtract. At this point, I don’t see a difference in the return stream doing that but it probably is the right thing to do.

Hi Josef – Thank you for your work. I have no technical background, so it’s been challenging (but fun) trying to figure it out. After many nights trying to understand and reverse-engineer your strategy, I think I finally have my em13 signals matching yours (at least back to 9/1). I know trend following wasn’t active, so I’ll go back farther to check that piece, but could you confirm I’m not over-simplifying here:

The four binary digits (in order) for today’s hex character are calculated as:

First Digit:

wPrice > 13dayEMA = 1

wPrice 13daySMA = 1

wPrice LN(wPrice/13dayEMA) yesterday = 1

LN(wPrice/13dayEMA) today LN(wPrice/13daySMA) yesterday = 1

LN(wPrice/13daySMA) today < LN(wPrice/13daySMA) yesterday = 0

The piece I'm most unsure about are the 3rd and 4th digits. I guessed my way into those calculations based on your comment "at least one of the averages is in a worse situation than yesterday relative to price". I'm not confident that my calculation of "worse' would always match yours.

Thanks again for sharing.

Hi Conrad,

Your example is close to OK, taking into account that something odd happened when you entered the comment.

I’ve been working on modifying/understanding my own underlying logic for about a week and will publish something on it soon.

Currently, WPrice – Avg is checked for positive or negative for the 8 and 4 bits. I also divide that difference by WPrice. That number is either positive or negative. I’ve also tried dividing by Avg instead of WPrice; that seems to make no difference.

The Up/Down compares todays numbers with yesterday and the 2 and 1 bits are set based on today being higher or lower.

I’m also looking at using natural logs to define the differences more accurately, that also has the advantage that a positive or negative number is produced without having to subtract. At this point, I don’t see a difference in the return stream doing that but it probably is the right thing to do.

Thanks so much, that clears it up for me. Appreciate you publishing your work!