XLI

[pdp-brugge]

Pascal,

There is something wrong with the XLI MF graph and the XLI Realtime Graph.
Can you have a look?

Regards

PdP

[Pascal]

I corrected XLI.
Thanks for noticing it.

The XLI RT should resynchronize at the open.


Pascal

[pdp-brugge]

Pascal,

There is something that I do not understand...
In the XLX file I downloaded Saterdaymorning (with the close of Friday processed), the XLI was still "Bought".
In the file that I have downloaded this morning (with the close of yesterday processed), the XLI model is in "Cash" since 23/08 (last week Thursday).
Is this anomaly caused by the same origin as yesterday when the XLI MF graph was not showing correctly?

My second question is what is the rule that you have defined for a model to be in Cash.
The coincidence with my Combo-MF strategy (where my XLI model turned to Cash yesterday) is striking.
If not by the possible error of the corrupted XLI MF Graph, my model would have turned to Cash one trading day earlier.
I wonder what the rules are that you use.

PdP

[Pascal]

The XLI file had been corrupted by bad data that was downloaded on 8/23.
At the close of 8/22, the XLI MF was 1.32% in Bought Overbought mode.

The corrupted data pushed the MF on 8/23 to 220% which technically is still Overbought (but extremely out of common sense data.)

When you noticed the issue yesterday, I erased the data from 8/23 re-downloaded and recalculated.

The new 8/23 data showed that money moved out and the MF moved down from Bought Oversold territory.
This triggered a move to cash at the close of 8/23. Hence, the new table that automatically recalculated the correct value today.

There is however still an issue with the RT XLI system, which still carries the corrupted data. I am checking this right now.


Pascal

[pdp-brugge]

Pascal,

Is there a solution for the XLI real-time graph?

[Pascal]

It is not solved yet. We are working on improving all the XLX. In the meantime, I removed the faulty XLI RT.


Pascal