NBA Stituational Bet, SDQL

[JMon]

I knew you would get the sdql, mako. I was hoping others would as well.

[Mako-SBR]

I knew you would get the sdql, mako. I was hoping others would as well.

The pick finally woke up and is killing it!

Come on guys, who is it? You can pass this one.

[cash$bro91]

"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.

[figue]

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.

[figue]

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.

[JAnthony]

Some good conversation. Some people in this thread have misinterpreted what I have said in earlier posts, so perhaps I could be doing the same thing here.

I do believe that ATS records and even ATS game results are helpful to picking the point-spread winner in games. You want to find value in a line or total. Oddsmakers can over or under-value a team due to how they are performing against the spread, and obviously straight-up.

Evaluating a team's overall ATS trend over the past 10 years is fruitless when there have been major personnel changes and different head coaches, IMO.

As stated above, SDQL isn't perfect but it is a very valuable tool. It gives you an advantage over most other cappers, but only if you know how to use it. Some services provide systems and trends for a fee. There are some touts that follow those "systems" blindly, you see them quoted in tout's write-ups all the time. Unfortunately, those systems aren't always correct or they follow very flawed logic.

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.

[Mako-SBR]

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.

[b1slickguy]

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.

I love it when school is in session!
Thanks, JMon!

[Mako-SBR]

I love it when school is in session!
Thanks, JMon!

Finally a class worth actually attending...

[FortySix]

Anything today fellas? Thank you again for this thread, best of SBR.

[azn1234]

-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.

You're playing Minnesota tonight?

[cofaga]

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<100

[JMon]

You're playing Minnesota tonight?

average play

[Mako-SBR]

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<100

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.

average play

That's the only one I had a game come up for today, nothing else was worth it in terms of value.

[Mako-SBR]

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.

[JMon]

Pacers 8 points in the 1st

[JMon]

That's the only one I had a game come up for today, nothing else was worth it in terms of value.

Me too, in average at that. No feel.

[JMon]

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.

This is really good. I saved it in my personal database. Not big on total filters in NBA, but it makes sense with HF. I saved it as is. But in my description... noted o:rest<3 and line>=-10.5

Very nice Mako

[JMon]

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.

Fig..you are going to have to learn this eventually. What can you come up with by yourself? Then we will help you out.

[figue]

Fig..you are going to have to learn this eventually. What can you come up with by yourself? Then we will help you out.

a and p:hw<10 points and wp>=60 and 75>= and op:wp>=51 and 60>=

[Wojo]

a and p:hw<10 points and wp>=60 and 75>= and op:wp>=51 and 60>=

Figue- You are close. There is a manual you can download to help you learn what needs to be capitalized.

A and p:HW and p:margin >= 10 and 75 >= WP >= 60 and 60 >= o:WP >= 51 and season >= 2008

[JAnthony]

...

[figue]

Figue- You are close. There is a manual you can download to help you learn what needs to be capitalized.

A and p:HW and p:margin >= 10 and 75 >= WP >= 60 and 60 >= o:WP >= 51 and season >= 2008

thanks buddy

[tonywayne]

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.

[JAnthony]

Is is possible to include such parameters as "team's average 3pt shooting %" (not in the past games, but current overall)?

[Wojo]

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.

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.

[Noleafclover]

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.

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.

[tonywayne]

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.

Oh, believe me, there's been LOTS of trial and error. That's why I'm reaching out...

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.

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...

[figue]

from google grups:

AF and line < -3 and line > -10 and Average(margin@team and season) >= 3 and points > 104 and ppoints > 104 and pppoints > 104 and rest < 2 and WP > 64.1 and game number > 16

85-29-2 (2.73, 74.6%)

avg line: -6.3

take thunder .

[Mako-SBR]

Ben posted this on the group, nice, simple, and makes sense:

A and p:AFL and 1<= rest<=2 and season>=2005

196-130-7 (1.71, 60.1%)

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.

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

65-18-3 (4.91, 78.3%)

Now does any of the above filtering I've done mean that you're guaranteed to exceed the base query's 60% win rate?

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.

[JayHorne3]

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%

[JayHorne3]

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%

Therefore we would be fading the Hawks tonight to take Golden State -9 and taking the under 209. Good luck!

[Mako-SBR]

Therefore we would be fading the Hawks tonight to take Golden State -9 and taking the under 209. Good luck!

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

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

Good job for your first attempt though, keep it up.

[JayHorne3]

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

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

Good job for your first attempt though, keep it up.

Ahhh, thanks for the correction bud. Back to the lab again

[cofaga]

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 thanks