-
Notifications
You must be signed in to change notification settings - Fork 274
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
[BUG] Caching of ci in ModelResult.conf_interval() to simple #791
Comments
@Tillsten Hm, I guess the intention is sort of obvious, but did maxiter get exceeded by the fit? Should Currently, ModelResul.conf_interval is just passing **kws to the conf_interval function. So either |
I am not sure what you mean by "ModelResult caches the result of conf_inveral()" - I don't see anything special happening there or? I have never been really a fan of the apparent possibility to change parameters for CI calls. In my opinion this run is tied to the Minimizer and the MinimizerResult, so why can you not just to the fit again with the parameters you want (or just set it higher to start with from the beginning)? I doubt that there are many cases that this is such a time-consuming thing that it is really a limiting factor, but perhaps I am not understanding the issue correctly. |
@reneeotten @Tillsten looking at the code for the Adding some print statements to a reasonably well-behaved test case (where error bars were estimated), it actually needed like 5 iterations, but it was seeing the A more complete example would be helpful. |
Sorry for the intial bad bug description. As Matt mentioned, the maxiter is the iteration used in the ci calculation, I just took one of the possible keyword arguments of the ci calculation. The mentioned issues is that the second call does return the result from the first one. The conf_interval() methods internally caches the result in ci_out, and if available returns it. The only issue with that, that it does not take different kwargs into account. The easy workaround is to set ci_out to None. |
@Tillsten I did not get that at all from the original issue! |
To clarify this issue: Here's the code for
The problem is that the result of the There are a few possible solutions. The most sophisticated would be to memoize the calling signature in addition to the results. So that would be to set A simpler brute force option would be a a third bruter solution would be to just always recalculate the confidence intervals. My opinion: I don't think this is a good use case for memoization at all. For my use cases confidence interval calculation is never anywhere near prohibitive enough that I can't call it whenever I like. But even it was I would handle the memoization on the user end (rather than See my suggestion which duplicates this bug for another example of surprising results due to this memoization: #796. |
Oh, in many of my usecases the CI calculation takse quite some time, still I am fine with removing the caching, since the result is still saved on the object. Alternativly, maybe just putting lru_cache decorator on the method works? Btw, some of the problematic use cases are properly due not well tought out values in the CI calculation, since I did not really tested their influcence. In addition, the output of the ci function is rather unwidely. Adding the result to the parameters themself would also make sense in retrospect. |
@jagerber48 @Tillsten The output of the I would suggest that it is not a violation of the API or actually unreasonable to cache the values, but then always recalculate them and then update and return that cached dictionary. In that case, it's always an update. Then increasing Does that seem reasonable to you two? |
@newville having the method save it's result into The only thing I don't exactly understand is what you mean by "and the user would have to explicitly clear previous results", but I assume you just mean that if the user has saved the calculated confidence interval into |
@jagerber48 By "and the user would have to explicitly clear previous results" I meant that if the user wanted to clear out any previous calculations, they would need to either explicitly set FWIW, I would suggest that we can declare the current behavior a bug that we want to fix, and not worry about backward compatibility. |
@newville I guess I'm still not fully following your logic.
I just removed the I'm not sure what the behavior would be for your
If so the Just to post a third code block for reference:
This is I guess the most sophisticated option that allows Nonetheless, I still prefer the simple first option where |
@jagerber48 I was sort of thinking of something like:
Does that look reasonable? That tries to express "new calls of I believe that is separate from #797 (I have not looked at it closely yet: in meetings!), but I maybe they are related. |
@newville Ah I see, that seems fine. For my use case I only use the But that's getting deep into edge cases and I'm not really worried about it, especially if the user is explicitly calling for that behavior with |
I would be fine and would prefer just overwriting ci_out in case of another call to conf_inf. |
@Tillsten @jagerber48 I am ok with "always overwrite" or "overwrite by default but allow updating" or "update by default but allow overwriting". I would probably put them in that order as "best", "fine", and "definitely acceptable". I thought @jagerber48 was asking to be able to update (first do sigma=1, then do sigma=2, have a printout show both), but that may not be correct. Like, "save earlier results" could be expected to be in user code, but the printed table is so nice ;). I guess we could document that if the user saves earlier results and then does an "update" of that dictionary, they can manage the "update vs overwrite" themselves. Because that saving of state was the previous behavior (but with the caching part sort of buggy), it seems fine to defer to that, but I think it is also OK to say that always overwriting is clearer and maybe "less surprising". Maybe @reneeotten or someone else has a "design preference"? |
@newville ah yeah maybe I wasn't clear with my example. With my first do sigma=1 then do sigma=2 I was just surprised that the printout was still showing only sigma=1 alone without any sigma=2. My expected behavior was to see the printout show only sigma=2. Though I can see why someone might want or expect to see both sigma=1 and sigma=2. Nonetheless that's not my preference since it's just more complex, hard to control, and in my opinion, outside of the scope of lmfit. It should be up to the user to handle those sorts of effort savings. I'm on board with the simple always overwrite solution. i.e.
As you say, the user can manage update vs overwrite themselves. |
@jagerber48 Ah, thanks! So, I think we all agree that "always overwrite If you would like to make a PR for that, I would be on board. Maybe we should wait until #797 is merged? |
Closed by #798 |
Description
ModelResult caches the result of conf_inveral(), but it does not check if the kwargs are identical.
The text was updated successfully, but these errors were encountered: