Hi, Would you please consider this for future...
On certain conditions Ie Historic fixed odds...when comparing one parameter (ie LTP) with X Seconds ago, it seems that you can only select above 1 second..which is a lifetime inplay..
Would it be possible to have this stepped down (to as low as 0.1 second?) I know the program may trip over itself, but if 0.1 is too low then maybe 0.2 with 0.1 increments?
Thanks
regards
Peter
Suggestion Please
peter, i get around this limitation by using stored values inside a rule (actually, a rule duo). i populate the stored value with the LTP and have it refreshing at 0.25 seconds.
i then query this inside a second rule (set at a 0.50 second refresh) to compare the difference of the stored value versus what the current LTP for the selection is.
i encountered this issue a while back and used this to overcome the limitation. CAVEAT it only works inside the bounds of the 2nd rule window refresh, so no way to compare beyond that. you could of course vary the timings on the two rules using the double proportion as required (0.25 vs 0.5 in my case, potentially 0.1 and 0.2 for the second rule in your case).
pm me if you need a cut down example.
i then query this inside a second rule (set at a 0.50 second refresh) to compare the difference of the stored value versus what the current LTP for the selection is.
i encountered this issue a while back and used this to overcome the limitation. CAVEAT it only works inside the bounds of the 2nd rule window refresh, so no way to compare beyond that. you could of course vary the timings on the two rules using the double proportion as required (0.25 vs 0.5 in my case, potentially 0.1 and 0.2 for the second rule in your case).
pm me if you need a cut down example.
Hi Jim
Thats a good idea.
I did have an earlier version whereby I set a signal first, then included that signal within the conditions, but it was too slow and I kept missing what I was after.
I didn't think of stored values, so I will take a look at that too.
(Having said that; I think the BA team might be able to implement the above changes relatively easy too)
Thanks Jim
regards
Peter
Thats a good idea.
I did have an earlier version whereby I set a signal first, then included that signal within the conditions, but it was too slow and I kept missing what I was after.
I didn't think of stored values, so I will take a look at that too.
(Having said that; I think the BA team might be able to implement the above changes relatively easy too)
Thanks Jim
regards
Peter
Historical records are stored every half second (best three prices on each side + volume traded and LTP). Storing more values or storing more frequently would means that the application would soon run out of memory. It's not just the current market that is building historical records, it is everything that is loaded into Guardian and allowed to refresh. Of course there are always optimisations that could be made, like storing more frequently in the short term and pruning/combining data as it gets older, but that's quite a bit of work. That idea has been logged for a while, but there hasn't been much demand for such an enhancement, so it is not something that is currently being worked on.
OK thanks, I only do the inplay, but I understand how much data this entails once you start incorporating everything in guardian too.
Thanks for the reply
Regards
Peter