Re: special functions reorganization in Octave

[Rik]

On 06/10/2017 07:32 AM, address@hidden wrote:

Subject:

Re: betainc and other special functions in Octave

From:

Michele <address@hidden>

Date:

06/10/2017 03:39 AM

To:

address@hidden

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

7bit

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden> <address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=utf-8; format=flowed

Message:

4

On 06/10/2017 10:47 AM, Michael D Godfrey wrote:

On 06/10/2017 02:42 AM, Rik wrote:

Is there a special functions Summer of Code project this year?  I thought I
saw some e-mails on the list about that.

I'd like to point out bug #51157 (https://savannah.gnu.org/bugs/?51157)
where the betainc calculations are inaccurate for some values. I did some
tracing and it comes down to the Fortran routines from Slatec that are
used.  They were last updated in 1992, and apparently are not accurate out
to the 15th or 16th digit of precision.

As a quick test, I wrote a C program that uses the GNU Scientific Library
to calculate betainc and it does get the more precise answer. The GSL
might be a way to quickly get access to other high quality special function
code.

Just a thought,
Rik

It would be good to include bug #44310 with this.

Michael

Dear all,

I'm the guy working on the Special Functions project for GSoC. Thank you Rik for the hint! betainc was already in my to do list due to bug #34405 and I saw this new bug in the tracker. Maybe I will change my timeline since my idea was to dedicate a week to betainc, but this new problem make me think I will need more time.
Regarding bug #44310, I think I can try to use the last part of the GSoC to work on it, but I have to discuss it with my mentors.

Michele

Michele,

There is a big ongoing re-organization of the Octave code base to base it squarely on C++11.  This will be excellent for future maintainability and accuracy, but will create hiccups in the meantime as the code base is undergoing a lot of change.  In particular, make sure you issue Mercurial pulls frequently from the main repository.  In the last two days I have delegated basic special functions, like erf or gamma, to the C++ std library.  I also alphabetized the header and C++ files for lo-specfun because they were so complicated and alphabetical order seemed to be the lowest common organizing principle.

I don't want to step on your toes, so I'll give you a heads up that I intend to remove the Fortran code in liboctave/external/slatec-fn that we no longer use.  In my opinion, it would be nice to shift away from Fortran when possible to C/C++ which matches the core language of the rest of Octave.  Perhaps jwe can weigh in here if he has a different opinion.  I think this principle should guide your thinking about how to tackle repairing or replacing special functions.  In other words, if you find yourself coding elaborate input validation or workarounds for the existing code, for example the Bessel functions from amos, then do consider some alternate source like gnulib, GNU Scientific Library, etc. which are based on C rather than Fortran.  And if you must write new code for an algorithm, do it in the m-file language or C++, rather than anything else.

Cheers,
Rik