Anyway, I doubt the EG from lasting longer makes up for the difference in what is immediately given up, esp since this strategy hedges on finding +EV vanilla numbers which makes the person on an extremely quick road to riches.
-
Comment -
Hedges? Hinges.Comment -
It is about optimal growth. What would you rather, make 10k and get booted from a book after a week or make 5k but last 6 months?
Mathy answered the question. Take what you can get and move on/start over. Unless you are a complete idiot like andywed and have never been booted/limited anywhere it's just something you get used too.
J7 is the only one with a big enough bankroll for the 15team rr'f for the limit yet oddly is still scalping out half of his potions on 1k limit bets at SIA.Comment -
Just for clarity, you banned one person who disagreed with you, and now have derided two posters who took the most logical interpretation of what you meant.
Why did you choose 15 +EV wagers? Did you make this number up? How are you parlaying them?
I'm sure you won't get around to answering any of these since they would get to the root of what is afoot. Apparently I'm too -EV to discuss ideas with. No handouts for Thrempie today.Comment -
for me, with my limits/bankroll, and depending on the overall EV, this could provide more bankroll growth potential than straight betting chicken feed. there r only so many outs i can get. the other option costs money too and i am finding it doesn't take long B4 i am in the same situation anyway.
i guess book and player specific tho.
Comment -
I've actually been working on an optimization algorithm for this. I would HIGHLY doubt that anyone is able to do this without some very efficient, distributed algorithm across many computers. AMPL will likely not help. In fact, it's probably just as bad as Excel Solver in terms of the number of iterations needed for convergence. It does have the benefit of multiple core/processing to aid it unlike Solver though. Any type of Newton-derived or gradient-descent method seems to converge poorly in a multivariate Kelly staking function unless your initial "guess" is close to the global maxima. The spreadsheet that Ganch created is set to differentiate twice using Solver (which uses a Generalized Reduced Gradient algorithm). By default, his spreadsheet uses central differencing (differentiation of two localized points on each side of every parameter). This is set in VBA by setting the Derivatives option to 2. In THEORY, central differencing should converge better than forward differencing. However, in the case of a multivariate Kelly optimization, it does far worse. Sometimes, central differencing will return a result, but upon re-running Solver, a new global maxima is found using the "converged" values as a starting point. I've had to do that up to four times when I was testing it in Solver. Oddly enough, when using forward differencing (one differentiation point), Solver converges more precisely and rapidly - without the need to reinitiate. I've had similar experiences using a variety of optimization algorithms in C# as well. What I've found works best so far is a simple linear search (i.e. two points on either side of the current stake with diminishing step size down to the specified precision) that adjusts the stakes individually, recalculates the total utility after each adjustment, and sets the parameter to the best of the three data points in terms of global utility. This performs roughly 30-40 times faster than a Solver solution. I am able to run a 2-5 team RR optimization in under one second. Since there is only one maxima which serves as the local and global maxima of the function integral, there is no need to worry about a false positive. The problem that I'm running into is that I haven't been able to devise a solution that enables a multi-core/multiple processor solution. Each parameter (stake) must be adjusted prior to another. Stake adjustments in tandem lend erratic results.
But to answer your actual question, even with an algorithm that converges approximately 30-40 times faster than a Solver solution, I attempted an optimization selecting just 2-4 team parlays with a 15 game set and I aborted it after running for 1.5 hours.Last edited by MonkeyF0cker; 05-23-12, 01:03 AM.Comment -
-
Well, after some deliberation, I believe that I've created the fastest, most efficient multivariate Kelly staking convergence algorithm known to mankind (semi-joking). It now multithreads the utility calculations to utilize additional cores/processors. Below are the average round-robin calculation times (in seconds) on a quad-core AMD with 8 decimal point precision (staking optimization to the penny for bankrolls < $9,999,999.99) followed by the total number of parlays optimized in parentheses. It should be noted that these times include the processes from taking a simple list of games (just odds and probabilities) all the way to optimizing stakes. In other words, these times include building every possible outcome, calculating the probabilities of each outcome occuring, building every possible 2->n team parlay, calculating each parlay's odds, building an event matrix between the parlays and outcomes, and optimizing individual parlay stakes using a proprietary (MonkeyF0cker Inc.) progressive-stepping linear search algorithm.
(A time of 0 means that it was completed within 1 CPU cycle)
2 team: 0.0000000 (1)
3 team: 0.0000000 (4)
4 team: 0.0156001 (11)
5 team: 0.0780001 (26)
6 team: 0.3432006 (57)
7 team: 5.0232088 (120)
8 team: 116.9476148 (247)
9 team: 4973.752539 (502)
You can quickly see how it becomes infeasible to RR anything more than 9 teams or approximately 500 total parlays.
There are only several different ways to speed along the computations...
1. Lower staking precision. Precision in staking could be adjusted two decimal places if one wants to disregard fractional dollars and wager whole dollar amounts per parlay. The precision can also be reduced for smaller bankrolls. For example, if your bankroll b ($9,999 < b < $100,000) was colloquially referred to as a 5 digit bankroll, you'd need 6 digits of precision to converge to the optimal stake in each parlay (or 4 digits of precision if you wish to wager whole dollar amounts).
2. Better estimate in initial staking. This algorithm steps up from a stake of 0% for each parlay. A closer first estimate to the global maxima will greatly reduce the iterations needed for convergence. Going about accomplishing this is the difficult part. There are several methods that I've considered including: creating a multitude of randomized staking vectors and choosing the one with the best total utility as a starting point and normalizing each stake's single bet Kelly stake across the vector. I have yet to try either (or perhaps a combination) of these methods, but perhaps I can see some significant improvement in total iterations in calculations with an (arbitrarily) higher amount of parlays.
If anyone has any interest in this or even any suggestions, let me know.
I should probably start a new thread for this, but oh well.Last edited by MonkeyF0cker; 05-24-12, 11:33 PM.Comment -
Using AMPL+SNOPT(via NEOS) I'm finding substantially faster convergence with an uninformed initial point. With a precision of 16 digits (solution and objective):
9-team: 2s
10-team: 4s
11-team: 4s
12-team: 12s
13-team: 63s
14-team: 315s
15-team: 1515s
To be fair, I've not verified the global-ness of any of the solutions and so they could certainly be way off; what's more, each partition represents a sample size of 1 (widely considered low).
Constituent win probabilities and edges were selected from the uniform distribution with endpoints of U[10%,90%] and U[0%,10%], respectively. With such moderate single-bet kelly stakes, the constraining of the solution to exclude single wagers looks to generally produce an optimal portfolio comprised solely of the 2-team round robin.
I'm kind of out of practice with optimization but I suppose this might indicate a singularity in the modified Hessian, which you're right ... would render the Newton family pretty much useless in the neighborhood.
Could you post a sample 9-team data set?Last edited by Ganchrow; 05-25-12, 01:16 PM.Comment -
Use the proprietary mathy algorithm (Mink Inc.):
Just pump and pound until you run out of money to bet
I've long been an advocate of back of the envelope Kelly, for practical reasonsComment -
Oh, wow. That's pretty impressive. I haven't tried SNOPT yet. My algorithm is essentially a linear search mutation of a MINOS and CONOPT Lagrangian method. The SQP method of SNOPT seems best designed for optimizations like this. The problem with my (along with the MINOS and CONOPT) algorithm is the constant re-evaluation of the utility function. SNOPT alleviates this. I found an academic paper on the SNOPT algorithm which will enable me to code up an implementation in .NET and see if I can attain feasibly-timed, reliable convergence (which seems to be the case).
I've found that optimal staking is generally comprised of 2 team parlays as well. However, there are situations that arise (especially betting in Vegas) where true odds (or even 2-team) parlays are not available and the staking vector becomes much less top-loaded. So, both situations need to be accounted for, but I believe SNOPT addresses both of them adequately.
It's been years (a decade maybe) since I've coded any type of nonlinear optimization like this, but this is an enjoyable problem to tackle and one that I've been meaning to address for quite a while. I would prefer if I didn't have to interface with Excel, AMPL, or another platform.
Here's a sample of a 9-team data set (odds, edge) at full Kelly:
1.90909090909090909, 0.0542781266994063
1.90909090909090909, 0.0868097997476485
1.90909090909090909, 0.0280478136709175
1.90909090909090909, 0.0527155743329493
1.90909090909090909, 0.0372057053911861
1.90909090909090909, 0.0086947421931842
1.90909090909090909, 0.0288709459060059
1.90909090909090909, 0.0642271636831586
1.90909090909090909, 0.0922243836824266
Total Utility = 0.0155705264982059 Time Elapsed = 485.0083209 Seconds
I had been testing with high win %, high edge wagers which intuitively increases convergence time (pretty significantly apparently). Although, it's still nowhere near 2s.Last edited by MonkeyF0cker; 05-25-12, 08:06 PM.Comment -
Well there you go ... I'm getting significantly lower full Kelly utility. My solution:
The MINOS solution is identical to the 12th staking decimal place and ran inconsequentially faster (with only 512 terms the utility function is still pretty cheap to evaluate). The IPOPT and KNITRO solutions are each a second or two slower and contain non-zero stakes for 3+ team parlays (which is wrong) but yield identical utility to the 8th decimal place (which as far as I can tell is the precision limit for each).Code:BET 2T 0.6867945898182101% :Solver: SNOPT Server: neos-3.chtc.wisc.edu EV: 2.549894% EG: 1.240171% Utility: 1.232544% Adj Util: 1.232544% # Bets: 36 Tot Bet: 24.724605% Solve: 0.01s AMPL Call: 0.21s NEOS RPC: 2.12s Perl Process: 2.21s Excel Call: 4.16s
What does your solution look like? (I'll venture a guess that you've misquoted the final utility number, although it's also possible there's a bug in my AMPL model).
SNOPT and MINOS are quality general-case NLP solvers and AMPL makes using them easy. NEOS is a great way to use AMPL for free although there are some serious memory limitations on the NEOS servers that effectively preclude their out-of-the-box use in large scale combinatorial optimization.
For this type of problem, I'd have consider it unlikely you'd be able to do better with a linear search algorithm although I've been wrong before and either way it's a fun exercise. In fact, this is a great test case that might make me eat my words in short order. What's your final solution?Comment -
In case you're interested, I've attached is the AMPL model/data file my software autogenerated for the specified problem.
I just kludged the round-robin optimization restrictions earlier today so that still could be an issue.Comment -
I'm attaching a text file with the individual stakes ordinally compliant with your generation algorithm. If you run the Read Stakes routine of your original spreadsheet with the appropriate parameters and paste the stakes into the stakes column, it returns the same utility that I quoted above with a total wager of 24.9034% and EV of 3.2392%.
You may be running into the same issues that I was encountering with the GRG2 algorithm and Excel Solver. Perhaps, if you input the "converged" values into your data file as initial values, it will converge to the same maxima as mine. That seemed to work for me.
I've found that memory utilization typically isn't the problem. CPU utilization seems to be the biggest bottleneck. I'm not aware of their server architechture. Perhaps, the time differential could be attributed to a highly-scaled CPU architechture on their server. Unfortunately, my algorithm doesn't scale well. I haven't had a chance to code up the SNOPT algorithm yet, but if it completes locally in even twice the time of the NEOS implementation, it's certainly worthwhile (even if multiple optimizations need to be run to get the real maxima).SNOPT and MINOS are quality general-case NLP solvers and AMPL makes using them easy. NEOS is a great way to use AMPL for free although there are some serious memory limitations on the NEOS servers that effectively preclude their out-of-the-box use in large scale combinatorial optimization.
For this type of problem, I'd have consider it unlikely you'd be able to do better with a linear search algorithm although I've been wrong before and either way it's a fun exercise. In fact, this is a great test case that might make me eat my words in short order. What's your final solution?Last edited by MonkeyF0cker; 05-26-12, 05:21 PM.Comment -
For whatever reason, I wasn't able to attach the txt file. My apologies as this will be messy, but here's the staking vector...
0.01332452
0.00395933
0.007951239
0.00545418
0.00074286
0.00409274000000001
0.00973146000000001
0.01420637
0.00815518999999999
0.01302812
0.00997523
0.00425969
0.00831780000000001
0.01522739
0.02073044
0.0037645
0.00171047
0
0.00058638
0.00521416000000001
0.00887979000000001
0.0052438
0.000580490000000001
0.00389651
0.00947454
0.01390042
0
0.00182862
0.00680813
0.01075433
0
0.00179065
0.00487062
0.00535648
0.0090473
0.01617003
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1.01643953670516E-20
The remaining stakes are all 0.Last edited by MonkeyF0cker; 05-26-12, 05:26 PM.Comment -
editComment -
Here's the issue ... when you said "round robins" I took that literally and modified my code (just for this thread
) to constrain all parlays of like dimensions to like risk amount.
When I wrote earlier 'BET 2T 0.6867945898182101%', that was the optimal stake for all 2-team parlays using the literal interpretation of a round robin.
Eliminating that constraint, SNOPT converges to a vector nearly identical to your own in 0.26s of AMPL time. The solutions differ by 0.00016%, although notably lacking in mine is that billionth of a billionth of a percent of bankroll you stake in the last listed position.Last edited by Ganchrow; 05-26-12, 09:44 PM.Comment -
After coaxing AMPL to display the final objective value out to 16 places, my solution yields utility of 0.01557052649820627, utterly destroying your meager value of 0.0155705264982059.
Comment -
LOL. Nice.
Sorry for the confusion. I just assumed that's what Thremp meant by RR optimization since there wasn't really a need for RR's in the traditional sense in the proposed scenario.
From here, I'll code up the SNOPT algorithm and see what sort of results I can obtain locally. I'm pretty curious to see how it compares to the NEOS implementation. I would prefer if I didn't need to rely on an Internet service since there is always a (albeit, likely small) chance of downtime.Comment -
Oddly enough, the NEOS server is hosted by my alma mater...Comment -
Yeah there were good people over there when the project was run out of Argonne Labs. I guess they moved over a year ago.
If you do use NEOS, just remember to use the priority queue for jobs that shouldn't take more than 5 minutes to solve (any longer and drops your connection). That will drastically reduce your wait time during peak hours.
And downtime, by the way, is not unheard of.
You can also download the free student version of AMPL, which limits you to 300 variables and constraints (after presolve, not including constant variable bounds). That's completely realistic provided you're willing to forego the larger parlays.
There's more to that general Kelly script I posted. It uses an an Excel interface, supports wildcard application of assigned parlay odds and betting limits (lower bounds too, so you can assign starting positions), and support for correlation and pushes. It submits (via Perl) either to a local AMPL executable or to NEOS via RPC and upon completion returns everything to Excel.
The code is rather messy (it was all written ad-hoc) but should be easy to improve upon and add features to.Comment -
Let's be very clear you two.
You Do or you DON'T pick winners based on how color coordinated thier uniforms are?
Thanks in advance.Comment -
Ahhh, my friend, you thought I was just goofing, and perhaps you're alluding to home team in whites or lighter colors.
Then I think you would be very interested in a brand new study commissioned out of F.I.T (Fashion Institute) in NYC, that has finally proven the specific effects various color combinations worn by sports teams has on three factors:
1) the team wearing the specific colors
2) the opposing team
3) the officiating if said game
4) the specific sport as a subset to all the above
You won't find this on google, as the compilation of data and results of the study are known to only an opportunistic few.
Turns out I have a cousin who partook in the analization phase.Comment -
Gosh I wonder if this has anything to do with home field advComment -
Actually I think there was a period in NHL where home teams wore white for a while, and in NBA, road teams occasionally wear white when the home team wears alternate unis.Comment -
I think white home jerseys hockey used to be the norm until 4-5 years ago. Maybe the lockout?Comment
