Was very pleased to see the VWAP items enter the Shared Values space a few weeks ago and delayed working on them until today. Unfortunately, I've hit a bit of a showstopper with the VWAP comparisons as the rule editor doesn't seem to have accommodated an entry in Conditions->Condition Type in order to compare previous values to the current value. The new book% entries are there and it would make sense to also include the VWAP entries here too.
v1.51.2 ??
[edit 1] - created a workaround using a 3rd stored value to take the current vwap... but would still be a nice inclusion
[edit 2] - dropdowns for storing value and comparing value added
VWAP - as a condition
You should be able to do the calculations you need directly between the stored values themselves, using the plus, minus, divide & multiple options.
ie, If you want to compare VWAP now against VWAP previously stored, then VWAP now will first need to be put in it’s own stored value and then compare value A against value B, this would work out quicker and also save the need for continually adding to the conditions area as new SV set comands are added.
There is an example here not using VWAP but its the same principal
viewtopic.php?f=50&t=16754]
ie, If you want to compare VWAP now against VWAP previously stored, then VWAP now will first need to be put in it’s own stored value and then compare value A against value B, this would work out quicker and also save the need for continually adding to the conditions area as new SV set comands are added.
There is an example here not using VWAP but its the same principal
viewtopic.php?f=50&t=16754]
thanks - this is what i ended up doing, tho was monitoring min/max and current... i can deal with the current, but am unable to use conditions to set the min/max as i'm unable to compare them.Dallas wrote: ↑Wed Oct 10, 2018 4:51 pmYou should be able to do the calculations you need directly between the stored values themselves, using the plus, minus, divide & multiple options.
ie, If you want to compare VWAP now against VWAP previously stored, then VWAP now will first need to be put in it’s own stored value and then compare value A against value B, this would work out quicker and also save the need for continually adding to the conditions area as new SV set comands are added.
There is an example here not using VWAP but its the same principal
viewtopic.php?f=50&t=16754]
after a few tries, i'm unable to arrive at the conditional logic i was after. i think that the VWAP included in the Value A/Value B conditons (in keeping with the other stored values that can be saved) is the only way i can do this. I also think for consistency, these values should be in those conditions also as the book% and volume% are included - i.e. anything that can be stored, should have a comparative equivalent 
If you want to PM me with what you're looking to do I'll have a look for youjimibt wrote: ↑Wed Oct 10, 2018 5:03 pmafter a few tries, i'm unable to arrive at the conditional logic i was after. i think that the VWAP included in the Value A/Value B conditons (in keeping with the other stored values that can be saved) is the only way i can do this. I also think for consistency, these values should be in those conditions also as the book% and volume% are included - i.e. anything that can be stored, should have a comparative equivalent
altho i use the comparison of current (against min/max) using value a->value b, it does work, but just feels a bit convoluted. will pm the thinkingDallas wrote: ↑Wed Oct 10, 2018 5:13 pmIf you want to PM me with what you're looking to do I'll have a look for youjimibt wrote: ↑Wed Oct 10, 2018 5:03 pmafter a few tries, i'm unable to arrive at the conditional logic i was after. i think that the VWAP included in the Value A/Value B conditons (in keeping with the other stored values that can be saved) is the only way i can do this. I also think for consistency, these values should be in those conditions also as the book% and volume% are included - i.e. anything that can be stored, should have a comparative equivalent
I've also started comparing VWAPs as a condition, but from observation it doesn't appear that the original stored VWAP is adjusted for known non-runners. Can we have confirmation as to whether or not any adjustment is made, since a reasonably short priced non-runner will have a large impact on already stored VWAPs?
No, no adjustment would be made.
Any value, once stored, is just a number. Considering how one value can be derived from another and manipulated with percentages, offsets, multipliers, rounding etc then it would be far too complicated to retropectively adjust for non-runners.
actually happens more often than you think. could be related to a rider getting thrown, a runner with a heavy sweat that just won't settle etc, etc.
as the complexity to backtrack would be just too much (without using some sort of memoized functional dictionary), i think the only way to figure this out would be to do a scan across the runners periodically to see if they were still producing odds. alternatively, BA could add an additional attribute to the selection that provided a datetime of withdrawal. this would be null for runners that were still in the race. you could then use this timestamp (if it appeared) to determine if a late withdrawal voided further examination of the race (this of course would require an additional condition to compare against - i.e. current time!!).
[edit] - on further reflection, you could simply have a datetime stamp at market level that indicated *time of last runner withdrawal*.
The last 10 minutes is irrelevant if the N/R was taken out prior to that and you were measuring VWAPs during the earlier time period. In any case, I can see that it would be almost impossible for BA to accurately reflect the impact of N/Rs on VWAPs.