[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OctDev] complex error function
From: |
Steven G. Johnson |
Subject: |
Re: [OctDev] complex error function |
Date: |
Wed, 21 Nov 2012 17:47:52 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 |
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
- Re: [OctDev] complex error function, (continued)
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Daniel J Sebald, 2012/11/21
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Michael D. Godfrey, 2012/11/22
- Re: [OctDev] complex error function, James Cloos, 2012/11/28
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/29
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Jordi Gutiérrez Hermoso, 2012/11/21
- Re: [OctDev] complex error function,
Steven G. Johnson <=
- Re: [OctDev] complex error function, Jordi Gutiérrez Hermoso, 2012/11/21
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Daniel J Sebald, 2012/11/21
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Daniel J Sebald, 2012/11/21
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/21
- Re: [OctDev] complex error function, Daniel J Sebald, 2012/11/21
- Re: [OctDev] complex error function, Jordi Gutiérrez Hermoso, 2012/11/22
- Re: [OctDev] complex error function, Steven G. Johnson, 2012/11/22