These are chat archives for bluescarni/pagmo_reborn
double backticksvs no special markup for types), so I went back and modified the existing docs. I don't care which style we use, as long as we adopt one and we stick to it consistently, and I'd like not to have to spend time policing this if possible :)
this is okish maybe for the
pagmo_throw(std::logic_error,"the user-defined problem does not support seed setting: " "either it does not provide the 'set_seed()' method or its 'has_set_seed()' method " "returns false\n\nThe expected prototypes for 'set_seed()' are:\n" "C++: 'void set_seed(unsigned int)'\n" "Python: 'set_seed(seed)'");
set_seed()function, but it does not really inform for instance on what the argument types should be, nor what the functions should return. This is a problem for functions like the gradient for instance. We could add this info to the message of course, but then we have the same information in 3 different places in the docs, and if we ever need to change it it's gonna be madness. This is all information that IMO should be in the web documentation. Are we expecting one to be able to start writing problems "blindly" from the command line without ever opening up the PyGMO docs? I think we need to have a consistent behaviour and intent about this, otherwise we will have a hodgepodge of documentation. It's clear that we have conflicting ideas about the style and scope of the docs, so I think we need to find a common ground before making a mess.
sort_population_con()does not mention it could throw anything thrown by the first overload. And so on. Again, I started noticing this after starting to write the Python docs and asking myself what and how could throw for documenting it on the Python side. About this, I am open to the idea of eliminating the throws specifications at all, because honestly over the years I have used them they have not been of great practical value. Better to erase them altogether than having them half-assed :)
@notecommand sometimes used with a
:sometimes not, phrases sometimes terminating with a
.sometimes not, etc.
rosenbrock. I assumed it was "the" one convention. Did not notice that you used two different conventions in the same file ...
m_name = value;or
return m_name;). This type of docs make the appearance of the doc page more compact as it avoids the use of space for the obvious shortening the wall of text. But I am fine if you want to add them.