Re: [OctDev] complex error function

[Steven G. Johnson]

On 11/21/12 3:17 PM, Jordi Gutiérrez Hermoso wrote:
> On 21 November 2012 14:55, Steven G. Johnson<address@hidden>  wrote:
> > On 11/21/12 11:47 AM, Jordi Gutiérrez Hermoso wrote:
> > > But after you do the patch, how will we incorporate it back into our
> > > own codebase, if we have a copy of it?
> >
> >
> > "cp Faddeeva.cc octave/...../Faddeeva.cc" is pretty easy...
>
> What if you become unresponsive to accepting patches?

Then you are even more screwed if you link to it as a separate library 
shipped by me, because then you can't merge your changes at all.

> What if I
> already had patches there? Then I can't just overwrite the local copy,
> I'd have to do merges instead. And also, I or someone else in Octave
> has to be remembering to periodically do this copy and make sure that
> something has changed.

Instead, users periodically check my site to see if something has 
changed, and re-install the shared library if necessary.  Which do you 
think they will update more often, Octave or some obscure little library 
they've never heard of?

Moreover:

1) Code like this doesn't change very much over the long term.  It is 
not likely to get much in the way of new features (except for new 
language interfaces), and bugfixes should tend to accumulate very slowly 
over time (probably slower and slower over time as it "converges").

2) It is easy for me to send a message to the octave mailing list, or 
submit a bug report, if I have a bugfix.  I am already doing this for 
SciPy.   It is much harder to publicize the need for users to download 
an updated version of an obscure little library to users, distros, 
etcetera.  As long as I am maintaining the code upstream I will continue 
to do this; if I were to stop maintaining the code then you won't have 
any more patches to merge anyway.

3) Other than Octave and possibly SciPy, it is not clear who would use 
it in library form.  Most scientific programmers that I know are very 
unsophisticated about libraries and it is much easier for them to just 
make a copy of the C++ code and link to it directly rather than 
installing a shared library (which they only do by necessity for large 
packages).  And SciPy may well prefer to just include their own copy of 
my source, as they are doing now, so as not to introduce an external 
dependency; certainly no one on the SciPy lists mentioned any interest 
in me shipping a shared library.

> Please, don't trivialise this problem. I know software distribution is
> a chore and hard work, but it can't be avoided.

I'm not trivializing it, I'm simply suggesting that standalone libraries 
are not necessarily the best solution for distributing relatively small 
self-contained numerical subroutines like this.  The question is, what 
is the best software distribution mechanism for this problem, 
considering users as well as developers?

Look, it is easy for me to make an autoconfiscated tarball if that is 
what you really want.  It's not a significant chore (the Makefile.am and 
configure.ac files would only be a few lines long).  I just don't think 
anyone other than you would want this in shared-library form, so what 
you are asking for doesn't make a lot of sense to me.

> > 2) make it optional. In which case most users won't install it (at
> > least, not until it is included in distros by default, which may
> > take a long time even if Octave suggests it, and even then only for
> > GNU/Linux distro users),
>
> I know you're eager to get your super important library [....]

There is no need to be obnoxious.   I am simply saying that if you are 
going to include complex error functions as a "core" function, there is 
an argument to including them for everyone.

If you don't want your error functions to support complex arguments, 
that is up to you.  Users who want such functionality can continue to 
download the octave plugins from my site.

> > I know how to distribute libraries. You are already using a little
> > library of mine called FFTW.
>
> Great, why don't you make this part of FFTW, then? Seems easiest this
> way. A reasonable case could be made for saying why fft needs the
> Faddeeva function and relatives.

No, there is no reasonable case for this (pretending you are serious). 
FFTs have virtually nothing to do with error functions.  Furthermore, it 
would make it MUCH harder for people who just want an error function if 
they have to pull in the entire (large) FFTW framework to get it, rather 
than grabbing a separate self-contained file.

--SGJ