add .bib file(s) ?

[d-monnet]

Would it be relevant to add .bib file(s) with the problems' reference, and link it in the problems' .jl ? This would make it easy to export a latex table with the name and citation of the problems.

[tmigot]

Thanks @d-monnet for the suggestion, I actually like the idea. We could add the DOI in each problem Meta and you can always use https://www.doi2bib.org for the rest :). What do you think?

[d-monnet]

That would work, but is doi2bib 100% reliable ? I know google scholar, for example, is not great for generating correct .bib files.

What I have in mind is to export a .tex file with the benchmark examples in a table, like

|name| ... 
arglina~\cite{ref} & ....
...

with ref in a .bib file exported/given along.

If we don't want to add the .bib to the package, I suggest we also create a web scraper that get the refs from this website and exports a .bib.

[tmigot]

I don't know if it is 100% reliable, but I have been using it very regularly and it seems pretty good nothing like the google scholar bib export. Maybe @abelsiqueira or @dpo have some feedback too on this?

I prefer anyway to add the DOI instead of the bib directly because it is more manageable for us.

[dpo]

This is a great idea and a corollary of a larger project I’ve been thinking about for years: properly documenting the source of each problem. Many come from the same source (e.g., the HS book or Buckley’s report), but many come from scattered sources. It would be great have a complete source description for each problem while we don’t have thousands of them.

Many problems will have a source of the form “problem 62 in Buckley’s report”, so the DOI alone isn’t sufficient. Maybe the problem source could be a struct with a DOI + other optional fields?!

[abelsiqueira]

doi2bib is not 100% reliable AFAICT (depends on the source of the DOI), but I have also had a pretty good experience with it. It does feel like it could be a larger project to list all source. It could actually be independent from this package, and link to implementations of the problems in multiple languages. It could potentially attract contributors from multiple languages. That being said, it is very niche, so I would start just adding the DOIs somewhere in the list here with the problem number or a string descriptor.

[tmigot]

As a first step in that direction, I would suggest to add two fields in the DataFrame that describe all the problems:

• a first field contains the DOI of the "primary" source ; so we can do what @d-monnet ;
• a second field could contain a larger string with a general description of the origin (original source, test problems, etc.).

[tmigot]

Ok, so a quick update about this.

• The DOI source might not be as simple as I thought because many of the sources reporting new problems are not published and may not have a DOI. In this, case we probably just leave the DOI field empty and count on the reference field to give us info.
• What do you think of something like this for the arggauss_meta (but then, it is aggregated in the giant DataFrame):

  
  argauss_meta = Dict(
  :nvar => 3,
  :variable_nvar => false,
  :ncon => 15,
  :variable_ncon => false,
  :minimize => true,
  :name => "argauss",
  :has_equalities_only => true,
  :has_inequalities_only => false,
  :has_bounds => false,
  :has_fixed_variables => false,
  :objtype => :other,
  :contype => :general,
  :best_known_lower_bound => -Inf,
  :best_known_upper_bound => Inf,
  :is_feasible => missing,
  :defined_everywhere => missing,
  :origin => :unknown,
  :doi => "10.1145/355934.355936", # https://www.doi2bib.org/bib/10.1145/355934.355936
  :reference => "

• Problem 9 in J.J. More', B.S. Garbow and K.E. Hillstrom, \"Testing Unconstrained Optimization Software\", ACM Transactions on Mathematical Software, vol. 7(1), pp. 17-41, 1981;
• Buckley#28;
• CUTEst: ARGAUSS.", )