Introducing cricodds: Match Odds and Analysis

[weldone]

... If you bet for a win you still lose 100% of your bet on a nr/tie ...

no

at least not in the 4 betting sites where I am active

 

[viriya]

no

at least not in the 4 betting sites where I am active

Betfair is like that afaik.

 

[weldone]

Also, why are there no 2nd innings records with exactly 50 overs remaining? (it starts from 49 in your site - should also include lunchtime data if possible)

 

[viriya]

This sounds like a good idea, probably will improve odds with big enough similar scenarios already and worsen odds for those with limited data. But the odds calculated when there is limited data is questionable anyway so probably a worthwhile trade.

I'll test this out and check which setup gives the better odds historically and report back.

 

[weldone]

Betfair is like that afaik.

maybe but not in bet365, williamhill, betway and boylesports

'No result' gives your money back, tie is considered as half-win

..unless it's a test match where draw is an option

 

[viriya]

Also, why are there no 2nd innings records with exactly 50 overs remaining? (it starts from 49 in your site - should also include lunchtime data if possible)

This is a function of the over comparison data gathering process I think - will check this as well.

 

[viriya]

Because more than the teams, the chances are affected by the exact batsmen who are playing, the exact batsmen who are to come next (i.e. batting order) and which bowler has how many overs left. In fact, you may find a way to link this with your player current ratings. But that's way too much work I guess.

Also another point is that even though you are right in that just using team ratings isn't that precise because it doesn't take match situation into account, I've found that the adjusted odds perform better than the raw odds when tested historically. So it's not entirely useless.

 

[weldone]

I've found that the adjusted odds perform better than the raw odds when tested historically.

Of course, but I'd rather take the raw odds and adjust that in my mind based on the batsmen, bowlers, pitch etc.

 

[viriya]

Of course, but I'd rather take the raw odds and adjust that in my mind based on the batsmen, bowlers, pitch etc.

But has your mind been backtested?

 

[weldone]

But has your mind been backtested?

If I didn't have reason to trust my mind, I wouldn't be active in this field by now.

Anyways, next question: rather than a pre-set deviation of results being considered for a particular filter, is it possible to select the deviation?
Example: Currently if I select 140 needed from 20 with 3 wickets then the results automatically select (140+-some %age) runs from (20+- some %age) overs with 2-4 wickets.
Can't we have 6 drop-downs in stead? (say I need to know the scenario 145-155 runs from 19-21 overs with 2-3 wickets exactly)

 

[viriya]

Anyways, next question: rather than a pre-set deviation of results being considered for a particular filter, is it possible to select the deviation?
Example: Currently if I select 140 needed from 20 with 3 wickets then the results automatically select (140+-some %age) runs from (20+- some %age) overs with 2-4 wickets.
Can't we have 6 drop-downs in stead? (say I need to know the scenario 145-155 runs from 19-21 overs with 2-3 wickets exactly)

Yes, this is the logical next change to the input options. I didn't add it right away to make the preliminary setup doable over the weekend. Definitely something that will be added (first in the list actually). Only problem I foresee is finding screen space.

 

[weldone]

Is there a way to download the results for a query in a csv file or something?

 

[viriya]

Is there a way to download the results for a query in a csv file or something?

Need to check.. not sure off the top of my head.

 

[viriya]

yea should be unique matches only for one query (can't do anything about sample size issue when the issue is genuine)

..should take the closest scenario from each match (i.e. where the number of overs matches exactly)

This is done. Only unique matches are used now. When multiple similar scenarios from the same match are found the average values are shown (runs, overs, wickets), leading to decimals in some cases. I pushed the change in since my backtests also showed that it slightly improves the odds as well.

Nice call on that.

 

[weldone]

This is done. Only unique matches are used now. When multiple similar scenarios from the same match are found the average values are shown (runs, overs, wickets), leading to decimals in some cases. I pushed the change in since my backtests also showed that it slightly improves the odds as well.

Nice call on that.

better - though I still think it's better to take case where wickets (if not then 2nd choice number of overs) matches exactly, rather than taking average

 

[viriya]

better - though I still think it's better to take case where wickets (if not then 2nd choice number of overs) matches exactly, rather than taking average

It doesn't really affect the odds - just the values you see in the table. I thought it was a good way to incorporate all the relevant scenarios. Also that allows me to avoid picking wickets or runs or overs as the matching factor. Althought I should probably round the numbers to the nearest integer to avoid it looking nonsensical.

 

[weldone]

It doesn't really affect the odds - just the values you see in the table.

Right of course, that was a brain-fade from me

 

[weldone]

If you don't include the 6 different filters thingy anytime soon then it's worthwhile changing the limits purely on the basis of RRR

Needing 35 from 9 overs with 4 wickets in hand is very very VERY different from needing 43 runs from 7 overs with 3 wickets in hand !!!!!!

 

[viriya]

If you don't include the 6 different filters thingy anytime soon then it's worthwhile changing the limits purely on the basis of RRR

Needing 35 from 9 overs with 4 wickets in hand is very very VERY different from needing 43 runs from 7 overs with 3 wickets in hand !!!!!!

Yea I actually expand the range a bit near the end of chases because of insufficient data issues. This is a good example of one that shouldn't be included. I might revert that <15 overs left method change come to think of it.

 

[weldone]

Yea I actually expand the range a bit near the end of chases because of insufficient data issues. This is a good example of one that shouldn't be included. I might revert that <15 overs left method change come to think of it.

Another reason why I think it should be based on RRR deviation:
For any query with 50-46 overs left, the upper limit goes to 49 only but the lower limit goes to (specified-5). So, for a '260 required from 49' scenario, we have a '275 required from 44' scenario but there's no '245 required from 54' scenario to counter it [the '245 required from 44' or the '245 required from 49' doesn't really counter the '275 required from 44' - if you see what I mean]