-
Comment -
fig..str....from spain? no english?Comment -
This is probably the most valuable thread here on SBR. Keep up the good work guys!Comment -
jmom how about this mlb for the first month:
o:run line>170 and line>100 and season=2013 and month=4Comment -
tomorrow : A and P:ats margin <= -10 and P:season = season and P:H and season > 2012
rockets ,sun, netsComment -
im not so sure about this..... i mean it's had a great 13/14 season. but if u roll back to 2006, there are only 2 other seasons which barely break the 50% mark, the rest were a tad below even. just my 2 cents worth. a good situation should yield similar results every season imoComment -
This is something I always have difficulties with. Do you follow a short-term trend that's working well or do you stay away if it hasn't been that good in the past?
If you like playing totals:
season > 2002 and 11 > p:M1 > 4 and p:M2 < 0 and p:L and rest = 0 and o:rest > 0Comment -
this is what i believe. trends, based on situations SHOULD NOT vary too much every season. if it does, the situation you based your trend on is flawed IMO.. take the revenge situation trend that is hitting an insane 70% this season, if its a mindset, it should apply EVERY season. no team is going to suddenly jump into a new season and decide to changeup some mindsets. just my humble opinion, don't mean to offend anyoneComment -
Question about using any of these situations: if it's a great ATS situation, should we ONLY play the "picks" if the spread matches (or is better) than posted? What if our best available spread is 1/2 a point "worse"? I kind of assume "don't play a worse line", but perhaps there's a very small range?
Just looking for how you guys use the info...Comment -
The public brought down the GS/Chi total pretty quickly, then quickly bought it back up to 187 around the time of this post. Going as low as 186, a 2.5 point drop from the open. I think the UNDER is the play all here; based on the sdql searched I performed. Read all these carefully.
Under is 8-1 L9 when GS scored 100+pts in their last game (18-7-1 dating back to Dec 06 2013)
Under 7-3-1 This Season when GS won their previous game when they scored 100+pts
Under 6-2 This season when gs won their previous game when they scored 100+pts and their next game (after Bulls) is on the road.
Under is 5-0 when GS won their previous game in which they scored 100+pts and they’re facing the Bulls.
Under is 4-1 this season when GS won their previous game which was on the road, and also won the game before than which was at home. 9-3 on the under last 12 scerarios
Under is 7-1-1 last 9 games when GS is coming off a game when they allowed their opp to shoot 40%. (6-2 on the under when GS won the previous game on the road allowing opp to shoot 40%)
Under 7-3 This season when GS is on the road and their opp scored 100+pts their previous game
The 1st play showed support of line movement; so does this one. Last night I looked over a total, and when I woke up, it rose four points! Pretty big within a 6-7 hour time. I'm talking the Atl/Bos game. I'm pointing these out, as I'm just sharing. Read these carefully.
Over is 7-1 Since Mar 25 2013 when Atl previous game they scored 100+pts, with their next two games on the road. 5-1 this season. 15-4 since Apr 06 2012.
Over is 9-2 This season when Atl scored 100+pts in their last game and lost
Over is 30-16 This season when their opp lost their previous game by 10+pts (5-0 L5)
Atl is 1-7-1 ATS This season when their opp lost their previous game by 10+pts
A surprising play; one I may lay some coin on. Lakers +11.5, hopefully 12 by the closing line. The underline trends are what make me consider this bet highly. Read carefully.
Lak 6-1-1 ATS L8 scerarios (Feb 2009) when playing a team on 3 days rest that lost their last game
Grizz 4-11 ATS This season when coming off an away game, playing at home
Grizz 5-13 ATS This season when playing at home and their opp previously scored 95+pts. 1-4 ATS L5. Over 11-7; 6-2 L8
But I think this game goes over no problem. Trends below: Read carefully.
Lak
Over is 8-3 L11 scerainos when L.A managed to score 95+pts in their previous game and lose
Over 16-7-2 Since Jan 3 2014 when L.A. managed to get blown out by 20pts or more (29-24-2 on the season, 43-34-2 over the last 2 seasons)
Over is 4-0 this season when Lak playing opp on 3 days rest
Mem
Over 8-1 L9 scerinaros when losing their last game, which was on the road, playing on 3 days rest
Over 7-3 L2 seasons when playing on 3 days rest
Over 6-1 L7 scerinaros when losing their last game by three, but winning their previous two games before that which were at home
I have the 'codes' for all these, if any of you doubt these are true. I do hours of research a night, I'll never sell my stuff. Just enjoy posting. ThanksComment -
Very true.
I figured when I created the thread that questions would come up regarding how we judge that a system or scenario is worth adding to the collection and wagering hard earned money on, and the short answer is...everyone is different.
For me, I prefer to play far fewer scenarios and am constantly whittling them away to keep only what I feel are the very best possible plays. I also prefer to only play league-wide systems versus the more popular team trends, because team trends are volatile and can change rapidly. That doesn't mean team trends aren't valid, it's just what I prefer as a 'lazy' bettor.
So I can only tell you how I personally do it, and what my own philosophy is. I am not recommending you follow these requirements per se, they're just here to serve as an example of how I try to filter out the noise from the actual signal. I apply the following standard to every NBA query I find, create, or tinker with:
NBA SYSTEM CREATION PARAMETERS - (I force myself to stick to all these, hurts to lose a query when it's SO close but that's the discipline)
1. SYSTEM MUST BE BASED ON A MINIMUM AVERAGE OF 6-7 PLAYS PER SEASON FROM 2006+ (50 minimum)
Any results below that level of frequency make me suspicious, always remember that the smaller the sample size the more likely the results are just random. This doesn't mean that smaller trends aren't valid, far from it, but just make sure you have other validation techniques in place like the ones I'm about to list to compensate for the smaller snapshot.
2. SYSTEM MUST HAVE AN ATS WIN RATE OF 45%+ WITH -5/+5 POINT PLEASER HIT APPLIED
To do this, I take the ATS win % and apply a -5 or +5 point 'pleaser' to it in a negative way, effectively making the line 5 points 'worse' than it actually was, then see how it impacts the wins/losses/net. If a system still 'wins' at 45% or more after taking a 5 point line hit, it tells me that the scenario might be stronger at keeping bad beats away, along with the randomness of small ats margin wins. Lately I've moved this figure up to 50%, meaning the system still breaks even minus the vig despite a massive 5 point line change away from it.
3. SYSTEM MUST HAVE MINIMUM WIN RATES OF 62.5% FOR BOTH 2006-2009 AND FROM 2010 TO CURRENT
This one is simple as to the 'why', it's what we all do every time we load up a query...to evaluate the ATS win rate. Win rate isn't everything, as we'll see the volume of plays combined with the win rate is what is truly critical, but it's the starting point. If the win rate isn't high enough for your base query the tendency is to filter it like crazy until it gets the 'right' number...which can be dangerous as it leads to overfitted results (explained in #6 below).
4. SYSTEM MUST HAVE AN AVERAGE ATS WIN MARGIN OF 3.0 POINTS OR HIGHER
I take a snapshot of whatever system I'm working on from 2006 to 2013, and not only must the results fit within the win rates of #3 above, but they must an average ATS margin of 3.0+ or higher with those win rates. Again, this is like #2, where I'm trying to see through the systems that just 'got lucky' the past few years, barely covering the spread through randomness, versus systems where there is actual EV of +3 points or more versus the line for whatever hopefully-logical reason/circumstance.
5. SYSTEM MUST HAVE A Z-SCORE OF 3.00+ FOR 2013-2006 PERIOD
Z-Scores or Z-Values are another useful filter that can be applied to help you see whether a system is just lucky or a true consistent play. To calculate a Z-Score, first take the total of wins+losses for the system and get the square root of that total number. Now subtract losses from wins and divide that number by the square root you determined a step earlier. You should get a number between 1.00 and 5.00, or close to it for the average NBA query that wins at 60%+. I choose to only play systems that achieve a 3.00 Z-Score from 2006-2013, because it seems to be a nice break point. If you get confused by this just Google 'Z-score' or 'Z-value' and there are plenty of auto-calculators that pop up to help.
6. SYSTEM MUST HAVE A LOGICAL DEFINITION TO EXPLAIN/JUSITFY RESULTS
One other extremely misleading and dangerous problem that the SDQL lends itself to is called "Overfitting". You can Google 'overfitting' or the other term that is sometimes used in its place ("data mining"), but the end result is that you're plugging in variables and filters to get a desired win/loss rate for the database and assuming that because it provided a "75-25 win/loss rate" that it "must" be real...when there isn't a logical reason behind the results. It's got to "make sense" in other words, like say two teams having 0 days rest playing each other that have poor defenses with average points given up of 100+ on the season which could make the Over bet a solid one.
IT'S ALL STILL A CRAPSHOOT
All of these examples are ways I try to 'protect' myself from getting too excited and following a query that looks like 24KT but winds up as fools' gold from the point I discover or build it onward. As time goes on I'll likely continue to add to the barriers based on experience and trying to figure out 'why' a system goes bad or doesn't work as it has in the past. But in reality anything can change overnight, and a bulletproof system that paid off for multiple seasons can be obsolete after a rule change or schedule change or any other number of variables.
Be smart, try to filter out the junk, and refine your process constantly in order to achieve better results over time.
Last edited by Mako-SBR; 02-26-14, 03:54 PM.Comment -
quoted for truth! well saidVery true.
I figured when I created the thread that questions would come up regarding how we judge that a system or scenario is worth adding to the collection and wagering hard earned money on, and the short answer is...everyone is different.
For me, I prefer to play far fewer scenarios and am constantly whittling them away to keep only what I feel are the very best possible plays. I also prefer to only play league-wide systems versus the more popular team trends, because team trends are volatile and can change rapidly. That doesn't mean team trends aren't valid, it's just what I prefer as a 'lazy' bettor.
So I can only tell you how I personally do it, and what my own philosophy is. I am not recommending you follow these requirements per se, they're just here to serve as an example of how I try to filter out the noise from the actual signal. I apply the following standard to every NBA query I find, create, or tinker with:
NBA SYSTEM CREATION PARAMETERS - (I force myself to stick to all these, hurts to lose a query when it's SO close but that's the discipline)
1. SYSTEM MUST BE BASED ON A MINIMUM AVERAGE OF 6-7 PLAYS PER SEASON FROM 2006+ (50 minimum)
Any results below that level of frequency make me suspicious, always remember that the smaller the sample size the more likely the results are just random. This doesn't mean that smaller trends aren't valid, far from it, but just make sure you have other validation techniques in place like the ones I'm about to list to compensate for the smaller snapshot.
2. SYSTEM MUST HAVE AN ATS WIN RATE OF 45%+ WITH -5/+5 POINT PLEASER HIT APPLIED
To do this, I take the ATS win % and apply a -5 or +5 point 'pleaser' to it in a negative way, effectively making the line 5 points 'worse' than it actually was, then see how it impacts the wins/losses/net. If a system still 'wins' at 45% or more after taking a 5 point line hit, it tells me that the scenario might be stronger at keeping bad beats away, along with the randomness of small ats margin wins. Lately I've moved this figure up to 50%, meaning the system still breaks even minus the vig despite a massive 5 point line change away from it.
3. SYSTEM MUST HAVE MINIMUM WIN RATES OF 62.5% FOR BOTH 2006-2009 AND FROM 2010 TO CURRENT
This one is simple as to the 'why', it's what we all do every time we load up a query...to evaluate the ATS win rate. Win rate isn't everything, as we'll see the volume of plays combined with the win rate is what is truly critical, but it's the starting point. If the win rate isn't high enough for your base query the tendency is to filter it like crazy until it gets the 'right' number...which can be dangerous as it leads to overfitted results (explained in #6 below).
4. SYSTEM MUST HAVE AN AVERAGE ATS WIN MARGIN OF 3.0 POINTS OR HIGHER
I take a snapshot of whatever system I'm working on from 2006 to 2013, and not only must the results fit within the win rates of #3 above, but they must an average ATS margin of 3.0+ or higher with those win rates. Again, this is like #2, where I'm trying to see through the systems that just 'got lucky' the past few years, barely covering the spread through randomness, versus systems where there is actual EV of +3 points or more versus the line for whatever hopefully-logical reason/circumstance.
5. SYSTEM MUST HAVE A Z-SCORE OF 3.00+ FOR 2013-2006 PERIOD
Z-Scores or Z-Values are another useful filter that can be applied to help you see whether a system is just lucky or a true consistent play. To calculate a Z-Score, first take the total of wins+losses for the system and get the square root of that total number. Now subtract losses from wins and divide that number by the square root you determined a step earlier. You should get a number between 1.00 and 5.00, or close to it for the average NBA query that wins at 60%+. I choose to only play systems that achieve a 3.00 Z-Score from 2006-2013, because it seems to be a nice break point. If you get confused by this just Google 'Z-score' or 'Z-value' and there are plenty of auto-calculators that pop up to help.
6. SYSTEM MUST HAVE A LOGICAL DEFINITION TO EXPLAIN/JUSITFY RESULTS
One other extremely misleading and dangerous problem that the SDQL lends itself to is called "Overfitting". You can Google 'overfitting' or the other term that is sometimes used in its place ("data mining"), but the end result is that you're plugging in variables and filters to get a desired win/loss rate for the database and assuming that because it provided a "75-25 win/loss rate" that it "must" be real...when there isn't a logical reason behind the results. It's got to "make sense" in other words, like say two teams having 0 days rest playing each other that have poor defenses with average points given up of 100+ on the season which could make the Over bet a solid one.
IT'S ALL STILL A CRAPSHOOT
All of these examples are ways I try to 'protect' myself from getting too excited and following a query that looks like 24KT but winds up as fools' gold from the point I discover or build it onward. As time goes on I'll likely continue to add to the barriers based on experience and trying to figure out 'why' a system goes bad or doesn't work as it has in the past. But in reality anything can change overnight, and a bulletproof system that paid off for multiple seasons can be obsolete after a rule change or schedule change or any other number of variables.
Be smart, try to filter out the junk, and refine your process constantly in order to achieve better results over time.Comment -
Wonderful post mako. Do you only do NBA?Comment -
mako Wished i had that much discipline. But hey, I do well.
Comment -
-9.5<=line<=-3.5 and tA(points)>=102 and 102>=oA(o: points)>=98 and wins+losses>=42 and p: points+po: points>=205 and pp: points+ppo: points>=205 and ppp: points+pppo: points>=205 and pppp: points+ppppo: points>=205
Need to eliminate spaces for emoticon..(freaken annoying as hell)
Let me know if anyone needs a translation.Comment
