Allowing substituted, unitless signomials in exponents. #1438
Conversation
|
Already encountering issues in Nomials.str_without, since it expects floats as exponents. Will implement fix. |
|
Alright, as I dig I realize there are more and more things to do. I will be tracking signomials with variable exponents with a self.varexps attribute, and making sure we track these variables shortly. |
|
Big picture strategy discussion. These types of expressions are not GP compatible, but are compatible with the exponential cone (possibly requiring some substitutions to get them into an exponential cone compatible form). So this will play nicely with mosek 9. Do we all agree with that overall picture? Do we want something along the lines of Not trying to side track! Just thought it would be a useful high-level discussion. |
|
The primary intended use for this is to allow for obtaining the sensitivities to the exponents. I'm not even thinking about exponential cones atm. But good to think about for the future. I do think that we should strive for mosek 9 compatibility before we consider allowing exponents to be variables anyways. |
| csmap = None # used for monomial-mapping postsubstitution; see .mmap() | ||
| expmap = None # used for monomial-mapping postsubstitution; see .mmap() | ||
| csmap = None # used for monomial-mapping postsubstitution; see .mmap() | ||
| varexps = False # used for signomial exponent operations |
There was a problem hiding this comment.
convention for comments in GPkit is double space between code and #, no alignment
There was a problem hiding this comment.
I think pylint may complain about one of those or the other?
bqpd
dismissed
their stale review
(whoops, thought this was a PR into varexp, not master)
| return self.__class__({key: val**other | ||
| for (key, val) in self.items()}) | ||
| return self.__class__({key: val**other | ||
| for (key, val) in self.items()}) | ||
| return NotImplemented |
There was a problem hiding this comment.
this fallback return statement is currently unnecessary
There was a problem hiding this comment.
lol pylint will catch this though, so I'll stop flagging things I know pylint will catch
|
Wow, this has been an absolute battle against existing GPkit norms. I can hardly get anything to work, since it involves really messing with NomialData and Nomial. I have figured out that I will likely need to store the signomial exponents using an hmap embedded in an hmap. |
Per the issue title, the exponents would be unitless signomials, but it sounds like the intent is for them just to be constant 'variables' such that sensitivities can be extracted. I think this should be made more clear -- is this PR for the general signomial case, or just for fixed variables? |
I wonder if we need to think about how |
|
More difficulties... It turns out that differentiating a variable**signomial is non-trivial. Will try and make it neat. |
|
@bqpd I wanted to ask you a question about differentiation in GPkit. Does it exist anywhere in the core code other than tests? (The derivative of var**sig w.r.t a variable in the signomial has a log, and was wondering how much havoc this is going to cause.) I have already scoured the code but couldn't find anything. Let me know. |
|
hmap.diff is used in monomial_lower_bound creation and in the calculation
of sensitivities for Signomials turned into Posynomials by substitution
…On Fri, Oct 4, 2019, 15:20 Berk Ozturk ***@***.***> wrote:
@bqpd <https://github.com/bqpd> I wanted to ask you a question about
differentiation in GPkit. Does it exist anywhere in the core code other
than tests? (The derivative of var**sig w.r.t a variable in the signomial
has a log, and was wondering how much havoc this is going to cause.) I have
already scoured the code but couldn't find anything. Let me know.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438?email_source=notifications&email_token=AALKAGHMGMY7ALSDU5VAIN3QM6JPRA5CNFSM4I3PSH6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAMUUUY#issuecomment-538528339>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALKAGFGY22EU44QABGNPNLQM6JPRANCNFSM4I3PSH6A>
.
|
|
Oh poop of course. Alright, I will try to make a non-intrusive method. |
|
todo for Ned:
|
|
@bqpd I see that this only breaks test_boundschecking, but what does that f'n actually do? It just seems to have a |
|
@1ozturkbe ah, that means it just checks that |
|
It looks like the error might just be in the type of error raised by cvxopt, which the test expects to be a ValueError but which is now a RuntimeWarning. I'm a little concerned that the error type has changed; this indicates that the bounds-checking in gp.py is no longer raising the ValueError that it should for an unbounded model like this one, but is instead attempting to solve it. Did you disable boundschecking errors? |
|
umm not that I know of! it is possible I created a bug since I have been messing with bounds (since signomial exponents, unsubstituted, cannot bound anything). |
|
@1ozturkbe I'm afraid all the recent changes on master have created some conflicts here...but on the plus side, the removal of 1700 lines of code from GPkit will probably make it easier to implement :p |
|
It's alright. This was quite the mongo chunk of code to do at once... at least I get less code to work with, you are right! |
|
@bqpd I'm never going to get to finish this before I graduate. If you have a desire to continue this (for the sake of getting sensitivities to exponents), feel free to reuse the code. Otherwise, this can be closed for the near future. |
|
@1ozturkbe no worries, makes sense! & let me know if I can do anything to help! |
|
I'll leave it open just for visibility's sake... |
This will take a bunch of work, but I wanted this to be a clear WIP subject to discussion.
Things to do (list will grow):