Re: pending interval-3.0.0 release

[Oliver Heimlich]

On 21.08.2017 04:20, Olaf Till wrote:
> On Sun, Aug 20, 2017 at 09:27:38PM +0200, Oliver Heimlich wrote:
>> On the other hand, the itl.mat
>> file can also be edited easily, since it is just a data file, which can
>> be processed with Octave.
> 
> This would possibly solve the problem, but I'm not sure that a data
> file is really so easily edited.

It is a file with numeric data.  Editing it with Octave (for the use in
this particular Octave package) is easier that editing the original
file, since you have more options:  You can add data by concatenating
the vectors and structs.  You can convert it into other formats using
octave's output functions.  You can query it with indexing expressions,
which is not even possible with a text editor on the original source.

For the Octave user, the itl.mat is everything he will ever need.  I
only want to give him the .itl files to document the license details of
itl.mat (and to advertise that external software).  We could as well not
redistribute the .itl source files at all and document the copyright in
COPYING explicitly.


>> Instead of hosting it on OF we could as well bundle it in the interval
>> repository.
> 
> Yes, if you think you can do this...

It is just a matter of putting a particular version of the python
scripts into a folder src/ITF1788.  Then, the user will receive that
software together with the Octave packages' release.  I am hesitating to
do this, because (1) I find this not important for the Octave package
user (see above).  The external software is only important to produce
test data in a format different from itl.mat for use in an unrelated
interval library.  And (2), I want to keep that external software
separate from the interval package to advertise its use in other
interval libraries.  Having its source in the interval package's
repository could leave the impression that it is part of the interval
package and thus GPL'd and then some potential users would refrain from
using it, see for example

https://github.com/JuliaIntervals/ValidatedNumerics.jl/issues/65


>> Another possibility could be to publish it in some official
>> Python repository, so you can pull it from there instead of Github.
>> Would that end your worries?
> 
> Yes, this would also end this worry.

I'd prefer this compared to bundling the software.  However, I have
little Python experience and first have to find out about publication.
IIRC, the setup.py is important for that.  Last time I checked, there
were at least two competing methods to do this (it's Python!).

Please look at the COPYING file in the tarball.  Currently, it tells the
user that if he wanted to compile the test data for another interval
library (or recompile the test data), he can find the compiler at a
Github repository.  I find the case of recompilation rather unimportant
(see above).  Should we really insist on having that generator available
this way?  If we develop that idea further, does it mean that I also
have to include the maintainer Makefile in the release tarball?  Even if
you have that external dependency, it is not trivial to use it.  So, one
could consider the Makefile rules to be part of the “missing source”.


> Unfortunately, there is a similar one: the external crlibm.mat is
> distributed without sources.

This is a different matter.  The crlibm.mat has been converted manually
(by me).  If you edited the original files, from which I have derived
this work, there is no way to apply that change to the crlibm.mat.  So,
I don't consider the original files as source files (=preferred form of
makeing changes) anymore.  That's why they are not part of the release
tarball.

Oliver