I’ve changed the first line adding 1 to each hour because otherwise ProOrder wouldn’t take the right hour frames into account. Probably because I’m on a different time frame on PRT, but it doesn’t seem to matter really.
I’ve used it on the DAX30 and I have checked around 20 occurrences and it works like a charm… except on one day.
On August 5, 2020, from 9 am to 13 (so 8 to 12 with the normal time frame), the pivot point is supposed to be 12 658,53 but the code’s calculation makes it 12 656,27.
Previous close is 12682, previous high is 12688,3 and previous low is 12605,3.
It does the same from 5 pm to 9 (so 4 pm to 8 on a normal time frame) on the same day!
You may try it out for yourself with this bit of code :
(don’t forget to change the first line depending on your time frame)
Full code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
//************************************
// Définition des paramètres du code
defparamCumulateOrders=False// Cumul des positions désactivé
// Empêche le système de placer des ordres pour entrer sur le marché ou augmenter la taille d'une position avant 8H
noEntryBeforeTime=080000
timeEnterBefore=time>=noEntryBeforeTime
// Empêche le système de placer des ordres pour entrer sur le marché ou augmenter la taille d'une position après 22H
noEntryAfterTime=220000
timeEnterAfter=time<noEntryAfterTime
// Empêche le système de placer de nouveaux ordres le samedi ou dimanche
We must grapher the variables of the pivot: hhigh + llow + cclose, and see which one is wrong. If the result is not good, we analyze the calculation and by going up like that you will find the reason for the bad result.
Hey thx for your help, I should have thought about it.
So for both Pivot Points, the mistake is that ProOrder doesn’t use the correct hhigh.
To calculate the PP from 9 am to 13, it uses the hhigh from the candle preceding the closing candle even if the high of the closing candle is higher. For example, with a 2-minute timeframe, it’ll take into consideration the candle from 08:56 to 08:58 instead of the candle from 08:58 to 09:00
To calculate the PP from 5 pm to 9, ProOrder uses the hhigh from the candle preceding the opening candle. For instance, with a 2-minute timeframe, it’ll take into consideration the candle from 12:58 to 13:00 instead of using the candle from 1:34 pm to 1:36.
It might seem that ProOrder’s calculation is always one candle late, meaning for example that it uses the 8:58 to 12:58 timeframe instead of the 09:00 to 13:00 timeframe to get its data. But it collects the correct data for cclose, which means it does include the last candle. Would it mean that it doesn’t include the last candle only to get the hhigh data (and maybe the llow too)?
Not sure what to do with that… If ever you have any ideas, please let me know.
Hey, it has had no effect. Either on hhigh values or llow values. Cclose hasn’t changed either though.
So I’ve checked a few other occurrencies and there’s also a discrepancy between the actual llows and the llows that ProOrder uses.
For example, on August 26 from 9pm to 1am (8pm to 0pm on a normal timeframe), ProOrder uses the llow from 4:58 to 5:00 when it should only consider the lows from 5:00 to 9:00 to make its calculations.
There are other similar examples the same day.
In view of the examples given above and the new ones, it leads me to assume that ProOrder (or the code) does use the correct timeframe to collect the cclose but does not to collect the hhigh and llow. It is even more strange that, when using the graph command, all values change at the same time, between the last candle of each 4-hour period.
.
