Skip to content

Submission to the Journal of Open Source Software (JOSS)

We are ready to begin the work for the submission of Minterpy to the Journal of Open Source Software. @hernan68 has already started the work in the dev-joss_paper branch.

Tentative outline

@hernan68 and I had a discussion about this and here is a tentative outline:

  • Summary (note that a JOSS paper does not include an abstract)
  • Statement of need
    • (global) polynomial interpolation as an alternative to spline interpolation
    • lifting the curse of dimensionality
    • qualitative comparison with / alternative to neural networks
      • Minterpy produces an approximation of the underlying function in the Weierstrass sense
      • polynomials are more precise and faster to evaluate (e.g., Jannik's work on the Horner's scheme)
      • polynomials may be easier and more amenable to post-process
  • Basic usage

    • the interpolation interface with an example (we start with a specific and concrete task)

    • the polynomial bases (then we generalize to the underlying polynomial implementations and what can we do with them)

      • multi-index set and grid

      • polynomial bases

      • transformation between bases

      • connection to interpolation (DDS and barycentric transformation)

      • The table below should summarize the available polynomial bases in relation with common tasks, why we have them, and why we support transformation between them. The table indicates whether a particular bases is well-suited for a particular task, e.g., how straightforward, how accurate, how stable.

        Task \ Poly. Bases Canonical Newton Lagrange
        evaluation
        differentiation
        integration
        interpolation
        representation (?)

    • regression and other sources of polynomials (we have introduced interpolation on a grid, what if we have to deal with scattered data? In the end, though, we'll end up once again with minterpy polynomials)

  • Benchmark
    • Interpolation of the Runge function in four dimension and comparison with popular routines (we've seen similar results before, but we need a more up-to-date results so we need redo this thing)
      • SciPy in Python
      • ChebFun in MATLAB
      • ApproxFun in Julia
  • Applications (as prescribed by the checklist of content, we need to mention a representative set of past or ongoing research projects using Minterpy)
  • Acknowledgment (the usual stuff)

About JOSS and its requirements

As a reminder, I copied and pasted the requirements for the submission below and how we currently fare.

The list of submission requirements:

  • The software must be open source as per the OSI definition (Yes, it's the MIT license)
  • The software must be hosted at a location where users can open issues and propose code changes without manual approval of (or payment for) accounts. (Yes, via GitHub)
  • The software must have an obvious research application. (Yes, some application-based papers have already been published)
  • You must be a major contributor to the software you are submitting, and have a GitHub account to participate in the review process. (Yes, all the maintainers themselves are submitting the paper)
  • Your paper must not focus on new research results accomplished with the software. (remember this when writing the paper; it's more about the software and less about the results)
  • Your paper (paper.md and BibTeX files, plus any figures) must be hosted in a Git-based repository together with your software (although they may be in a short-lived branch which is never merged with the default). (Yes, the paper is in a branch in the GitLab repository, perhaps later to be merged; however, it must later be public for the review process.)

In addition, the software associated with your submission must:

  • Be stored in a repository that can be cloned without registration. (Yes, no restriction at GitHub)
  • Be stored in a repository that is browsable online without registration. (Yes, it's GitHub)
  • Have an issue tracker that is readable without registration. (Yes, via GitHub)
  • Permit individuals to create issues/file tickets against your repository. (Yes, via GitHub)

JOSS mentions something about the submitted software being of "substantial scholarly effort" on the part of the author. Indeed this is the case: Minterpy has enabled tackling some research challenges as demonstrated by several application-based publications. Moreover, JOSS also provides a guideline for editors and reviewers to assess whether a software project was a fruit of substantial labor:

  • Age of software (is this a well-established software project) / length of commit history.
  • Number of commits.
  • Number of authors.
  • Total lines of code (LOC). Submissions under 1000 LOC will usually be flagged, those under 300 LOC will be desk rejected.
  • Whether the software has already been cited in academic papers.
  • Whether the software is sufficiently useful that it is likely to be cited by your peer group.

From the end-product point of view:

  • the software should be feature-complete (i.e., no half-baked solutions)
  • the software is packaged appropriately according to common community standards for the programming language being used (e.g., Python, R)
  • the software is designed for maintainable extension (not one-off modifications of existing tools)

I think we check most if not all those criteria.

Finally, regarding the structure of the paper itself...

As a general guideline, the paper should:

  • include some sentences that explain the software functionality and domain of use to a non-specialist reader (i.e., the Summary section).
  • include some explanation on the research application of the software (we'll have an Application section).
  • be between 250-1000 words (many JOSS papers are a one-page summary; we plan to write more but most probably we shouldn't exceed five pages)

Checklist of content:

  • A list of the authors of the software and their affiliations, using the correct format.
  • A summary describing the high-level functionality and purpose of the software for a diverse, non-specialist audience.
  • A Statement of need section that clearly illustrates the research purpose of the software and places it in the context of related work.
  • A list of key references, including to other software addressing related needs. Note that the references should include full names of venues, e.g., journals and conferences, not abbreviations only understood in the context of a specific discipline.
  • Mention (if applicable) a representative set of past or ongoing research projects using the software and recent scholarly publications enabled by it.
  • Acknowledgement of any financial support.

All in all, a JOSS paper is neither a full-length paper nor a software documentation.

Edited by Uwe Hernandez Acosta

A HIFIS Service | Privacy | Imprint | Support | Documentation | Changelog