Я написал проблему, используя язык MathProg, чтобы проверить, правильно ли я понимаю некоторые проблемы со смешанными целыми числами. Через некоторое время мне удалось это выяснить, и я могу предположить, что это решение верное.
GLPK Simplex Optimizer, v4.45
37 rows, 30 columns, 97 non-zeros
0: obj = -1.300000000e+01 infeas = 1.300e+01 (0)
* 10: obj = 7.677248677e+00 infeas = 0.000e+00 (0)
* 14: obj = 5.925925926e-01 infeas = 7.889e-31 (0)
OPTIMAL SOLUTION FOUND
Integer optimization begins...
+ 14: mip = not found yet >= -inf (1; 0)
+ 15: >>>>> 5.925925926e-01 >= 5.925925926e-01 0.0% (2; 0)
+ 15: mip = 5.925925926e-01 >= tree is empty 0.0% (0; 3)
INTEGER OPTIMAL SOLUTION FOUND
Time used: 0.0 secs
Memory used: 0.2 Mb (204010 bytes)
...
Model has been successfully processed
Но на самом деле мне нужна та же самая подпрограмма, реализованная в коде C ++. Мне потребовалось некоторое время, чтобы переписать проблему с точки зрения GLPK C API, но во время модульного тестирования я обнаружил, что эта версия C ++ не возвращает решение, так как не существует выполнимого.
GLPK Simplex Optimizer, v4.45
37 rows, 30 columns, 10 non-zeros
0: obj = 0.000000000e+00 infeas = 2.000e+00 (16)
PROBLEM HAS NO FEASIBLE SOLUTION
Очевидно, я сделал несколько ошибок, и мне нужно найти где.
Есть ли какой-нибудь метод отладки или предварительного просмотра, который я могу использовать, например, для просмотра модели, сгенерированной моим кодом C ++ и моделью MathProg для их сравнения? Простое прохождение всех мест, где я мог что-то испортить, было бы каким-то решением, но совершенно неэффективным.
Через некоторое время я придумываю способ исправить свою программу шаг за шагом.
Сначала запустите программу MathProg следующим образом:
glpsol -m model.mod -d data.dat --output solution.txt --wglp glp.mod
Затем запустите испорченную подпрограмму C ++ и после gtl_simplex
выполните следующие команды:
glp_print_mip(problem, "broken_solution.txt");
glp_write_prob(problem, 0, "broken_glp.mod");
От solution.txt
а также broken_solution.txt
Я мог бы выяснить разницу между определением ограничений столбцов и строк. Это помогает, когда мы создаем фиктивный первый ряд, равный функции стоимости, со свободной переменной в качестве ограничения. Поворачивая определения строк и столбцов, мы можем убедиться, что оба файла будут иметь соответствующие строки и определения столбцов в одинаковом порядке.
Как только эти ограничения будут устранены, мы можем приступить к исправлению фактических данных. glp.mod
а также broken_glp.mod
оба будут содержать определения для каждого ограничения, а также значения для каждой строки и столбца. Они 1-индексированы, а 0-ряд является фактором функции стоимости.
Если в программе на C ++ у нас уже есть строки и столбцы в том же порядке, что и в модели, сгенерированной MathProg, мы можем легко сравнить оба файла — но сначала отсортируем их, например. лайк sort glp.mod > glp.sorted
— значения для каждой строки / столбца могут появляться в другом порядке, даже если мы определили строки и столбцы в том же порядке, что и в файле MathProg.
Через некоторое время я смог исправить свою программу, выполнив ту же процедуру, что и MathProg. Единственная разница заключалась в точности отображения, но это только вопрос форматирования вывода.
Других решений пока нет …