I knew you would get the sdql, mako. 
I was hoping others would as well.
I was hoping others would as well.
-
Comment -
"We want to fade a home dog on a same season road revenge game getting blown out by 30 or more; off a road loss. Good, but with taking away rest of more than two and high dogs of more than 8.5...we have something extraordinary since 2002."
HD and p:AL and P:AL and P:margin<=-30 and rest<=2 and line<8.5
It was fade the Cavs.Last edited by cash$bro91; 03-05-14, 12:44 AM.Comment -
guys what is the sdql for this :
This matchup fits into a system to play on road teams like the Clippers when they are coming off a home win by 10 points or more and have won 60 to 75 percent of their games on the season, and they are facing a team that has won 51 to 60 percent of their games on the year. This system has a 47-23 (67%) ATS record over the last five seasons.Comment -
Of course, those purely ATS performance based trends are not completely useless and without any value whatsoever. However, I believe that one must look on them as an indication that bookies frequently over-estimate or under-estimate a particular teams or situations, and from there on one must search for factors, what made bookies set the line which was way off.
Please, everyone, do not take this as a personal insult, it's just that there are so many so called "touts" who base their picks on wild trends which contain little logic or none of it.
And, guys, I'm really trying hard to put any input of my own in finding some great value and contribute to this thread.Comment -
2-1, and thanks to J's late quiz entry today, 3-1.
This is is why I enjoy SDQL research, because of those 4 games if I were left to my own capping abilities I would have picked 3 of them wrong.
Comment -
Anything today fellas? Thank you again for this thread, best of SBR.Comment -
I would love to hear you guy's thoughts on this sdql for the over play:
tA(points)>=102 and oA(o: points)>=100 and op:dps<=-10 and 215>total>200 and rest=0
and got this at a different angle but still pointing over
p: points+po: points>205 and pp: points+ppo: points>205 and 103>oA(o: points)>=100 and rest=0 and 215>total>200 and op: points<100Last edited by cofaga; 03-05-14, 06:24 PM.Comment -
I like the second one better but wouldn't play either. These are examples of queries that are frustratingly close but ultimately fail on a few fronts. In these two case the low sample sizes combined with a little inconsistency from season to season would make me move on. But they're not bad, I doubt anyone would lose money on them over time...but I doubt they'd make money either.
Good attempts cofaga, keep it up.
That's the only one I had a game come up for today, nothing else was worth it in terms of value.
Last edited by Mako-SBR; 03-05-14, 08:02 PM.Comment -
New one, no play with it today but it passes the tests for consistency over the years, Z-value (win % + volume), good ATS margin, and decent logic:
HF and WP>=72 and game number>=25 and p: LF and line<=-9.5 and total>=187.5
I'll explain a bit more about how it came about for those still learning "why" we choose to pair up certain filters but not others when tinkering with queries.
The logic is that you're playing the elite team (72+ win % on the season) who is a heavy home fav (laying 9.5 points minimum) after the team just lost their last game also as the fav (home or away). There are tons of 'bounce back' queries and scenarios in the NBA, some work, some don't, and when you chase them in SDQL you need to be patient because it can take time to put the puzzle together properly while filtering out the noise.
For this particular one it's later in the season to make sure we're not betting in November on some fluke pretender that had a lucky hot start (doesn't begin until 25 games in or more), and since we need a shit-ton of scoring from the fav to cover that massive line we're eliminating any game where the total is below 187.5 (gets rid of some mediocre heavy dog opponents that actually show up defensively for 'big' games and lock down the fav's scoring versus the norm).
It works inside or outside of division or conference games (a lot of systems break down if a game is, or is not, a well-known division opponent, always screen for that when you feel you've found a winning query), and it allows the comfort of being a true square (you're on the same elite marquee home that the rest of the clueless public is).
That's it, pretty simple. It's not perfect but it's an example of what you're chasing with SDQL, something that only has excess filters if each of the filters fit (mostly) within the logic of the play, and something that can be applied in most circumstances within said logic.Last edited by Mako-SBR; 03-05-14, 08:08 PM.Comment -
Pacers 8 points in the 1st
Comment -
-
I've read through the manual you guys are referring to and I'm still not seeing how to use operands. I tried using the Sum feature on points (ie per quarter) to do some 1st half / 2nd half comparison, and it just errors out every time. Maybe this database simply can't provide "points scored in 2nd half when total first half points are greater than or equal to ###"?
Has anyone ever done anything along these lines or tried since I mentioned it earlier in the thread? I could really use some help here.Comment -
Is is possible to include such parameters as "team's average 3pt shooting %" (not in the past games, but current overall)?Comment -
The manual leaves a lot to be desired. The google group can be a good spot to browse and learn a lot. I believe the baseball and NFL databases are more robust and have more shortcuts than the NBA one.
I haven't ever tried to do what you are attempting, but it would be very interesting to do. As has been mentioned in this thread, a lot can be learned by trial and error.Comment -
There was an SDQL posted earlier that might give clues. Let's take a look (I'm new to this too):
H and total>205 and p:HL and po:P3-p:P3 + po:P4-p:P4>14 and season>=2010
The reason I pulled this out was it shows us the quarter operands (P1/2/3/4). However, I think where you're still stuck is analyzing games as halves... database just doesn't seem designed to. What you might end up having to do is just looking at p:P1 + P2 total > 120 (or something like that? thats not pulling anything up). Then pull up schedules for the team's prior game and looking one by 1.Comment -
Oh, believe me, there's been LOTS of trial and error.
That's why I'm reaching out...
Thanks for that reference. You might be right about at least looking at the first half and then manually going from there. That won't be TOO bad, because at least I'll have a list of games with first halves with high scoring, which is my starting point...Comment -
from google grups:
AF and line < -3 and line > -10 and Average(margin@team and season) >= 3 and p
oints > 104 and ppoints > 104 and pppoints > 104 and rest < 2 and WP > 64.1 and game number > 16
take thunder .85-29-2 (2.73, 74.6%) avg line: -6.3 Comment -
Ben posted this on the group, nice, simple, and makes sense:
A and p:AFL and 1<= rest<=2 and season>=2005
With that large a sample it's easy to use it as the basis for a wide variety of drilled down scenarios by adding filters and screwing around, etc. Filters always have to make 'sense', meaning they have to fit in with whatever logic you're basing the entire system on. If they don't, you run the risk that you're simply finding exotic win rates without those win rates carrying on in the future.196-130-7 (1.71, 60.1%)
Example of just tweaking SDQL to provide a boost to the base query, no logic at play per se, but it doesn't necessarily go against the core query's concept either:
A and p:AFL and rest in [1,2,3] and 67>=game number>=21 and 48<=WP<=80 and P:ats margin<0 and season>=2005
Now does any of the above filtering I've done mean that you're guaranteed to exceed the base query's 60% win rate?65-18-3 (4.91, 78.3%)
Nope.
In fact all you may wind up doing by drilling down like I've presented here is eliminate more than half the games you COULD have been playing on (and winning on) at that previous 60% rate, which means you actually may 'hurt' yourself by the use of filters.
You won't lose more but you won't win as much as you could have if my data-mined version of the query still performs at 60%...if my refinements don't actually improve anything within the actual system...which means you limited what could have been a much more successful system for your bankroll in the long run if you had just stuck to the less sexy 60% base query.
And that higher volume of plays at 60% might make up for the other systems you're playing every season that have begun to fall below 52.4%, because as time passes systems erode due to changes in the game, rules, scoring, etc., and you've got to have other newer or less-obsolete/higher-volume systems carrying your overall bankroll.
But you never know, and if the logic fits then you may actually improve the performance of the core system through filters, and that's why we do it. So always make sure you tinker around with base queries you find online or develop yourself, because one, it's good practice, and two, you may find stronger versions of your original idea as you play.
Last edited by Mako-SBR; 03-07-14, 03:45 PM.Comment -
After reading this thread, I decided to try this out. Very good stuff can be used if you can get enough queries together to have plays daily or as often as possible.
I believe I got one for today. Teams following a loss in which they scored less than 80 points.
SDQL: AD and p:L and points<=80 and season>=2010
SU: 11-164 (-18.68, 6.3%)
ATS: 24-146-5 (-10.09, 14.1%) avg line: 8.6
O/U: 6-168-1 (-21.51, 3.4%) avg total: 191.0
Pretty good sample size and very strong trends. Basically we are fading a team coming off a loss where they did not score 80 points because they are just 24-146-5 ATS in the next game. Additionally playing the under in those games has amazingly hit at the following rate: (168-6-1) 96.6%Comment -
Nice, that's exactly what the thread is for, introducing SBRers to SDQL, helping them learn it, and hopefully benefitting from the systems they create!
You made a mistake in that query though Jay...forgot the "p:" on the points<=80 to tell SDQL you want it to look at the team's "previous" points scored...which means SDQL is going to tell you only when a team finishes their current game and scores 80 or less in said game, and give a wildly false result.
Corrected query:
AD and p:L and p: points<=80 and season>=2010
Good job for your first attempt though, keep it up.42-164 (-8.57, 20.4%) 96-107-3 (-0.88, 47.3%) avg line: 7.7 100-101-5 (1.56, 49.8%) avg total: 191.7
Comment -
Ahhh, thanks for the correction bud. Back to the lab againNice, that's exactly what the thread is for, introducing SBRers to SDQL, helping them learn it, and hopefully benefitting from the systems they create!
You made a mistake in that query though Jay...forgot the "p:" on the points<=80 to tell SDQL you want it to look at the team's "previous" points scored...which means SDQL is going to tell you only when a team finishes their current game and scores 80 or less in said game, and give a wildly false result.
Corrected query:
AD and p:L and p: points<=80 and season>=2010
Good job for your first attempt though, keep it up.42-164 (-8.57, 20.4%) 96-107-3 (-0.88, 47.3%) avg line: 7.7 100-101-5 (1.56, 49.8%) avg total: 191.7
Comment -
P:AL and op:margin>10 and p:HW and 65>WP>o:WP and -10<=line<=-5 and H
My logic in this is taking the better team in a away loss revenge spot. Both teams coming off wins and home team is a decent favourite. If you get rid of the 65 still hits over 60% and gives you a larger sample
Any input is welcomed thanksComment
average play
