sansbacon
commented
4 years ago Can you post the contents of the solution file?
Open anthonyshook opened 4 years ago
sansbacon
commented
4 years ago Can you post the contents of the solution file?
anthonyshook
commented
4 years ago Sure, here it is -- the offending element is on line 259 in this file. The actual error is:
symbol '2262' in wrong position
I've included the entire code block below, but here's just the particular lines, numbers included:
258 > Binaries
259 > 2262d107_4805_4c65_80cc_01d01b984de4
260 > 355f4232_a9ab_43a2_bea5_ee603f8df601
261 > 3dd3dd32_1be4_4e6a_b2a2_5bb75968b6d5
262 > 6635d8a5_3d87_4fa8_94bf_1e610e522c2cSo it looks like the error comes from having the binary variable begin with a number. I recreated the example and saved the .lp file. I then changed the first binary variable to 'aaa' and the error was thrown on the next line of the solver file. You can test this out by editing the .lp file for your specific variables (the GLPK_CMD has a parameter for keepFiles=True which will save the .lp file to your working directory.
The solution for the library could be as simple as including a prefix 'b_' to the UUID with the changes below, although I must confess I don't know much about uuid4 or why it was chosen to create the variable name, but I think this should work:
aggregated_var = solver.add_variable(str(uuid4()), min_value=0, max_value=len(second_team_variables))to
aggregated_var = solver.add_variable(f'b_{uuid4()}', min_value=0, max_value=len(second_team_variables))As an aside, are you using GLPK_CMD for performance reasons? I'd start by filtering the player pool with players that project for at least X fantasy points, which will speed up the default solver.
anthonyshook
commented
4 years ago Hey, thanks for digging into this! I figured it would end up something like that -- never trust a number to do a letter's job.
And yes, it was for performance reasons, but I actually just switched over to using CPLEX_PY as my solver, and that has been successful so far. I've got a fork here where I can test the change to the aggregated_var call, when I've got the time, but unless @DimaKudosh (or you!) wants to tie this to a PR, I think it could be closed.
There is seemingly a bug with the restrict_positions_for_opposing_team method when using GLPK as a solver.
The following code works fine with the default CBC solver.
But when I change the solver to GLPK_CMD from the PuLP package, and try to run the same code, I get the error:
(note, ~ have been used to replace the path to my local user temp folder)
Any thoughts on why? Or do we think this is just an GLPK problem that can't be solved on the PYDFS end?