<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Dear all, Below you will find a chart with the number of IPOL papers published per year. The number of papers IPOL published is a strong limitation in order to get IPOL indexed in JCR which in opinion should be the main goal of the journal in order to be recognized as a mature and relevant journal in the field. Of course, the "80 character by line" or the "-Wall -Wextra -Werror" philosophy does not help to increase the number of papers. In my opinion we should focus in the algorithm design and that the code is well organized, understandable and it follows the algorithm description and any other restriction about the code should be removed from the journal website. I would be more than happy to listen any idea to increase the number of papers published in IPOL and I think that to strongly simplify the IPOL code guidelines goes in such direction. Regards Luis Alvarez <img src="cid:part1.6B3E926F.FCC1D141@ulpgc.es" alt=""> <div class="moz-cite-prefix">El 04/07/2017 a las 15:55, Pascal Monasse escribió: </div> <blockquote type="cite" cite="mid:46858668.L5XoMGOZ51@pascal-virtualbox"> <pre wrap="">Dear all, I agree that the manuals/guidelines/web pages need serious update, but I would not advise to remove all the restrictions unilaterally. I answer point by point in the following. </pre> <blockquote type="cite"> <pre wrap="">It's not true any more that we only accept C/C++ code, and there's no reason why the algorithms can't go further than 1 Gb of RAM usage, since we have a lot of memory in the servers. They should not use an exaggerated amount of memory, though. </pre> </blockquote> <pre wrap=""> OK for C/C++, we have been accepting other languages for a long time. Concerning the RAM usage, indeed the servers can support much more than 1Gb, but that is not the only criterion. We would like the code to be able to run on regular machines, not only big servers. We could discuss whether 1Gb is too low a target for current machines, but I think that setting such a target is a good thing. It could still not be a hard requirement, but just a recommendation, that is allowed to be overridden if the editor agrees. </pre> <blockquote type="cite"> <pre wrap="">- We accept not only C/C++ but also Python and MATLAB and we're open to other languages eventually. </pre> </blockquote> <pre wrap=""> Indeed, we need to update the docs. </pre> <blockquote type="cite"> <pre wrap="">- All those technical terms give the impression that we're going to reject anything which does not follow exactly the norm of the compile (C89, C99, C++98), which is not true. </pre> </blockquote> <pre wrap=""> Still, having standard conforming code for C and C++ seems important to me for portability. Naturally, as Python and Matlab have no such strict standards, this does not apply to them. </pre> <blockquote type="cite"> <pre wrap="">- We give a list of allowed libraries, but these technical details should be discussed with the editor, not put here as a strong requirement. The editor should tell the editor what is possible and what is not, instead of writing "only libtiff, libjpeg, libpng, libgsl, eigen, zlib, fftw, cblas and clapack external libraries". </pre> </blockquote> <pre wrap=""> Again, for portability, it is important to delimit the dependences that are allowed. It is said in the guidelines that other libraries must be included in the package, so I think it is not too restrictive. </pre> <blockquote type="cite"> <pre wrap="">- We say "need at most 1 GB memory and 30 s computation". Again, this is flexible. It seems that if your algorithm takes 45 seconds it's going to be rejected. And that's not true at all. It should be a discussion with the editor instead of a hard limit. </pre> </blockquote> <pre wrap=""> That could be up to discussion with the editor, but again the 30s computation should be a strongly recommended target. This may oblige the authors to restrict strongly the input loads of their demo, but if a demo takes more than 30s, people will not have the patience to try it. </pre> <blockquote type="cite"> <pre wrap="">- "read/write PNG, TIFF, PNM, EPS, SVG, VRML or PLY format." --> Same comment here. Actually, the system can perform many conversions if needed. </pre> </blockquote> <pre wrap=""> Yes it can, but do we want to multiply the formats? This should cover most needs, this list can be expanded based on authors' requirements in accordance with the editors, but sticking to widely used formats is normally a good thing. </pre> <blockquote type="cite"> <pre wrap="">We should remove lines such as: - C89, C99 or C++98 code tested with gcc -std=xxx -Wall -Wextra -Werror </pre> </blockquote> <pre wrap=""> Why? It is a good requirement for code quality, not overly difficult to comply with. </pre> <blockquote type="cite"> <pre wrap="">We should remove lines such as: - compilation with make or cmake, only standard options, make uses $(CC) or $(CXX) </pre> </blockquote> <pre wrap=""> Why multiply arbitrarily the build methods? At least for C and C++ code, we want to stick with the dominant build methods. </pre> <blockquote type="cite"> <pre wrap="">We should remove lines such as: - max 80 characters per line, max 1000 lines per file </pre> </blockquote> <pre wrap=""> Again, why? We do not want messy code, this is not too much to ask from authors. </pre> <blockquote type="cite"> <pre wrap="">We should remove lines such as: - This file archive can either be a single volume .ZIP compressed archive or a GZIP compressed tar archive2. The size of the compressed archive file should be less than 2 MB --> There's no reason to limit to 2 Mb! </pre> </blockquote> <pre wrap=""> OK for that one, after all it is just a question of what the server can support. </pre> <blockquote type="cite"> <pre wrap="">- A published software must not be distributed with binary precompiled files if these files can be obtained from source code --> Actually, it should NEVER contain precompiled files! </pre> </blockquote> <pre wrap=""> Agreed. </pre> <blockquote type="cite"> <pre wrap="">- Other techniques for accelerated computing, like OpenCL and OpenACC, are not supported by the journal --> We support it in the new system if we manage to have a server with a GPU. </pre> </blockquote> <pre wrap=""> I have no strong opinion on that. Of course, the server could support those. </pre> <blockquote type="cite"> <pre wrap="">Again, this is should be fixed, since it's blocking without any reason a lot of eventual submissions. </pre> </blockquote> <pre wrap=""> The omission of Matlab and python may indeed have that effect, I do no think that is the case for the other requirements. </pre> <blockquote type="cite"> <pre wrap="">"I only work with Windows (resp. Linux), I don't think Linux (resp. Windows) compatibility is important." --> This is irrelevant and confusing here. We ask for the minimal requirement that the code compiles and works in Debian Stable, but we won't make any comments if it works/don't work in any of the thousands of other systems out there. </pre> </blockquote> <pre wrap=""> Having C/C++ compliant code should answer that. Yes, we want Linux compatiblity (why just Debian Stable?). Even though Windows compatibility may not be required (the build can be much more complex on Windows because there is no standard location for dependences), it could still be a recommendation. Concerning my demos, I had several times people requesting help for installation on Windows machines, so I put now some effort into ensuring such integration is easy. Other authors may not care about that, but I am glad that people are using my code. Best, Pascal </pre> </blockquote> </body> </html>