Operations Research Editing and Proofreading Services
The new algorithm solves the instances in a third of the time. The instances were generated by the authors, with parameters they chose, at sizes where their method has an advantage — and the competing method was run with its default settings on a machine of a different generation. Every number in the table is honest and the comparison is uninformative.
We edit what operations researchers write — algorithm and heuristic papers, computational experiment sections, modelling and formulation work, applied optimisation studies and case reports, simulation studies, stochastic and robust optimisation papers, industry and consultancy reports, and theses, articles and proposals. Our editors work on the computational study and how its instances were made.
The computational experiment is what an operations research paper's claim rests on, and its failure is a set of instances designed, however unconsciously, to suit the method. Where the test problems came from determines what the result means. We work through these so instance generation is described completely enough to reproduce — the generator, its parameters, the random seeds, the sizes and the structural features varied — since a reader cannot otherwise tell whether the instances span the interesting range; so benchmark instances from the literature are included alongside any generated ones, because self-generated instances are the weakest evidence a paper can offer and the standard sets exist for this reason; so the comparison is made fair and said to be — the same hardware, the same time limit, the same termination criteria, and competing methods tuned rather than left at defaults; so instances where the method performs badly are reported, given that the boundary of a method's usefulness is a result; so the measure is stated with what it hides, as average runtime over solved instances silently excludes the failures; so solution quality is reported against a bound or an optimum where one is available; and so the implementation, the solver and the version are named. Papers written this way get their methods adopted.
Everything you send is treated in confidence, including unpublished algorithms, industrial data and client reports. We are editors rather than operations researchers, and we offer no view on formulations, algorithms or computational results. What we can do is make the experiment's design visible.
Key Operations Research vocabulary
- Instances suited to the method
- Where the test problems came from
- Instance generator described
- Generator parameters stated
- Random seeds recorded
- Instance sizes and their range
- Structural features varied
- Density, tightness and correlation
- Benchmark instances from the literature
- Standard test sets included
- Self-generated instances as weak evidence
- Same hardware for all methods
- Machine specification reported
- Time limit applied equally
- Termination criteria matched
- Competing method tuned not defaulted
- Default parameters as a handicap
- Instances where the method fails
- Boundary of usefulness reported
- Average over solved instances
- Failures excluded from the mean
- Number solved within the limit
- Performance profile
- Solution quality against a bound
- Optimality gap
- Best known solution
- Lower bound quality
- Implementation language and solver
- Solver version and licence
- Warm start and its effect
- Reproducibility artefact
- Statistical comparison across instances
Operations Research Word Challenge
Even seasoned pros miss these — give it a shot.