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

Mosek support for complex data #684

Open
jdbancal opened this issue Jan 28, 2020 · 7 comments
Open

Mosek support for complex data #684

jdbancal opened this issue Jan 28, 2020 · 7 comments

Comments

@jdbancal
Copy link
Contributor

It seems that Mosek supports SDP problems specified with complex coefficients (tested on MOSEK Version 7.1.0.14), however in definesolvers.m, the Mosek SDP solver is defined as not supporting complex problems.

Complex problems are still solved through yalmip's automatic translation into a real equivalent, but dual variables are then inaccessible (NaN values are returned).

Would it be possible to allow calls to Mosek for complex problems, hence returning dual variables seemlessly?

@johanlofberg
Copy link
Member

johanlofberg commented Jan 28, 2020

At the moment a bit of a mess to accomplish, as far as I can recall. I'll keep this open though

@jdbancal
Copy link
Contributor Author

Thanks for your understanding, I can totally imagine it could take quite some work to implement something like that properly, even just for SDPs.

Looking for a possible temporary workaround, I found only three solvers with solver.complex set to 1 in definesolvers.m. These are SeDuMi versions 1.03, 1.05 and 1.1, which are quite outdated and should probably not be used anymore. Do you know why complex support was disabled for SeDuMi 1.3? On my side, this solver seems to at least accept complex data. Wondering if supporting this version of SeDuMi would be easier to implement than Mosek (hence at least allowing full complex support for one maintained solver).

@johanlofberg
Copy link
Member

I cannot see anything in the commit history, so I guess it was turned off before 2012, and my guess it was due to simplify the code (little used feature so low pay-off to fix issues). In 1.03-1.1 it is probably just kept by mistake as those are dead

@jdbancal
Copy link
Contributor Author

Oh, I see, then there's probably no quick workaround.
Thanks for your feedback!

@johanlofberg
Copy link
Member

and a fundamental problem in YALMIP is that there is no complex variable. x = sdpvar(n,n,'','complex') simply generates a+b*i with structure on a and b, i.e. the complex cone is disaggregated from start.

@jdbancal
Copy link
Contributor Author

Hmm, that needs not be a problem...
If I have a chance I might take a closer look at this issue

@johanlofberg
Copy link
Member

OK.

So basically when setting complex to 0, YALMIP takes C-Ay and maps it to the real cone by doubling dimensions, and then sends the data C and A for that lifted formulation. When set to 1, the complex data C and A will be sent to the interface code (callsedumi.m). It's probably not too hard with sedumi, as it was supported previously

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants