-
Notifications
You must be signed in to change notification settings - Fork 34
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
Types #43
Types #43
Conversation
Codecov Report
@@ Coverage Diff @@
## master #43 +/- ##
=========================================
+ Coverage 47.52% 48.63% +1.1%
=========================================
Files 7 8 +1
Lines 566 584 +18
=========================================
+ Hits 269 284 +15
- Misses 297 300 +3
Continue to review full report at Codecov.
|
This looks good to me. Seems like it is quite straightforward to introduce types :) I think that, while we're at it - we could evaluate whether the |
Ok - will try to finish this over the course if the next few days |
This should in principle complete the PR. Some more notes: I've called the basic line search At this point it would be good to decide whether the
vs
Either way, the next step - maybe still within this PR - might be to deprecate all of the line search functions |
I agree; basic could just as well be backtracking to some people
why would the second be preferred?
yes, this needs to be done, and I think the "privatization" is a good idea. Let me get back to you on the "custom" warning unless someone gets to it before me (I need to go) |
regarding the custom dep, you can do something like const has_deprecated_xyz = Ref(false)
function xyz(args)
if !has_deprecated_xyz![]
warn("xyz is deprecated, please ... descriptive message here ...")
has_deprecated_xyz![] = true
end
... code here ...
return ...
end |
ok so pretty much hand-code it, that will be fine. |
The second seems the more natural construction in the dispatch context, but it really doesn't have to be. I am perfectly happy with making linesearch types callable. In particular the first type requires far no changes throughout |
why |
see the PR #411 in Optim for the corresponding changes in Optim. |
(ls::LineSearch)(args...) vs linesearch(ls, args...)
The dispatch approach would align with Optim's |
Ready to merge?
I'm curious as well |
hm - when I was writing it, it started to make sense, I'll need to look at the code again. |
I remember now - this is actually the only way to do it - at least as I've implemented the deprecation in the end. If you are more comfortable with macros than I am then you could probably rewrite these deprecations much more elegantly though. P.S.: if you read the code it ought to be clear, but let me know if I need to clarify anything |
I see. No I'm not a big macro genius - just hadn't seen Ref before. Is this ready to merge? |
from my end, yes it is ready |
hmm, can't really remember the technical details for using |
The function approach would be fine by me. It's currently called |
Great, thanks! |
I think we should actually define the function (whatever name we choose) in |
Does it also become important then to define an abstract supertype |
I suggest to not merge this yet. This is just a proof-of-concept for
backtracking!
only. Please have a quick look - if you are happy then I'll try to do the same for the remaining line searches.Notes:
backtracking!
adding amaxstep
parameter; this requires thatalpha * vecnorm(s, inf) <= maxstep
. (the choice of norm is a little restrictive, but I'll do another PR later when this is done to generalise to arbitrary step-length constraints).Please, somebody double-check that I've deprecated
bt2!
andbt3!
correctly.