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
MAINT documentation #228
MAINT documentation #228
Conversation
…c/restructure_examples
Codecov Report
@@ Coverage Diff @@
## development #228 +/- ##
==============================================
+ Coverage 85.28% 85.9% +0.61%
==============================================
Files 42 42
Lines 2270 2369 +99
==============================================
+ Hits 1936 2035 +99
Misses 334 334
Continue to review full report at Codecov.
|
A great addition would be an API documentation, something similar to sklearn's documentation. I'm not sure if this is on your stack and/or whether this is the right time to start this. |
@mfeurer I think API documentation would be great and work hand in hand with further improving the docstrings. Sphinx provides automatic generation of documentation from docstrings. However, the current theme does display the generated rst-files nicely. The widely used read-the-docs theme displays the generated API-files rather nicely. I post a screenshot for comparison. |
Yep that's look fine as well + it's actually developed by something like a company if I understand correctly. What's important to me is that there is a global menu on the page, which isn't there in the default layout. |
You can now check out the API that is generated from SMAC as it is right now. Global menu on the left with collapsible per-page-menus. |
I didn't check the text (PING again once that is ready for review), but I like the layout. I wonder though if it makes sense to divide the longer Sections into shorter ones (i.e. manual and quickstart guide). |
@shukon any updates on this PR? Is it ready for a review iteration? |
Soon! I'm on it. Fixed API-generation to get rid of the errors, trying to get toc right and rewrite a couple paragraphs. |
@mlindauer @mfeurer I think this PR is ready for review.
|
Hi, Open issues/todos are:
|
Another issue I found today is that the API is not build anymore. |
Actually, the first example (using CLI interface to optimize branin) might be intimidating for someone coming from the blackbox optimization literature and is used to an interface like this (see getting started section). |
@mfeurer Added f_min to branin-example (prior the cmd-line explanation). This feels like the interface you talked about. However, I left the cmd-line in, so you have a direct comparison in the same example. What do you think? |
Much better, thanks a lot. In general, it is a good idea to have a very minimal example, such as this one. Maybe it would be great to simplify the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through the manual and a part of the API documentation. However, I stopped the second because a lot of the docstrings are not rendered yet.
:lineno-match: | ||
|
||
This way, you can optimize a blackbox-function with minimal effort. However, to | ||
use the whole of *SMACs* capability, a scenario_ object should be used. There are a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're explaining the CLI, so there's no scenario
-object here. Maybe it would be a great idea to contrast the three different interfaces of SMAC? But that would be something for a new PR. We should get this one merged ASAP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll keep that in mind.
doc/basic_usage.rst
Outdated
The usage of *SMAC* from your Python-code is described in the `SVM-example | ||
<quickstart.html#svm-example>`_. | ||
Scenario and PCS are both build within the code. The target algorithm needs to | ||
be registered with a `Target Algorithm Evaluator (TAE) <tae.html#tae>`_, which communicates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, the default is to simply pass a function.
doc/options.rst
Outdated
The following assumes that the scenario is created via a scenario-file. If it is | ||
generated within custom code, you might not need *algo* or *paramfile*. | ||
|
||
Required: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to dynamically create this list of arguments from the scenario file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
doc/options.rst
Outdated
* *tuner-timeout* is the maximum amount of CPU-time used for optimization. Default: inf. | ||
* *wallclock_limit* is the maximum amount of wallclock-time used for optimization. Default: inf. | ||
* *runcount_limit* is the maximum number of algorithm-calls during optimization. Default: inf. | ||
* *minR* is the minimum number of calls per configuration. Default: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please reword this description? minimum number of calls
and maximum number of calls
is not very descriptive if a user doesn't know about the intensify procedure.
doc/options.rst
Outdated
# Forbiddens: | ||
{parameter_name_1=value_1, ..., parameter_name_N=value_N} | ||
|
||
.. note:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure? Can't it read both the old and the new format? Or do you mean that it is more restrictive than the implementation of the new PCS format in SMAC2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what I mean ;). I'll cut the note out.
smac\.epm\.random\_epm module | ||
============================= | ||
|
||
.. automodule:: smac.epm.random_epm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mlindauer @KEggensperger as a general question, do we want the documentation to show all methods which are inherited from the base class? I think this would be a great addition to the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't mind as long as the documentation stays concise
smac\.epm\.rf\_with\_instances module | ||
===================================== | ||
|
||
.. automodule:: smac.epm.rf_with_instances |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sfalkner the docstring for rf_with_instances
mentions the parameter max_num_nodes
. I'm currently wondering if the tree is build in depth-first or breadth-first fashion as this would change the behaviour?
smac\.epm\.rfr\_imputator module | ||
================================ | ||
|
||
.. automodule:: smac.epm.rfr_imputator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KEggensperger could you please add the return values to the docstring of the impute()
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just pushed a commit to this branch adding some more documentation to the BaseImputor class. See 0d9c36e
@@ -0,0 +1,7 @@ | |||
smac\.facade\.smac\_facade module | |||
================================= | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shukon could you please update the return value of get_trajectory
in the docstring? This function actually returns a named tuple now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
smac\.intensification\.intensification module | ||
============================================= | ||
|
||
.. automodule:: smac.intensification.intensification |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why for most classes the constructor isn't shown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is intended. It is toggled via this option. Would you prefer it to be shown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to see all methods of a class. @KEggensperger @mlindauer what's your opinion on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All methods. What would be a good argument to hide the constructor?
@shukon also, is there a reason why you reference pages by their file names and don't reference the page by its name? |
…te on help-content)
@mfeurer Because the links where not working the way I wanted before - do the work for you? Especially with the "#"-link. Anymore requested fixes I missed? |
@mlindauer @shukon @KEggensperger I think we should merge this now as this PR does what it's supposed to do: restructure the docs so that the structure is the way we want it to be. Polishing the API documentation is in my opinion better suited in a new PR to not make this PR too big and make it block the development of SMAC. What do you guys think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't looked into the current version, but if you think that we can merge it now, I'm happy to approve it.
Rewriting documentation in general.
This is not to be merged right away, but I would greatly appreciate an opinion on the work so far to see whether it is going in the right direction. Also to know things you are missing in the documentation in general would help.
To read, with sphinx installed: