Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVXR with new mosek problem #49

Closed
ghost opened this issue May 14, 2019 · 3 comments
Closed

CVXR with new mosek problem #49

ghost opened this issue May 14, 2019 · 3 comments

Comments

@ghost
Copy link

ghost commented May 14, 2019

To slove the quadratic minimizatiom problem, I tested a example from stackoverflow and also I found this problem in the issues #40 . But I came cross a new different error. After running the last command result <- solve(prob,solver='MOSEK', verbose=TRUE), the errors showed that:

Interior-point solution summary
Problem status : PRIMAL_AND_DUAL_FEASIBLE
Solution status : OPTIMAL
Primal. obj: 2.9027224916e-01 nrm: 1e+00 Viol. con: 1e-08 var: 0e+00 cones: 0e+00
Dual. obj: 2.9027225465e-01 nrm: 1e+01 Viol. con: 0e+00 var: 2e-08 cones: 0e+00
Error in py_call_impl(callable, dots$args, dots$keywords) :
AttributeError: type object 'solsta' has no attribute 'near_optimal'

Detailed traceback:
File "/scratch/work/dais2/R/CVXR/python/mosekglue.py", line 138, in mosek_intf
return format_results(task, data)
File "/scratch/work/dais2/R/CVXR/python/mosekglue.py", line 207, in format_results
mosek.solsta.near_optimal: s.OPTIMAL_INACCURATE,

It seems that I can obtain the the optimal value. But it still shows the error. So, I think this might be a new bug and I am very sure. The detailed version information are as follows.

sessionInfo()
R version 3.5.0 (2018-04-23)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS/LAPACK: /share/apps/spack/software/openblas/0.3.2/7rbfsnk/lib/libopenblasp-r0.3.2.so

locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] CVXR_0.99-5 reticulate_1.12

loaded via a namespace (and not attached):
[1] Rcpp_1.0.1 lattice_0.20-35 gmp_0.5-13.5
[4] MASS_7.3-49 R.methodsS3_1.7.1 grid_3.5.0
[7] R6_2.4.0 jsonlite_1.6 Rmpfr_0.7-2
[10] R.oo_1.22.0 R.utils_2.8.0 Matrix_1.2-14
[13] lpSolveAPI_5.5.2.0-17 tools_3.5.0 bit64_0.9-7
[16] bit_1.1-14 compiler_3.5.0 scs_1.2-3
[19] tcltk_3.5.0 ECOSolveR_0.5.2

installed_solvers()
[1] "ECOS" "ECOS_BB" "SCS" "MOSEK" "LPSOLVE" "GUROBI"

@ghost ghost changed the title CVXR with mosek problem CVXR with new mosek problem May 14, 2019
@bnaras
Copy link
Collaborator

bnaras commented May 14, 2019

Thanks for reporting this. It is an issue with the newer mosek drivers: they've changed some attributes and no longer include the near_optimal attribute. Will have to make this a defensive fix across versions 7, 8, and 9.

@bnaras
Copy link
Collaborator

bnaras commented May 15, 2019

Pushed out a branch that addresses this issue. Some testing would be welcome.

@ghost
Copy link
Author

ghost commented May 15, 2019

Thank you agian. Obviously, the error has been fixed.

@ghost ghost closed this as completed May 15, 2019
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant