Dynamic Interest Rate #1221
Dynamic Interest Rate #1221
Conversation
Codecov ReportBase: 73.32% // Head: 73.30% // Decreases project coverage by
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## master #1221 +/- ##
==========================================
- Coverage 73.32% 73.30% -0.03%
==========================================
Files 74 74
Lines 12122 12120 -2
==========================================
- Hits 8889 8885 -4
- Misses 3233 3235 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
This seems like a sound temporary fix. But this problem illustrates why my strongly held view is that the default way of building models should be to define a terminal period, then define the problem for My way of doing things would get rid of a lot of extraneous baggage (like this). Wish we'd done it that way from the start. (My fault that we didn't). |
|
@dedwar65 if this gets merged before yours, then the process should be to merge master back to your PR, then address any conflicts that come from that. Trying to preempt changes before they are on master might cause more issues. We can work on it together once it's needed. |
alanlujan91
added
the
Ready-To-Merge
|
@alanlujan91, this is not marked "Ready-To-Merge" but my sense is that you think it is? I guess we still don't have a workflow to test a PR against DemARKs; but if I merge it, can you trigger a retest of the DemARKs and reverse my merge if problems crop up? |
|
This is tagged as Ready to Merge. Not sure why you can't see it. But yes I can revert if needed. |
|
Oh, I see the Ready-To-Merge label now. Didn't know where to look. Merging ... |
This should close one of #1106 or #1132 or both. Should also address sbenthall/SHARKFin#186 (comment).
Can @wdu9 and @dedwar65 also review this?
With apologies to @dedwar65, this might affect #1219. (Going back to
agent.Rfreewithout index in notebook).The logic is as follows:
If Rfree is an int, float: it is time invariant.
If Rfree is a list of length 1: it is time invariant and recast as a float.
If Rfree is a list of length n>1: it is time varying and should be same length as T_cycle.
If Rfree is an array: it is time invariant (for Markov types)
Everywhere else where we want to use Rfree (as in calculations) we should first check the type then use appropriately (indexed if time varying).