bug-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-glpk] GMPL performs correct translation to MPS, but does not so


From: Andrew Makhorin
Subject: Re: [Bug-glpk] GMPL performs correct translation to MPS, but does not solve correctly directly.
Date: Wed, 09 Sep 2015 19:54:37 +0300

Thank you for your bug report.

Please note that your model is extremely badly scaled:

Scaling...
 A: min|aij| =  1.331e-32  max|aij| =  1.000e+00  ratio =  7.510e+31
GM: min|aij| =  2.293e-16  max|aij| =  4.361e+15  ratio =  1.902e+31
EQ: min|aij| =  5.259e-32  max|aij| =  1.000e+00  ratio =  1.902e+31

Since glpsol is based on inexact (floating-point) arithmetic, there may
be large errors in the solution obtained.

Try to remove tiny constraint coefficients (say, whose magnitude is less
than 1e-7) from the model.

You also may try to solve the model in exact arithmetic by specifying
'--xcheck' option to glpsol.


Andrew Makhorin


On Wed, 2015-09-09 at 14:19 +0000, Arts, J.J. wrote:
> Dear Andrew,
> 
>  
> 
> The attached model file contains an LP formulation for a Markov
> Decision Process (it is a small formulation fortunately). For this
> problem, I have also implemented a dynamic progamming formulation. The
> LP formulation in the model file is not solved correctly when I use
> glpsol.exe via GUSEK on a windows 7 32 bit system with 4 Gb RAM. This
> is immediatelyt obvious from the output in the attached file where the
> normalization row should have an activity of 1.0, but an activity of 0
> is reported. However, if I use glpsol.exe to generate an MPS file and
> solve the model from the MPS file, I obtain the correct answer (which
> can be verified from my dynamic programming implementation). This
> behaviour is somewhat dependent on the input parameters. In some cases
> both yield the same result, but in most cases they do not.
> 
>  
> 
> I believe that this result may be somehow due to the fact that I
> compute parameters (which in this case are Poisson probabilities) from
> within the GMPL code (see the section called Transition
> probabilities). I have made LP implementation of MDP problems in GMPL
> before without any problems, but in these implementations I read the
> transition probabilities from a file that I generate in Octave. 
> 
>  
> 
> If you have time to pursue this bug, I would be happy to work with you
> to find it, but I am not sure where to start at this point.
> 
>  
> 
> Regards
> 
>  
> 
> Joachim
> 
>  
> 
> 
> Dr.ir. Joachim Arts
> 
> Assistant Professor
> 
> School of Industrial Engineering
> 
> Eindhoven University of Technology
> 
> Phone: +31 (0)644161529
> 
>  
> 
>  
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]