Oscar Dowson
Oscar Dowson
> It doesn't break the C API so that's definitely not the reason. Looks like it does to me: https://github.com/cvxgrp/scs/blob/c8297172633bcb3a10d4781a19d4769ce5282d29/include/scs.h#L146-L163 This adds some new fields, and `dsize`, `nucsize`, `ell1_size`, and...
> It definitely breaks our interface, but not the C API I guess we're arguing about a very subtle semantic difference. From my perspective, it breaks our interface, and we're...
I've opened a PR to Yggdrasil to recompile: https://github.com/JuliaPackaging/Yggdrasil/pull/12314 Maybe it's time we changed to `300.200.900` version numbers?
> I just create a ScsCone, and set the fields I need This requires the new header to know the correct size of `ScsCone`. > isn't that why we have...
Yip. Pkg doesn't know about build numbers
> Then I think the only sane alternatives are 300.200.900 or waiting for 3.2.10 Yes, exactly. Which is what I could have written explicitly instead of "Maybe it's time we...
Since there has now been a few times we're we've wanted to recompile things between SCS versions, I decided to use the offset: https://github.com/JuliaPackaging/Yggdrasil/pull/12314
> We also have a paper describing these examples in detail. It hasn’t been publicly released yet (it’s been stuck on a desk for a year), but I’d be happy...
> For the nuclear norm cone, we assume m >= n (if that's not the case it should be possible to just transpose the input to the nuclear norm) I...
I have a bridge for transposing in #328, but it would be so much nicer if SCS just did this internally.