Thank you for the bug report.
> When running the glpsol command line for the MIP model.mps everything is
> OK, optimal solution is found.
> But when I launch it with the --intopt option, GLPK crashes (see
> crash.txt file).
> It seems that for a column, ipp_tight_bnds() function returns 0, becau
> I had no problem building glpk 4.28 under Mac OS X 10.4.11 and
> 10.5.2, but under 10.3.9 I get the following error:
> gcc -DHAVE_CONFIG_H -I. -I.. -I../include -g -O2 -MT glpsql.lo -MD
> -MP -MF .deps/glpsql.Tpo -c glpsql.c -fno-common -DPIC -o
> .libs/glpsql.o
> glpsql.c:239: error: parse er
> the error was possibly caused by an old iODBC release.
> Please, consider the proposal by Marius to allow specifying the path to
> the include files for MySQL (and iODBC) when calling configure.
It seems to me that headers and libraries in /usr/local/ are available
by default. Or am I mistaken?
> using glpk-4.28
> ./glpsol -m tsp.mod --mipgap 1000
> gives
> INTEGER OPTIMAL SOLUTION FOUND
> ./glpsol -m tsp.mod --tmlim 1
> gives
> TIME LIMIT EXCEEDED; SEARCH TERMINATED
> ./glpsol -m tsp.mod --mipgap 0.05
> gives
> TIME LIMIT EXCEEDED; SEARCH TERMINATED
> I would rather expect a text ind
> GLPK 4.28 does not correctly report SQL errors when failing to select
> data via a table IN statement.
> Example:
> Wrong error reporting:
> db_iodbc_open: Query "SELECT job, operation, machine, duration FROM dsp
> WHERE problem = FT10" failed.
> The driver reported the following diagnostics whi
Xypron,
Thank you for your bug report.
> running glpsol --cuts on the following model gives an error
> Model has been successfully generated
> ipp_basic_tech: 5 row(s) and 0 column(s) removed
> Assertion failed: ipp != ipp
> Error detected in file ..\src\glpipp02.c at line 801
> glpsol --versi
>> I am currently experiencing a problem getting
>> 'minimization' to stick, even though I set this flag
>> explicitly with 'glp_set_obj_dir' and 'glp_get_obj_dir'
>> returns 'GLP_MIN' before and after the solver call.
This is strange, because the direction flag is explicitly stored
in the problem
- - -
1 x1 * 4096 1 1
2 x2 * 4095 1 1
Integer feasibility conditions:
INT.PE: max.abs.err. = 0.00e+00 on row 0
max.rel.err. = 0.00e+00 on row 0
High quality
Saturday, July 12, 2008, 5:56:31 PM, you wrote:
> * Andrew Makhorin <[EMAIL PROTECTED]> [2008-07-12 16:06]:
>> The failure appears due to insufficient robustness of the glpk mip
>> solver. It is mainly caused by unbounded integer variables (x1 and x2
>> have no upp
0; 69)
INTEGER OPTIMAL SOLUTION FOUND
Time used: 0.1 secs
Memory used: 0.1 Mb (151279 bytes)
Thank you for your interest in glpk.
Best regards,
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> Good evening, I sometimes find negative solutions of the simplex method
> from glpkmex though I impose the parameter "lb" to 0. This happens
> sometimes when I must resolute large or very large programmation
> problems. What's the problem? The software is not totally reliable for
> large problems
(except those which are explicitly defined in
configure.ac) are automatically inserted in the configure script by
autoconf.
> These comments aside, the configure help screen is very
> clear and informative.
> Many thanks to Andrew for developing and maintaining
> GLPK and for h
> I #39;m using GLPK (4.25) and I have a program that works very well in
> a x86 (IA-32) architecture.
> I started to port my program to a SGI-Altix (8 x Itanium IA-64) and
> when a call a lpx_read_model function a get a Bus Error.
> I know this error is caused by unaligned acess of memory
> (htt
> I am trying to access constraint coefficient matrix. When I use
> function glp_get_num_rows, I am getting unexpected number of rows.
> In model assign.mod (from standard glpk examples), there are 8
> elements in each of set I and set J. So total number of constraints
> should be 16. But function
irectory
> Command exited with non-zero status 127
Probably there is some confusion. Options --enable-dl and --disable-dl
concern the shared library support used by some glpk modules. If you
need to build the shared/static glpk library, you should pass options
--enable-shared and/or --enab
Hi Robbie,
Thank you for your exhaustive comments.
> Please note: further testing revealed another related
> problem for 4.30:
> $ make distclean
> $ ./configure --enable-dl
> $ make
>...
>gcc -DHAVE_CONFIG_H -I. -I.. -I../include -g -O2 -MT glplib12.lo \
>-MD -MP -MF .deps
other routine (which provides solution
of current lp relaxation and which should be replaced by a more robust
version). I hope to resolve the issue in 4.31.
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listin
A bug has been detected in the MathProg translator. Due to this bug
iterated expressions having an indexing expression whose dummy indices
are bound to some values, i.e. like 'sum{(i+1,j,k-1) in E} x[i,j,k]'
are evaluated incorrectly. Namely, current value of such expressions
is not invalidated whe
> in the lpx_simplex method of GLPK 4.31 (and 4.30), a bad initial basis
> yields a return code LPX_E_FAULT, while I would expect to get an
> LPX_E_BADB. I think this just needs a little change at glplpx01.c:379.
Lpx_simplex is obsolete and kept only for backward compatibility.
Since it does not r
> in order to get a GLPK 4.31 library linked with other code, I had to
> change line 29 of glpscl.h from
> #define scale_prob _glp_scale_prob
> to
> #define scale_prob glp_scale_prob
> According to glpapi04.c, glp_scale_prob does not have an underscore in
> the beginning.
There are two routines:
> the following model code creates a segmentation fault:
> table ta { l in LOCATIONS } OUT
> 'iODBC'
> 'DSN=glpk;UID=glpk;PWD=gnu'
> 'UPDATE result_t12 SET DATE = ' & date & ' WHERE ID = 4'
> 'UPDATE result_t12 SET QUAN = ? WHERE LOC = ? AND ID = 4' :
> quantity[l], l, 4 ~ id;
> The numb
UND
Integer optimization begins...
+ 478: mip = not found yet <= +inf(1; 0)
+ 478: >>>>> 1.531894909e+10 <= 1.531894909e+10 0.0% (1; 0)
+ 478: mip = 1.531894909e+10 <= tree is empty 0.0% (0; 1)
INTEGER OPTIMAL SOLUTION FOUND
The error looks the same as described in the article:
A. Neumaier and O. Shcherbina, Safe bounds in linear and mixed-integer
programming, Math. Programming A 99 (2004), 283-296
www.mat.univie.ac.at/~neum/ms/mip.ps.gz
when a problem found primal infeasible becomes primal feasible after
tightening bo
; k <= dca->na; k++)
xfree(dca->arg[k]);
xfree(dca->arg);
}
(in the internal routine free_dca (glpmpl03.c), which is called
from mpl_terminate in case of error), because some dca->arg[k] is
not initialized (contains 0x3f3f3f3f written by xmall
To fix the bug reported by Xypron please apply the patch below.
Note that the bug will be fixed in the next release of the package.
*** glpk-4.31/src/glpmpl03.cTue Sep 2 12:00:00 2008
--- glpk-4.32/src/glpmpl03.cThu Sep 4 12:00:00 2008
***
*** 4895,4900
--- 4895,4903 ---
> in particular, in the cplex lp file Yi0_copy should be
> specified as follows:
> Bounds
> Yi0_copy = 1
This is not necessary, because glp_read_lp correctly set the types
of variables having identical lower and upper bounds to GLP_FX.
___
Bug-glpk
> I have a problem for integer variables with a lower bound equal at upper
> bound.
> I obtain this error message:
> lpx_intopt: column 1 has incorrect bounds
> My problem is:
> PROBLEM: spConf_ whose formulation ref number is 1
> Minimize
> Objectif: -11.6667 Yi0_copy -11.6667 Yi1_copy -5 Yi2
lt;= 10
> Bounds
> 1 <= Yi0_copy <= 1
> 0 <= Yi1_copy <= 1
> 0 <= Yi2_copy <= 1
> 0 <= Yi3_copy <= 1
> 0 <= Yi4_copy <= 1
> 0 <= Yi5_copy <= 1
> 0 <= Yi6_copy <= 1
> 0 <= Yi7_copy <= 1
> 0 <= Yi8_copy <= 1
>> I don't use functions glp_read_lp or glp_read_cpxlp.
>> And, I use GLP_FX (not GLP_DB) to fix bounds for the first variable.
>> So, I don't understand.
>> And, when I use lpx_write_cpxlp, I obtain this result.
>> The problem is that variables aren't integer and the first variable bound
>> is
> I am working on GLPK 4.32 and ran in to the following error while
> trying to use the table command. Is there a known bug in the version
> that handles tables ? Many thanks || Sincerely || Rajesh
> --
> [EMAIL PROTECTED]:~/gl
> I have run into a problem building octave 3.0.3 against glpk
> version 4.32. When I investigated the issue, I found that the build
> works correctly for version 4.31, but not 4.32. The offending
> symbols are
> For version 4.32:
> nm /usr/local/lib/libglpk.0.17.0.dylib | grep 'lib_[a-z]*_hook'
>> I check my code and I resolve my problem. But, an other problem appear.
>>
>> When I fix a variable at one, and after, I define the type as binary, then
>> the lower bound is 0 instead of 1.
>>
>> I resolve this problem in declaring variables as integer. But, why
>> glp_set_col_kind redefine t
glpk/trunk/glpk-4.32/src/glpsql.c?view=diff&r1=297&r2=294&diff_format=h
Please gzip the new version of glpsql.c and post it to me via e-mail.
Thanks.
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> I have this problem:
> When I use this routine (lpx_intopt(glpkProbPtr)), my problem is solved
> normally.
> But, when I use this routine
> (glp_intopt(glpkProbPtr,&glpkParamMipPtr)), my
> problem doesn't solve the problem.
> The error message is: glp_intopt: optimal basis to initial LP relaxa
Hi Robbie,
> I am having trouble linking against my new build of
> GLPK 4.33. This is somewhat puzzling as my build
> process is the same as always. First, my config
> options are:
> $ ./configure --disable-shared --with-gmp
> After installing, I get:
> $ glpsol --version
> GLPSOL: GLPK
A bug has been detected in the cplex-like interface to glpk api
(routine CPXdelsetrows).
To fix the bug right now please replace all files in subdirectory
examples/cplex (glpk 4.33) by the patched files attached.
cplex.tar.gz
Description: GNU Zip compressed data
__
> "0 ** 0; result undefined "
> Result of 0 ** 0 is defined, it #39;s 1. That #39;s all.
In the strong mathematical sense 0 ** 0 is undefined. Defining 0 ** 0
as 1 violates continuity and sometimes may lead to false conclusions.
Nevertheless, if you disagree with that, you can always check oper
> the glp_copy_prob() does not create name index in glpk 4.33.
> The patch solves the problem.
Thank you for your report.
The name index is not created intentionally, because if it is not
needed, creating it would waste the time. It is assumed that the
application creates it with glp_create_index
> According to ISO/IEC 9899:TC2 (ISO C99)
> A domain error may occur if x is zero and y is zero. (in function pow).
This standard also says (see subsection F.9.4.4, page 460):
pow(x, 0) returns 1 for any x, even a NaN.
However, this does not mean that the GNU MathProg must follow the same
con
> no idea if the MathProg statements below are legal.
> However, I'm sure the solver should not crash :)
> $> cat segfault.mod
> set samples dimen 4;
> set bnodes := (setof{(sid, bid, temp, rep) in samples: bid !in bnodes}
> bid);
> display bnodes;
> data;
> set samples :=
> # sid bid temp re
> set A := A;
> display A;
>
> results in a segmentation fault.
>
> The error is in function
> SET *set_statement(MPL *mpl)
> the same error is in
> PARAMETER *parameter_statement(MPL *mpl)
No, this is not a bug. MathProg allows recursive definition of sets
and parameters, and in your example '
See, for example, the model examples/bpp.mod, where parameter z is
defined recursively.
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> I see the point for indexed parameters (or sets) with bpp.mod. My
> solution is only valid for non indexed parameters and arrays.
> How about the following solution: When evaluating an element of a
> parameter GLPK "earmarks" it as being in evaluation. If the same element
> of the parameter is
> constraint
> s.t. cost {i in N, j in N} :
> t[i] - t[j] - sum{(i,j) in E} c[i,j] * x[i,j] >= 0;
> leads to error
> 0-ary slice not allowed
> in glpmpl01.c, function expression_list.
> My expectation was that the sum is 0 if (i,j) is not an element of E and
> c[i,j] x[i,j] otherwise. This w
>> constraint
>
>> s.t. cost {i in N, j in N} :
>> t[i] - t[j] - sum{(i,j) in E} c[i,j] * x[i,j] >= 0;
>
>> leads to error
>
>> 0-ary slice not allowed
>
>> in glpmpl01.c, function expression_list.
>
>> My expectation was that the sum is 0 if (i,j) is not an element of E and
>> c[i,j] x[i,j]
>>> Just for clarity.
>>> Do you agree that the following notation is meaningless?
>>> sum{(2,3) in E} c[i,j] * x[i,j]
> The following model is correctly solved by GLPK:
> set E := {(2,3)};
> var v{(i,j) in E};
> s.t. con1 {(i,j) in E} : v[i,j] - sum{(2,k) in E : k == j} 1 = 0;
> var w{(i,j) in
case GLP_DB:
xassert(lb <= new_ub && new_ub <= ub - 1.0);
dn_type = (lb == new_ub ? GLP_FX : GLP_DB);
xassert(lb + 1.0 <= new_lb && new_lb <= ub);
up_type = (new_lb == ub ? GLP_FX : GLP_DB);
break;
default:
xassert(type != type);
}
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
because removing the call causes the error to
disappear.
I am not a C# programmer. May be you could tell me what is wrong?
Thanks,
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> I tried to run your example, t1.cs, with MS Visual Studio 2008, and
> encountered an error. Stripping the code off I detected that the error
> happens in the destructor.
I found what causes the bug. Looks like a system call to DllMain due
to the reason DLL_THREAD_DETACH or DLL_PROCESS_DETACH (in
> the model below leads to glpsol ending without result or error.
> I would have expected an error message like "illegal recursion" if
> the param statement cannot be resolved by the current implementation.
(FYI: In error messages the GNU Coding Standards recommends to use
the adjective "invalid"
> I received the error
> min{} over empty set; result undefined
> for the following statement.
> param ti{i in O} := max( ti0[i] , min( ta0[i], min{(i,j) in V diff I }
> ti0[j]) - d[i] );
> Currently for operations over sets in GLPK the following definitions
> have been made:
> prod{i in {}} i =
> the following problem written in CPLEX format results in a binary
> error with the variable RutilScBin/RutilscL.
> Since glpk doesn't support semi-continuous variables I tried to simulate
> it - and got the described error. So where is the problem? By the way,
> CPLEX results in the same error bu
em
> header file, since this is a Sun operating system.
Thank you for the bug report.
> Would it be possible to just rename this variable?
It is sufficient to #undef it.
I have fixed the bug. The changes will appear in the next version of
package.
Andrew Makhorin
___
not using threads.
Glpk routines do not write anything to memory blocks which were
allocated by someone else, and do not kill any threads of the distributed
shared system.
Could you provide more detailed information? Does the error happen within
a glpk routine? If so, in which one? Thanks.
Andrew M
> I found a strange behaviour of glpk library.
> The glp_write_lp function aborts the entire program
> when problem to write is empty.
> I don't think it is a desired behaviour (especially when problems
> are generated from dynamic data)
> In my opinion, this function should instead return an
> err
> when using GLPK with MySQL ODBC Connector 5.1 on 64bit Windows an error
> occurs.
> Please, apply the patch below to file src/glpsql.c
Done.
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
A minor bug has been detected in the interior-point solver:
if the problem is scaled, dual solution components are computed
incorrectly.
To fix the bug please replace line 445 (file glpapi08.c):
temp = lpx_get_obj_coef(lp, k) / sjj;
by the following line:
temp = lpx_get_obj_co
he solver reports the (wrong) optimum:
x = 134 and y = -670.
It is wrong, because the constraint
1 <= a*x+b*y <= guess;
is violated; in fact:
a*x+b*y = 75 * 134 - 15 * 670 = 10050 - 10050 = 0
However, the vio
> I am testing GLPK 4.36. I tried a test case that I have also used with
> GLPK 4.19.
> Maximize
>40 * x1 + 60 * x2
> subject to
>0 <= x1
>0 <= x2
> 70 <= 2 * x1 + x2
> 40 <= x1 + x2
> 90 <= x1 + 3 * x2
> This problem is primal feasibl
>> I am testing GLPK 4.36. I tried a test case that I have also used with
>> GLPK 4.19.
>
>> Maximize
>>40 * x1 + 60 * x2
>> subject to
>>0 <= x1
>>0 <= x2
>> 70 <= 2 * x1 + x2
>> 40 <= x1 + x2
>> 90 <= x1 + 3 * x2
>
>> This problem is
> The documentation says:
> GLP_PRIMAL-use two-phase primal simplex;
> GLP_DUAL -use two-phase dual simplex;
> GLP_DUALP -use two-phase dual simplex, and if it fails, switch to the
> primal simplex.
> Your point is that the dual simplex has solved the dual problem--the
> dual problem is infeasible
> Versions 4.35--4.37 of glpk have failed to build on SGI IRIX MIPS, but
> I only today had the time to figure out why.
> The problem is this definition in the native file:
> #define _G 0x4000 /* Graphic characters only */
> It conflicts with this piece of code in src/glpnet0
wnload the glpk distribution tarball from
ftp://ftp.gnu.org/gnu/glpk/ or from some mirror ftp sites (see
http://www.gnu.org/order/ftp.html ) and build the package in usual way.
Both the glpsol options must work.
Andrew Makhorin
___
Bug-glpk mailing list
> Error detected in file ..\src\glpmpl06.c at line 760
Thank you for the bug report.
The error appears due to incorrect numeric data on reading csv or dbf
file. There must be an error message rather than abnormal termination,
however, I just missing that when was writing the code.
Andrew Mak
> please, apply
> chmod 755 examples/sql/mysql_setup.sh
> The file should be executable.
Done.
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
hen a computer program is really crashing, it never says
about that :). I will replace this message by a more friendly one like
"Constructing initial basis..." . Thanks.
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> Hi, I'm new to GLPK and I need help. I'm trying to solve a problem with
> GLPK (or, at least, to write LP problem) but the solver crashes and I
> don't know why...
> I'll attach you mod and dat file:
> http://www.nabble.com/file/p23556429/FP.mod FP.mod
> http://www.nabble.com/file/p23556429/zona
the standard says nothing about
locale-specific decimal separator in atof and scanf. So I wouldn't like
to use locale functions at all in the glpk code.
Probably strtod should be replaced by something like xstrtod.
BTW, in the standard C on program startup the current locale is "C".
Is locale changed intentionally in your application?
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> I'm sorry to say I think I may have found a small bug in amd_order.c
> When using glpk 4.38 and I try to solve this problem with the interior
> point method (either null or default params) :
> Minimize
> obj: - x_4 - x_5
> Subject To
> r_1: + x_4 - 2 x_1 = 4
> r_2: + 2 x_5 + x_2 = 1
> I modified the introductory example from the manual to use the
> interior-point method:
> [...]
> It compiles and runs but finishes with a null pointer:
> j...@jisp:~/pure/glpk/pure-glpk$ ./ipt_test
> Original LP has 3 row(s), 3 column(s), and 9 non-zero(s)
> Working LP has 3 row(s), 6 column(
> There seems to be something wrong with the parameter block in the
> glp_interior call. When I define the parameter block, try to change the
> ordering method and pass the block to glp_interior I always receive
> precisely the same output including AMD ordering method.
Please check your code. I
> Please forgive me if this is not in the correct format. If there is a
> better way to submit this report please advise me.
> A research group I work with has been using GLPK and CPLEX for the
> past four years to solve queueing network problems. Most of our work
> occurs during the summer. Re
Hi Xypron,
> some typos exist in output strings. See patch below.
Thank you for your attention.
Best regards
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
you are solving. It appears, because
the timer value determined by the routine happens to be less than
its value in the past.
Does the error happen regularly or randomly? On which platform are
you running glpk?
Andrew Makhorin
___
Bug-gl
> I am writing to report what looks like a bug in glpk-4.39, that,
> surprisingly, is not there in glpk-4.26.
> Below, I first describe the problem, and its output when run with
> glpk-4.39 on a pc running fedora-11. It is solved incorrectly by
> glpk-4.39. Then, I will give the output of glpk-4.2
tes)
You could try to use a more stable form of the basis factorization,
for example, bfcp.type = GLP_BF_GR (that corresponds to glpsol
option --cgr) with the api routines glp_get_bfcp/glp_set_bfcp. This
may help.
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
;dump' file in decimal floating-point format
with 16 decimal places?
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
7: obj = 3.029052923e-002 infeas = 0.000e+000 (0)
*29: obj = -1.0e+000 infeas = 0.000e+000 (0)
OPTIMAL SOLUTION FOUND
Never gets here!
However, a much better way is to replace tiny constraint coefficients
by exact zeros.
Andrew Makhorin
___
> I am sure we both agree that getting into an infinite loop is not
> acceptable.
>> and applying geometric mean scaling makes the instance badly scaled.
> What is your opinion about the Curtis-Reid scaling algorithm?
I do not think that another scaling algorithm would help. The defect
is in the
gt;= 4.295331243e+04 < 0.1% (7; 8)
+47: mip = 4.295372226e+04 >= tree is empty 0.0% (0; 27)
INTEGER OPTIMAL SOLUTION FOUND
Time used: 0.0 secs
Memory used: 0.1 Mb (113395 bytes)
Andrew Makhorin
glpkin1.lp
Description: Binary data
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
Looks like large constraint coefficients cause the effect described
in the paper:
A. Neumaier and O. Shcherbina, Safe bounds in linear and mixed-integer
programming, Math. Programming A 99 (2004), 283-296.
http://www.mat.univie.ac.at/~neum/ms/mip.pdf
when tightening the feasible region "improves"
>> I do not think that another scaling algorithm would help. The defect
>> is in the simplex solver.
> Could you please fix that? Would it be a lot of work?
It is not so easy. Currently, if some basic variables violate their
bounds due to excessive round-off errors, the primal simplex switches
to
0 1.28218e+20
148 move[2,3,2] B -0.682574 0
149 move[2,3,3] NU 0 0 2.55832e+20
150 move[2,3,4] NU 0 0 < eps
Andrew Makhorin
___
B
> with the attached lp, I get an assert in glpnpp01.c at line 634:
> GLPSOL: GLPK LP/MIP Solver 4.39
> Reading problem data from `glpk_nppassertfail.mps'...
> Problem: Objective: R000
> 7 rows, 26 columns, 38 non-zeros
> 75 records were read
> Original LP has 7 rows, 26 columns, 38 non-zeros
Hi Xypron,
> I have solved the model below with
> glpsol.exe --fpump -m test.mod --tmlim 30
> (derived from
> http://lists.gnu.org/archive/html/help-glpk/2009-09/msg00015.html
> http://lists.gnu.org/archive/html/help-glpk/2009-09/msg00015.html
> )
> The output was
> + 1763: mip = 1.04149
> I guess what is missing either in function glp_ios_heur_sol() or in
> ios_feas_pump() is to
> solve the original problem with the integer values found.
Ios_feas_pump provides a complete mip solution.
> I would prefer glp_ios_heur_sol to call glp_simplex. This would allow to
> check the feasibi
Hi Xypron,
C:\>>glpsol.exe --dfs --nopresol -m s.mod
> gave the following output
> GLPSOL: GLPK LP/MIP Solver 4.39
> Reading model section from s.mod...
> 132 lines were read
> Generating start...
> Generating end...
> Generating onemove...
> Generating delta...
> Model has been successfully gen
a new integral solution, a
> constraint is added to increment the objective by 10 %
> which may be more than the gap to the LP solution.
Thank you for the patch. I need some time to check the code, and then
I will include it in the heuristic module.
B
a new integral solution, a
> constraint is added to increment the objective by 10 %
> which may be more than the gap to the LP solution.
See the patched version of glpios10.c attached. It will be included in
the next version of the package.
Could you please check the modifications once ag
> the modified patch works fine with my examples.
Thanks.
> I guess the coding after
> #if 0 /* modified by xypron */
> up to
> #else
> should be removed from the coding as the coding is incorrect for dir ==
> GLP_MAX.
Why incorrect? It is another heuristic to choose bnd; probably it is
more ag
> I am not sure if this is a bug or not, but I am not able to get
> sensitivity bounds for the following simple example.
Thank you for the bug report.
There is a bug in the bound sensitivity routine: it works only for
minimization while your instance is maximization.
To avoid the bug you can rep
> the problem below can be solved by the dual simplex
> glpsol.exe -m test.mod --dual
> Yet glp_get_dual_stat() returns
> GLP_INFEAS dual solution is infeasible
> for the problem when called in glplpx03.c.
> The dual values for the constraints are
> c1: 1.00
> c2: 1.00
> c3: -0.0
Hi Xypron,
> the problem below can be solved by the dual simplex
> glpsol.exe -m test.mod --dual
> Yet glp_get_dual_stat() returns
> GLP_INFEAS dual solution is infeasible
> for the problem when called in glplpx03.c.
> The dual values for the constraints are
> c1: 1.00
> c2: 1.00
>
e (see attachment). It is assumed that you have glpk
version 4.39.
Andrew Makhorin
glpapi12.c.gz
Description: GNU Zip compressed data
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> glpsol -m big.mod -o a.log
>
> the attached file is model file
>
> it seems take too much time to have a
> result
>
> could anybody help me?
Try:
glpsol -m big.mod --mir
Using mir cuts the solution takes about 30 secs on my machine.
__
> Andrew,Tks.really really good.
>
> it takes about 68.9 secs on my machine
>
> I'm not good at maths.
> What's the reason for --mir?
Your instance is hard for the branch-and-bound method used by
default in glpsol to solve mip. Specifying '--mir' option you
enable using the branch-and-cut method
e iteration and produces the log.txt console output. I can
> only reproduce this in the Windows environment.
I need a time to check your code.
Andrew Makhorin
___
Bug-glpk mailing list
Bug-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-glpk
> I am using gplsol.exe v4.40 in standalone mode:
> 32 bit version compiled with Visual Studio Express 9.0
> I am using the ODBC driver Running on Windows 7 64 bit
>
> I made a single change in glpmpl.h in order to accommodate large ODBC
> queries (string literals):
> #define MAX_LENGTH 1024 wa
> the following model returns an error
> "write error on - output buffer overflow"
> for {i in 1..2000}
> printf "%6s", "x";
> end;
> Currently the output buffer is only flushed when reaching a new line.
> For very long output lines the buffer should be flushed instead of
> throwing an error.
>>> I removed the buffering at all. (This was needed due to an old version
>>> of glplib which allowed printing only an entire line.)
> some operating systems often are very slow on single byte file ouput
> because the changes are immediately written to disk. Hence buffering
> may make sense.
I m
101 - 200 of 555 matches
Mail list logo