[nash13]

And we are three. Will there be any others from here?

[pip2]

And we are three. Will there be any others from here?

Is anybody in that market interested in buying queries to fade? I've made some pretty good ones of those...

[pip2]

cle/mia U 1, --> -1
bos/atl O 2, --> -2
sac L vs mil 1, --> -1
ny L vs orl 2, --> +2
ny/orl U 1, --> +1
dal/ut U 1, --> +1
sa L vs det 7, --> -7
lal/por U 1, --> +1
mn/gs U 1, --> +1
gs L vs MN 1, --> +1
tor L vs wsh 1, --> +1
tor/wsh O 1, --> -1
hou W vs lac 3, --> -3
hou/lac O 1 --> -1

total -8

running total 0

[nash13]

what do you mean by fading? show one example please where you think it was a trend to back/tail first and now to fade. i am a bit confused about your approach. thank you.

[pip2]

what do you mean by fading? show one example please where you think it was a trend to back/tail first and now to fade. i am a bit confused about your approach. thank you.

Nash, I haven't gotten to the point of trying to single out queries. I just have a big pile of query results from the past month and a half, and most days the losers outnumber the winners, and while there are very few days (perhaps none) where the winners vastly outnumber the losers, there are quite a few days where there might be 5 active queries that won and about 25 queries that lost. The overall total at this point is 247-375.

If this keeps going like this then while you guys are going through your queries and weeding out the bad ones, I might have to start going through my queries and weed out the good ones!

But in the mean time I am just sticking to what brought me to this point in the first place, which is just recording how the active queries do as a group each day.

Today I found:

Bulls(8U)(H1)/Cavaliers(A0)(1.0--201.5) -- SU: 304-232 (2.49, 56.7%) -- ATS: 261-270-5 (-0.20, 49.2%) -- OU: 210-317-9 (-1.34, 39.8%)8O8UUUOOOOUOUUUOUUOO Pip Sunday under query 12/29/14

Bulls(9L9UU)(H1)/Cavaliers(A0)(1.0--201.5) -- SU: 95-76 (1.83, 55.6%) -- ATS: 70-95-6 (-1.61, 42.4%)6W9LLWWWLWLLWLLPLLLW -- OU: 63-106-2 (-2.69, 37.3%)7O9UUOUOOUOUUUUUOOUO NBA 135

Cavaliers(6WW11U)(A0)/Bulls(H1)(-1.0--201.5) -- SU: 69-32 (3.60, 68.3%) -- ATS: 69-30-2 (4.49, 69.7%)6W10LWWLWWLLWLLLWLLLL -- OU: 42-58-1 (-2.34, 42.0%)5O11UUUOUUUUOUUOUUOOU NBA89

Cavaliers(6WW8U)(A0)/Bulls(H1)(-1.0--201.5) -- SU: 91-48 (2.81, 65.5%) -- ATS: 92-44-3 (3.97, 67.6%)6W10LWWLLLWWWLLLLLLLW -- OU: 57-81-1 (-2.06, 41.3%)8O8UUUUUOOOUUOUOUOOO from hyahya sitpost #1990

Cavaliers(X5U)(A0)/Bulls(H1)(-1.0--201.5) -- SU: 61-51 (0.93, 54.5%) -- ATS: 53-56-3 (-1.04, 48.6%) -- OU: 43-68-1 (-4.53, 38.7%)11O5UOOOUOUOUOUUOOOOO 1/28/15 from nash around sitpost #2946

Cavaliers(12U)(A0)/Bulls(H1)(-1.0--201.5) -- SU: 126-95 (2.57, 57.0%) -- ATS: 109-109-3 (0.03, 50.0%) -- OU: 89-128-4 (-1.65, 41.0%)4O12UUUUOUUUUOUUOUUUO NBA217

********

Just from experience and eyeballing these queries, I can see there is a Nash query and a hiyahya query in the group, and that plus the fact that the active query size for today is relatively small (only one game today), might well mean the winners outnumber the losers today.

Anyway, I will take the above and reverse their predictions, and post these as my "Fading the Pip query library" picks, as I wait to see if the numbers start to equal out to something less than a 60% loss rate.

[pip2]

chi/cle O 4 units
chi beats cle 3 units

[emkee13]

Incorporating this method into my bets. Some help, please.

SDQL for same-season revenge when they lost the last meeting by 10+. Thanks.

[emceeaye]

Incorporating this method into my bets. Some help, please.

SDQL for same-season revenge when they lost the last meeting by 10+. Thanks.

P:margin<=-10 and P:season=season

[pip2]

chi/cle O 4 units --> +4
chi beats cle 3 units --> +3

total +7

running total +7
(34-27)

[Cutler'sThumb]

chi/cle O 4 units --> +4
chi beats cle 3 units --> +3

total +7

running total +7

Like a charm tonight, Pip. Maybe you're on to something, lol.

[pip2]

Like a charm tonight, Pip. Maybe you're on to something, lol.

How long will this last? Is it like nuclear energy, can it be harnessed for the good of mankind?

[JMon]

How long will this last? Is it like nuclear energy, can it be harnessed for the good of mankind?

It will last until it turns the other way, and it will

[nash13]

Hello everyone,
I guess since the Trend Market started and the contribution to the sheet stopped, I will only leave the contributing members in the access group. If I delete one of the regular contributors mistakenly, let me know via PN.

[JMon]

Hello everyone,
I guess since the Trend Market started and the contribution to the sheet stopped, I will only leave the contributing members in the access group. If I delete one of the regular contributors mistakenly, let me know via PN.

Been a good ride nash! See you on the trend mart.

For the noobs that need sdql help, post away and I will help as much as possible. As for posting queries for particular plays..not on this forum!

[Heart]

My only concern... when we start deciding to actually fade winning SDQL queries.. that just doesn't sit right with me. I mean that's red flags being raised on the entire operation.

Also I don't get a good feeling regarding selling to the "trends market". At this point it feels like a money grab. I honestly haven't made any $$$ using NBA queries that specifically filter out unrelated noise. On a bit of a high horse here but I can't in good faith peddle the NBA queries at this point to anyone else and feel confident. No judgement being passed to those who take this path as I understand it $$$ from any source spends the same as money won from beating books. I honestly feel that the info of SDQL became public and the books adjusted accordingly. Keeping this technology on the down low (as they used to say) in hind sight may have been the better approach. But it has been a fun ride and I've enjoyed collaborating with you fellas so for me I got my money's worth!

My hope is that we can make some noise in the MLB arena this year. It may seriously be worth figuring out how we can keep a closed group to keep the information from getting public. I think if we had something setup to share a private thread with the regular core posters here we could potentially make some noise. Perhaps I'm totally off base here but wanted to present some food for thought.

No NBA sdql plays for me for at least a week after the all star game either way to allow for some semblance of normalcy for the trends.

[pip2]

My only concern... when we start deciding to actually fade winning SDQL queries.. that just doesn't sit right with me. I mean that's red flags being raised on the entire operation.

Also I don't get a good feeling regarding selling to the "trends market". At this point it feels like a money grab. I honestly haven't made any $$$ using NBA queries that specifically filter out unrelated noise. On a bit of a high horse here but I can't in good faith peddle the NBA queries at this point to anyone else and feel confident. No judgement being passed to those who take this path as I understand it $$$ from any source spends the same as money won from beating books. I honestly feel that the info of SDQL became public and the books adjusted accordingly. Keeping this technology on the down low (as they used to say) in hind sight may have been the better approach. But it has been a fun ride and I've enjoyed collaborating with you fellas so for me I got my money's worth!

My hope is that we can make some noise in the MLB arena this year. It may seriously be worth figuring out how we can keep a closed group to keep the information from getting public. I think if we had something setup to share a private thread with the regular core posters here we could potentially make some noise. Perhaps I'm totally off base here but wanted to present some food for thought.

No NBA sdql plays for me for at least a week after the all star game either way to allow for some semblance of normalcy for the trends.

4 possible reasons the pip query libraries have performed so much worse than throwing a dart:

1. Simple variance that will probably swing back in the other direction with a vengeance.
2. Weird year -- how many times have you seen an otherwise awesome query showing terrible results for 2010 or 2012? Maybe this year is one of those. 2010 was another year when Lebron shifted teams...maybe that, or a shortened season, or weird injuries to too many key players throws too much uncertainty into the query picture and muddles it up.
3. Bettors were winning so much money on queries that the oddsmakers started factoring them into their calculations.
4. Nobody ever paid any attention to bad queries before -- nobody ever wanted anything to do with a bad query besides to get rid of it. Maybe the results of the pip query library so far, if they persist, are just what bad queries have always done, but nobody noticed.

But to me, none of those possibilities sheds any bad light on the art of query-making itself, or raises any red flags on the operation itself that shouldn't have already been there from the start. I think we always have to keep in mind that no matter how good any system is, the linesmakers can set any line they want to try to screw it up. Maybe you are right about keeping critical information on the down low.

[Cutler'sThumb]

Just my 2 cents here, but I seriously doubt that SDQL betting is having any significant impact on the lines oddsmakers set. I could be wrong, but it comes up all too often on forums like this. Billions of $$ are flowing thru the system and I doubt there are enough guys out there all making the same large volume bets using SDQL to influence lines in Vegas or at Pinnacle.

[lovetobet]

Oh sh*t just spent hours reading this thread because I got sucked into it and read almost the entire thread. Was hoping to be able to look at this sheet to get an idea if this was something I could attempt to start learning as it obviously seems somewhat complicated. I know a few pages back that was being offered by Nash but I'm not sure of all the language in the last 2 pages with the 'selling' going on. Is it still possible to get a copy of the sheet and take a look at it? I am very interested in seeing if this is something I can learn to do, would appreciate any help, thanks.

Out of curiosity what types of backgrounds do you guys have that are good at this is it programming? Or something similar?

[Pete0]

^ the whole thread ?! Wow

If so can u please summarize in ur own words ? Or maybe post some of the interesting ideas uve come across ?Would be interestd in heqring ur opinion. Thanks !

[pip2]

Oh sh*t just spent hours reading this thread because I got sucked into it and read almost the entire thread. Was hoping to be able to look at this sheet to get an idea if this was something I could attempt to start learning as it obviously seems somewhat complicated. I know a few pages back that was being offered by Nash but I'm not sure of all the language in the last 2 pages with the 'selling' going on. Is it still possible to get a copy of the sheet and take a look at it? I am very interested in seeing if this is something I can learn to do, would appreciate any help, thanks.

Out of curiosity what types of backgrounds do you guys have that are good at this is it programming? Or something similar?

I really don't think programming experience is necessary. It helped me feel a little more confident about being able to eventually learn the sdql commands, because you kind of feel that if you can learn a set of C commands, for instance, then you should be able to learn these sdql commands. But the individual commands you use and the strategies you use when programming tend to be very different from what you do when you use sdql. In one respect, programming can be easier, especially with today's compilers, because they are designed to help you figure out whatever mistake you might have made. Sdql, on the other hand, tends to just tell you that you made a mistake, and you have to figure the rest out for yourself.

But when you program something you are building an entire structure and orderly procedure of commands that all have to work together to do what you need. In sdql, the structure is already there for you, and you basically just need to spit out one line of commands to describe the situation you are curious about. And that one line can be as simple or as complicated as you want to make it.

[lovetobet]

I really don't think programming experience is necessary. It helped me feel a little more confident about being able to eventually learn the sdql commands, because you kind of feel that if you can learn a set of C commands, for instance, then you should be able to learn these sdql commands. But the individual commands you use and the strategies you use when programming tend to be very different from what you do when you use sdql. In one respect, programming can be easier, especially with today's compilers, because they are designed to help you figure out whatever mistake you might have made. Sdql, on the other hand, tends to just tell you that you made a mistake, and you have to figure the rest out for yourself.

But when you program something you are building an entire structure and orderly procedure of commands that all have to work together to do what you need. In sdql, the structure is already there for you, and you basically just need to spit out one line of commands to describe the situation you are curious about. And that one line can be as simple or as complicated as you want to make it.

pip2 - Thanks that's helpful. I know the other person above is giving me a hard time but I actually did read this entire thread last night but it was in the middle of the night because I was up sick so maybe I missed some pieces because there were a few things that I never figured out in my reading. Was hoping that getting a copy of this 'sheet' would clear some or all of it up. What program is this being run in/on? Is the 'sheet' on the same program? If the 'sheet' is not being shared with noobs anymore could you shed some light on the best way for someone like myself to try and start looking into this on my own? Appreciate your thoughts above and any other useful advice from you or other experienced users.

If it helps I'm not a flash in the pan. I've been sports gambling for over 20 years but only seriously for the last 10. Over the last 10 years one thing has become clear to me I have only been able to win consistently in one sport football, luckily both college and pro, but have not been able to ever put together consistent winning seasons in NBA, NHL or NCAAB. I have a math, accounting & science back ground so that is why I got sucked into this thread last night because the nature of how this works (or at least my limited understanding of how it works) speaks to me. Again any help guidance would be appreciated. I can see that you core guys have put a lot of time and energy into this and I'm not looking for just a free ride (the old give a man a fish/teach a man to fish proverb). I'm out of work with an injury right now and have more time than usual to dedicate to learning something new like this (again what pulled me into reading this whole thread).

Anyway again would appreciate any help and guidance.

[JMon]

The best way for any beginner to learn sdql is to read the manuals @ sdql dot com and killersports dot com. Pay special attention to the listed parameters for each sport. They also offer a google group, where one can search for previously asked questions. Bol

[lovetobet]

The best way for any beginner to learn sdql is to read the manuals @ sdql dot com and killersports dot com. Pay special attention to the listed parameters for each sport. They also offer a google group, where one can search for previously asked questions. Bol

Thanks Jmon. Just quickly check both sites out and will start in on some reading after the kids go down tonight.

So is this thread done. Are you guys done collaborating on here?

[pip2]

pip2 - Thanks that's helpful. I know the other person above is giving me a hard time but I actually did read this entire thread last night but it was in the middle of the night because I was up sick so maybe I missed some pieces because there were a few things that I never figured out in my reading. Was hoping that getting a copy of this 'sheet' would clear some or all of it up. What program is this being run in/on? Is the 'sheet' on the same program? If the 'sheet' is not being shared with noobs anymore could you shed some light on the best way for someone like myself to try and start looking into this on my own? Appreciate your thoughts above and any other useful advice from you or other experienced users.

If it helps I'm not a flash in the pan. I've been sports gambling for over 20 years but only seriously for the last 10. Over the last 10 years one thing has become clear to me I have only been able to win consistently in one sport football, luckily both college and pro, but have not been able to ever put together consistent winning seasons in NBA, NHL or NCAAB. I have a math, accounting & science back ground so that is why I got sucked into this thread last night because the nature of how this works (or at least my limited understanding of how it works) speaks to me. Again any help guidance would be appreciated. I can see that you core guys have put a lot of time and energy into this and I'm not looking for just a free ride (the old give a man a fish/teach a man to fish proverb). I'm out of work with an injury right now and have more time than usual to dedicate to learning something new like this (again what pulled me into reading this whole thread).

Anyway again would appreciate any help and guidance.

The sheet consists of nearly 300 single queries, many of which are of dubious value even in good seasons, and I don't think this is a good season, so there are many more queries from that sheet that are perhaps only for this year of dubious value. At any rate, 300 queries is a lot to deal with as it is, and when you consider that each of those queries probably needs to be scrutinized carefully with an expert eye, at this point in time in your sdql career you are probably just as well off without it.

If you have gone over the thread, you will have seen a number of queries that eventually ended up on the sheet. Certainly enough of these to keep you busy building up your sdql capacity. Have you visited Killersports and tried a simple query?

As an experienced gambler you might have more of an edge than an experienced programmer. I got on one nba gambling site near the beginning of the season and was running queries in response to requests from some of the gamblers on that site, and I really appreciated the opportunity to get a glimpse of what kinds of things they were interested in looking at. One of the few queries I have written that doesn't completely suck, came from writing a query to match a situation as described by one of those guys.

At any rate, the best advice I could think of for you would be to start thinking up all the situations that you as a gambler have always wondered about as far as perhaps those situations might make good bets. And then, one by one, try to figure out the sdql to describe those situations and get the results that show whether there is really a bet there.

I think it might be debatable how valuable a tool sdql is. But to me there is no debate as to whether its valuable or not. There is a set of queries I run daily just to get a quick run down on who is playing b2b, 4in5, is just back from a long road trip, etc, and that quick rundown by itself makes sdql valuable to me. But I'm also pretty sure that's just the very tip of the iceberg in terms of value.

And there is a lot of room for using your own imagination to increase the value, which makes it at the very least, quite an entertaining hobby.

[pip2]

fade pip query library day 5

Spurs(X6W)(A7)/Clippers(H7)(-2.5--203.0) -- SU: 82-44 (4.31, 65.1%) -- ATS: 84-37-5 (3.28, 69.4%)6W10LWWWWLLWLLLLLWLLL -- OU: 60-64-2 (0.48, 48.4%) L5

Spurs(X7U)(A7)/Clippers(H7)(-2.5--203.0) -- SU: 49-34 (1.10, 59.0%) -- ATS: 37-41-5 (0.64, 47.4%) -- OU: 27-55-1 (-5.24, 32.9%)9O7UUOOOUUUOOOOOUUUO NBA18 from NBA18 on Nash sheet

Spurs(10W)(A7)/Clippers(H7)(-2.5--203.0) -- SU: 93-27 (7.38, 77.5%) -- ATS: 77-41-2 (3.06, 65.3%)10W6LWLWWLWWWLLLWWWWL -- OU: 60-59-1 (0.43, 50.4%) NBA22 from NBA22 on Nash sheet

Thunder(X7O)(H7)/Mavericks(A7)(-5.0--214.5) -- SU: 222-163 (3.22, 57.7%) -- ATS: 183-196-6 (-0.28, 48.3%) -- OU: 221-159-5 (3.19, 58.2%)7O9UOUOUUUOOUUOOUOUU NBA87

Spurs(8U)(A7)/Clippers(H7)(-2.5--203.0) -- SU: 223-333 (-3.53, 40.1%) -- ATS: 268-281-7 (0.03, 48.8%) -- OU: 233-312-11 (-2.28, 42.8%)8O8UUOUUOUUUOOOUOOOU NBA205

Mavericks(10L10UU)(A7)/Thunder(H7)(5.0--214.5) -- SU: 106-97 (1.06, 52.2%) -- ATS: 87-114-2 (-1.01, 43.3%)5W10LLLWLWLWLLWLLWLPL -- OU: 87-114-2 (0.78, 43.3%)6O10UUOUUUUUOUOOOUUUO NBA214

fade translation:

dal beats okc 1 units
lac beats sa 2 units
sa/lac O 2 units

[pip2]

dal beats okc 1 units --> -1
lac beats sa 2 units --> +2
sa/lac O 2 units --> +2

total +3
running total +10
(38-28)

[pip2]

33 active queries found today so I will skip straight to the fade translation:

det beats chi 1 unit
det/chi O 1 unit
mn beats phx 1 unit
mn/phx O 1 unit
tor/atl U 1 unit
tor beats atl 1 unit
ny beats mia 3 units
ny/mia O 1 unit
por/ut O 2 units
sac beats bos 1 unit
sac/bos O 1 unit
dal/hou O 1 unit
lal beats bkn 1 unit
den beats mil 1 unit
orl beats no 1 unit
gs beats sa 2 units
sa/gs O 1 unit
wsh beats cle 6 units
wsh/cle O 1 unit

[pip2]

det beats chi 1 unit --> +1
det/chi O 1 unit --> -1
mn beats phx 1 unit --> +1
mn/phx O 1 unit --> +1
tor/atl U 1 unit --> +1
tor beats atl 1 unit --> +1
ny beats mia 3 units --> -3
ny/mia O 1 unit --> +1
por/ut O 2 units --> -2
sac beats bos 1 unit --> +1
sac/bos O 1 unit --> +1
dal/hou O 1 unit --> 0
lal beats bkn 1 unit --> -1
den beats mil 1 unit --> -1
orl beats no 1 unit --> +1
gs beats sa 2 units --> +2
sa/gs O 1 unit --> 0
wsh beats cle 6 units --> -6
wsh/cle O 1 unit --> +1

total -2
running total +8
(50-42)

[pip2]

mia beats no 2 units
okc/cha O 1 unit
tor/hou U 1 unit

[lovetobet]

The sheet consists of nearly 300 single queries, many of which are of dubious value even in good seasons, and I don't think this is a good season, so there are many more queries from that sheet that are perhaps only for this year of dubious value. At any rate, 300 queries is a lot to deal with as it is, and when you consider that each of those queries probably needs to be scrutinized carefully with an expert eye, at this point in time in your sdql career you are probably just as well off without it.

If you have gone over the thread, you will have seen a number of queries that eventually ended up on the sheet. Certainly enough of these to keep you busy building up your sdql capacity. Have you visited Killersports and tried a simple query?

As an experienced gambler you might have more of an edge than an experienced programmer. I got on one nba gambling site near the beginning of the season and was running queries in response to requests from some of the gamblers on that site, and I really appreciated the opportunity to get a glimpse of what kinds of things they were interested in looking at. One of the few queries I have written that doesn't completely suck, came from writing a query to match a situation as described by one of those guys.

At any rate, the best advice I could think of for you would be to start thinking up all the situations that you as a gambler have always wondered about as far as perhaps those situations might make good bets. And then, one by one, try to figure out the sdql to describe those situations and get the results that show whether there is really a bet there.

I think it might be debatable how valuable a tool sdql is. But to me there is no debate as to whether its valuable or not. There is a set of queries I run daily just to get a quick run down on who is playing b2b, 4in5, is just back from a long road trip, etc, and that quick rundown by itself makes sdql valuable to me. But I'm also pretty sure that's just the very tip of the iceberg in terms of value.

And there is a lot of room for using your own imagination to increase the value, which makes it at the very least, quite an entertaining hobby.

Hey pip,

Thanks for the response, sorry I was MIA for a couple of days. I have gone back to KS and SDQL.com and looked over both sites and started to do some preliminary reading, I won't have time to really dive into it until Monday i can't wait. Once I realized I wasn't going to get the sheet I started going back through the thread and copying and pasting trends into a document to help in the learning process and one of the contributors of this thread was nice enough to provide me with a few of the top trends in a couple of each sport to help, so all of this should help me in the learning process.

I hear you and understand on the experienced gambler vs. experienced programmer, makes sense. At this point I need to just dive into reading and understanding everything better as I have a lot of question but not fully understanding how it works leaves me at an obvious disadvantage, so time to dive in and figure it out.

Take care and thanks for the responses.

[lovetobet]

So pip, I don't have time to go back and read through the thread and the first time I read it, it was all 90 pages in 1 night at 3 in the morning, so remind what you are doing?

Are you basically fading the trends because (betting against them) because this years has been ass backwards? Is that's what you are doing?

[pip2]

So pip, I don't have time to go back and read through the thread and the first time I read it, it was all 90 pages in 1 night at 3 in the morning, so remind what you are doing?

Are you basically fading the trends because (betting against them) because this years has been ass backwards? Is that's what you are doing?

I want to make sure it is clear that what I am fading is my own library of queries. It's really tentative fading, with very small bets being placed. If the fading wins, then perhaps that would be house money that could be used to enlarge the bets. So this is basically just a wild-ass test balloon I am sending up in the air right now. The reason I am doing it is that the queries I have, many of which I wrote, have had around 700 plays over the past 2 months, and up to about 2 weeks ago they were losing at around a 60 percent rate. Now, since I began posting them, they have been losing at around a 54% rate, and if they keep going this way, maybe the entire accumulation of them might just be evened out at 50-50 by the end of the season. Or maybe they will veer back into losing again as the days roll forward.

So more than anything at this point I am just monitoring them with very small bets, and also trying to look for patterns among the winners and losers that might help me understand better what makes some work and what makes others fail.

Just for the record, this thread has really kind of morphed over the past year. When it started, it was about the art of making a query that would win. But there came a point when everything kind of shifted to seeing what could be accomplished by pooling all our queries together. We quickly gathered this big sheet full of queries and a lot of focus went from the art of making a query to how to manage a big query library. So we have kind of drifted a long way from where we started. I don't think that is necessarily a bad thing, but maybe we could kind of "bookmark" that morph-point, so that if the time comes when the whole sdql thing seems to be failing, we can look back to that morphing point as a possible time when things started going south...

[pip2]

mia beats no 2 units --> -2
okc/cha O 1 unit --> +1
tor/hou U 1 unit --> +1

total 0
running total +8
(52-44)

[pip2]

48 active queries found today, here are the fades:

mil beats atl 5 units
cle beats ny 1 unit
cle/ny O 1 unit
bos/lal U 1 unit
lal beats bos 2 units
cha/dal U 1 unit
ind beats gs 5 units
gs/ind U 1 unit
det beats wsh 7 units
wsh/det O 2 units
den beats okc 1 unit
den/okc U 1 unit
mem/por O 1 unit

[pip2]

mil beats atl 5 units --> -5
cle beats ny 1 unit --> +1
cle/ny O 1 unit --> -1
bos/lal U 1 unit --> -1
lal beats bos 2 units --> +2
cha/dal U 1 unit --> +1
ind beats gs 5 units --> +5
gs/ind U 1 unit --> +1
det beats wsh 7 units --> +7
wsh/det O 2 units --> -2
den beats okc 1 unit --> -1
den/okc U 1 unit --> -1
mem/por O 1 unit --> -1

total +5
running total +13
(69-56)