[REVIEW]: Aerobus: a C++ template library for polynomials algebra over discrete integral domains

[editorialbot]

trafficstars

Submitting author: @JeWaVe (regis portalez) Repository: https://github.com/JeWaVe/aerobus Branch with paper.md (empty if default branch): joss Version: v0.2.0 Editor: @diehlpk Reviewers: @JPenuchot, @balos1 Archive: Pending

Status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/3c1ba7b1d77f0d84db637854a939daf6"><img src="https://joss.theoj.org/papers/3c1ba7b1d77f0d84db637854a939daf6/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/3c1ba7b1d77f0d84db637854a939daf6/status.svg)](https://joss.theoj.org/papers/3c1ba7b1d77f0d84db637854a939daf6)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@JPenuchot & @balos1, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review. First of all you need to run this command in a separate comment to create the checklist:

@editorialbot generate my checklist

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @diehlpk know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Checklists

📝 Checklist for @balos1

📝 Checklist for @JPenuchot

[editorialbot]

Hello humans, I'm @editorialbot, a robot that can help you with some common editorial tasks.

For a list of things I can do to help you, just type:

@editorialbot commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@editorialbot generate pdf

[editorialbot]

Software report:

github.com/AlDanial/cloc v 1.88  T=0.02 s (493.2 files/s, 138668.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C/C++ Header                     1            293             38           1198
C++                              1            112             39            890
XML                              3              0              0            208
Markdown                         3             48              0            206
TeX                              1              3              0             27
YAML                             1              1              4             18
make                             1              2              0              6
-------------------------------------------------------------------------------
SUM:                            11            459             81           2553
-------------------------------------------------------------------------------


gitinspector failed to run statistical information for the repository

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1007/978-3-319-06486-4_7 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

Wordcount for paper.md is 962

[editorialbot]

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

[balos1]

Review checklist for @balos1

Conflict of interest

• [x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• [x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• [x] Repository: Is the source code for this software available at the https://github.com/JeWaVe/aerobus?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Contribution and authorship: Has the submitting author (@JeWaVe) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• [ ] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [x] Functionality: Have the functional claims of the software been confirmed?
• [ ] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• [ ] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [ ] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [ ] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [ ] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [ ] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• [ ] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• [x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• [ ] A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
• [ ] State of the field: Do the authors describe how this software compares to other commonly-used packages?
• [ ] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• [ ] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[diehlpk]

Hi @JPenuchot, @balos1 how is your review going?

[JPenuchot]

Review checklist for @JPenuchot

Conflict of interest

• [x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• [x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• [x] Repository: Is the source code for this software available at the https://github.com/JeWaVe/aerobus?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Contribution and authorship: Has the submitting author (@JeWaVe) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• [ ] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

• [ ] Installation: Does installation proceed as outlined in the documentation?
• [ ] Functionality: Have the functional claims of the software been confirmed?
• [ ] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• [ ] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [ ] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [ ] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [ ] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [ ] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• [ ] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• [ ] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• [ ] A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
• [ ] State of the field: Do the authors describe how this software compares to other commonly-used packages?
• [ ] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• [ ] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[JPenuchot]

Hi @JPenuchot, @balos1 how is your review going?

Hi Patrick, I have a few comments already:

• there is no documentation,
• the code is not commented,
• there are no instructions for installation (although it is a single header, having it specified in a documentation would be a good start),
• performance claims aren't backed by any benchmark/measure (nb: there is an assembly output example which might be a strong indicator, but isn't a performance measurement per se),
• the first commit was on the 3rd of june, and the last commit of the JOSS branch was on the 13th, which amounts to a 10 day effort and therefore doesn't nearly satisfy the substantial scholarly effort requirement of 3 months,
• SLEEF, which seems to implement the same functionalities, isn't cited anywhere and makes the statement of need fall short of arguments as of now. However I do understand the interest of having an alternative based on a generic implementation, which could be enough to justify the need for such a library (future-proofing for next architectures, or support for architectures not supported by SLEEF like RISC-V, etc...). Therefore the statement of need could be revised to something acceptable.

So in general the effort seems relatively small, and the project definitely falls short of any proper documentation and comprehensive comments, as well as performance measurements -preferably against the libraries cited by the author- to back the performance claims.

Regards, Jules

[diehlpk]

• the first commit was on the 3rd of june, and the last commit of the JOSS branch was on the 13th, which amounts to a 10 day effort and therefore doesn't nearly satisfy the substantial scholarly effort requirement of 3 months,

@JeWaVe could you please elaborate on that?

[JeWaVe]

Hi.

1. I will add documentation and benchmarks, even if I absolutely don't trust benchmarks (I wrote so many).
2. this library is a updated version of a previous repo I have "euler", which provided the same basic functionalities. In this previous version, I didn't manage to go as far as the fraction field over any discrete ring, including polynomials. therefore, total effort on this library is much more than 10 days, even if I have no idea about the total time. 3 didn't know about sleef. I'll add it in references and comparative benchmarks.

Envoyé depuis Proton Mail mobile

-------- Message d'origine -------- Le 23 août 2022 à 17:23, Jules a écrit :

Hi @.(https://github.com/JPenuchot), @.(https://github.com/balos1) how is your review going?

Hi Patrick, I have a few comments already:

• there is no documentation,
• the code is not commented,
• there are no instructions for installation (although it is a single header, having it specified in a documentation would be a good start),
• performance claims aren't backed by any benchmark/measure (nb: there is an assembly output example which might be a strong indicator, but isn't a performance measurement per se),
• the first commit was on the 3rd of june, and the last commit of the JOSS branch was on the 13th, which amounts to a 10 day effort and therefore doesn't nearly satisfy the substantial scholarly effort requirement of 3 months,
• SLEEF, which seems to implement the same functionalities, isn't cited anywhere and makes the statement of need fall short of arguments as of now. However I do understand the interest of having an alternative based on a generic implementation, which could be enough to justify the need for such a library (future-proofing for next architectures, or support for architectures not supported by SLEEF like RISC-V, etc...). Therefore the statement of need could be revised to something acceptable.

So in general the effort seems relatively small, and the project definitely falls short of any proper documentation and comprehensive comments, as well as performance measurements -preferably against the libraries cited by the author- to back the performance claims.

Regards, Jules

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[balos1]

Hi @diehlpk ,

So far, I have the same comments as @JPenuchot with my biggest concern being the lack of documentation or code commenting. The main branch does have installation instructions in the README (the joss brach does not), but that it is it. My second biggest concern is that this is work does not represent a substantial scholarly effort. I think further justification will be needed other than what has been provided so far.

Thanks, Cody

[diehlpk]

Hi @JeWaVe,

could you please provide more details on the time you spent on developing the code?

What is the benefit of this code to the scientific community?

[JeWaVe]

Sure I will. I'm too busy with other projects right now but I will.

Envoyé depuis Proton Mail mobile

-------- Message d'origine -------- Le 2 sept. 2022 à 17:13, Patrick Diehl a écrit :

Hi @.***(https://github.com/JeWaVe),

could you please provide more details on the time you spent on developing the code?

What is the benefit of this code to the scientific community?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[diehlpk]

@JeWaVe just checking if you have time to repsond.

[diehlpk]

@JeWaVe just checking if you have time to respond.

[diehlpk]

@JeWaVe just checking if you have time to respond.

[danielskatz]

@diehlpk - As track chair, I suggest sending an email to @JeWaVe as well as saying here that we will reject this submission if we don't hear back by some date (3 weeks from now?)

[diehlpk]

@JeWaVe Could you please respond to the above question? If I do mot hear back by November 21th, we will need to reject your submission.

[danielskatz]

Having not heard back, I will now reject this submission

[danielskatz]

@editorialbot reject

[editorialbot]

Paper rejected.

[danielskatz]

Thanks to @JPenuchot and @balos1 for your work in getting this review started; I'm sorry we couldn't finish this process more successfully.