Re: pending interval-3.0.0 release

[Oliver Heimlich]

On 21.08.2017 23:11, Julien Bect wrote:
> Le 21/08/2017 à 17:57, Oliver Heimlich a écrit :
>> On 21.08.2017 17:32, Olaf Till wrote:
>>> This means that we can't come to an agreement over this.
>>>
>>> But since this is a controversy between two administrators, a solution
>>> could be that you publish the package despite my disapproving.

> IANAL: If you, as the main developer of the package, consider this
> "itl.mat" file as the preferred form for making (future) modifications
> to it, then I think that you are allowed to consider it as "source",
> even if it was (originally) produced form some other data and/or code. 

In a nutshell, I have obtained data (from various sources) with LGPL and
Apache 2.0 licenses.  The original form has been either a proprietary
raw data format (see [1] or [2]), or data that is interleaved in unit
test code (see [3]).

In either case, I have spent nights to extract the data (vectors of
floating point numbers).  This mainly involved a lot of copy-pasting and
search-replacing and read-parsing.  It is not something that I have
automated or would find useful to automate.  It has been a one-off
manual work that needed to be done to get the data into accessible form.

Since the data stayed the same during that process, but eventually got
stored in a different format, I consider my work product a derivative
work of the original files.  It's like migrating a program from one
language into another language without using a compiler.

In one case I have saved my work product in the crlibm.mat file.  In
other cases I have used an intermediate format to save my work product
(domain specific language, see [4] for an example) and use exotic python
scripts to eventually produce the itl.mat file for use in the interval
package.

To sum up, in either case there is no way to automate conversion from
the very original source into the .mat files currently.  Also, I don't
find it worthwhile to implement one.  The work to make the data
accessible has already been done.

I don't see a reason to include any original sources for the derivated
test data in the tarball of the interval package.  Also, I don't have to
provide any of the tools or methods that I have used for conversion.

 * The original authors have been attributed in the package manual [5].
 * In the package's COPYGING file [6] the copyright details of
   the .mat files are explained (since the .mat files don't contain
   copyright meta data on their own).

Currently, the release tarball also contains the intermediate format
(.itl files) and rough instructions plus a reference to the python code
on Github.  This is meant for the case that anybody would find the
intermediate format equally useful and would want to use the .itl files
for something else (i. e. not for this package).

In 2015, I have decided to put the intermediate .itl format into the
tarball [7], because back then the tests have been a bulk of generated
.tst code (which clearly is not the preferred form to edit anything for
anybody).  Back then, it would have made sense to also include the
python scripts.  Now, with interval 3.0.0, there is no more generated
.tst code, only a itl.mat file with data and the generated external
tests have been replaced with proper BISTs.  My point is, that the user
doesn't need the .itl files anymore (and thus not the python scripts).

This leads me to the conclusion that I would eventually want to remove
the .itl files from this project entirely and probably publish them
together with the python scripts somewhere else.  However, this can
still be done after this release.  I don't see this as a blocking issue.
 To put it in a positive way: the situation has already been improved
compared to the previous release.

I hope that this explanation suffices for now.  I will publish the
release and we can maybe come to an agreement later and fix any open
issues in the next version.  I would have waited and discussed this
longer, but the release contains the results of a GSoC project (this is
GSoC's final week) and I don't want to see them getting delayed further.

Oliver



[1]
https://sourceforge.net/p/octave/interval/ci/default/tree/src/crlibm/tests/acos.testdata
[2] https://scm.gforge.inria.fr/anonscm/svn/mpfi/trunk/mpfi/tests/acos.dat
[3]
https://github.com/nehmeier/libieeep1788/blob/1f10b896ff532e95818856614ab3073189e81199/test/p1788/infsup/test_integration_mpfr_bin_ieee754_flavor_elem.cpp#L401
[4]
https://sourceforge.net/p/octave/interval/ci/default/tree/src/test/mpfi.itl
[5] https://octave.sourceforge.io/interval/package_doc/Acknowledgments.html
[6]
https://sourceforge.net/p/octave/interval/ci/default/tree/doc/COPYING.texinfo
[7]
http://lists.gnu.org/archive/html/octave-maintainers/2015-03/msg00174.html