SDQL3 KBO Tutorial
- awang_htx
- May 26, 2020
- 4 min read
As of 5/26/2020, here are my thoughts: in my opinion, SDQL3 was a bit harder to pick up on and not as intuitive as SDQL2. There's also no guides or manuals to follow yet. After getting my feet wet, I can see the additional functionality and the flexibility to customize your own layouts and combine data from different tables. It also seems to incorporate a lot more Python functionality (which I don't know much of). Dr. Joe Meyer (@sdql) has been releasing some nuggets of new functionality and lessons, so I am eager to learn more!
By utilizing my knowledge of SDQL2, studying the material on https://sdql.com, and reading Joe's (@sdql) lessons and challenges, I have been exploring the SDQL3 database to learn about the KBO. I’ve uncovered some tricks and functionality that I can share with you all that may be having trouble. I have had many reach out to me yearning for some additional direction. To the head honchos, I apologize if I am overstepping my boundaries here, but I am a man of the people and I give them what they want!
Disclaimer #1: I was not affiliated in the development of SDQL3 and I do not consider myself an expert. I am not a SDQL Master, but I am a SDQL Bachelor with aspirations of one day becoming a SDQL Master. I enjoy the community and have interacted with some smart and cool folks. I think the tool is amazing for a sports fan and a handicapper and what makes it even better? It’s FREE! WHAT! Support https://killersports.com by purchasing from the Trend Mart and buying their reports/publications. There are some truly talented people that have uncovered some amazing systems and trends that will add value to your betting repertoire. Disclaimer #2: Joe has clearly stated this product is a beta version. There are likely errors in the database. I have found a few, so do not be surprised if you find some. Instead, report it to the Sports Database Data Google Group so it can be fixed. A few I have reported have since been corrected.
Here are a few new features that Joe has shared that have stood out to me:
· The use of a mysterious #CamelCaseCompletion that allows minimal typing of parameters and strings. What camel? What case are we solving? I have no freaking clue. For some reason, sometimes it’s "sick" too. Joking aside, here are some examples I’ve seen Joe use to be more of a minimalist in typing out less text to define parameters:
- R is Runs
- Te or T is Team
- Si is Site (H is Home, A is Away)
- D is Date
- Se is Season
- Li is Line
· The new #SDQL3 Aggregator ‘Record’. This is a really neat function where you define the parameter and it will return a dictionary with a list of keys: ‘wins’, ‘losses’, ‘pushes’,’margin’,’invested’,’profit’. To return a simple O/U record you can simply define: Record(R+o:R-total). The Record Aggregator also accepts line and bet size; therefore if you use Record((R+o:R-total,1.91,100)). This assumes a -110 vig and bet wager size of 100 so you can see the ROI on your bets.
Example
Here is the SDQL3 syntax I shared that utilizes CamelCaseCompletion (not sure if it’s sick or not) and the Record function. This table is to show the YTD O/U Record for each KBO Team, the average runs, opponent’s average runs, total average runs, run differential, and average SU margin. R(Te),Record((R+o:R-total,1.91,100)),A((R+o:R>total)*100),A(R),A(o:R),A(R+o:R),S(R-o:R),A(R-o:R)@Te and game number>=0 and Se=2020| Let’s break it down:
Per the sdql.com website, “The basic SDQL structure is a comma delimted list of parameters, an @ sign, followed by an and delimited list of conditions. This can be thought of as ‘what I want to see at the conditions under which I want to see it.’ Let’s go through the conditions under which I want to see it: · Te = I want to run it for all teams so I leave it wide open. If you want to define a specific team, you can put "Te=Bears".
· game number>=0 : this is important for the KBO database as there are games that are canceled or rescheduled due to rain delay. These lines don’t have a game number, but they still exist in the database as a gid (Game ID). Without defining this, you will be picking up an extra game in any potential queries or Average calculations.
· Se=2020 = this indicates that I only want to pull data from the 2020 season.
· | = this ‘empty’ subsequent reduces the grouped query result into a single sortable table, per @sdql
Now here are the parameters we want to SEE:
· R(Te) : Since I did not find a definition in the manuals, I will do my best to describe it. The R( ) function (and excuse the lack of proper technical programming jargon) is used to summarize/group a parameter in it’s own Row.
· Record((R+o:R-total,1.91.100)) : I already defined this above.
· A((R+o:R>total)*100), A(R), A(o:R), A(R+o:R), A(R-o:R) : The “A” is an Average function. I think you get the point here. These parameters return the average OU%, average runs, average opponent, average total score, average SU margin.
· S(R-o:R): The “S” is a Sum function. This calculates the season to date Runs less opponent’s runs to calculate the Run Differential.
Here is the output – not too aesthetically pleasing with the dictionary keys:
As Joe explains below, you can add in a subsequent query to grab those desired values and make it into a sortable table.
Here is my revised query to utilize the subsequent query to break out the keys within the Record output to make it a sortable table and names the columns. This makes the presentation a little nicer and you will be able to sort by the Overs and Unders.
This concludes my example for today. As you can see, there are so many parameters you can explore and play around with. Good luck and have fun!
Special thanks to: @sdql – Joe Meyer @Killer_Trends – Ed Meyer @CharliesHustle2 – Charlie’s Hustle
Comments