octave-1.0.11 Comments and Queries

[John W. Eaton]

On  5-Apr-1998, (Ted Harding) <address@hidden> wrote:

| I just pulled the octave-2.0.11 sources and compiled it (S.u.S.E.-5.1 Linux
| with gcc 2.7.2.1, libm.sa.5.0.9)
| --------------------------------------------------------------------------
| 
| A: Seems fine now but I had the following:
| 
| 1. Configure with
| 
|    ./configure --with-f2c --enable-shared --enable-dld --enable-lite-kernel  
| 
| and the compilation seemed to succeed, but when octave was run
| several functions were undefined: they seem to be some of the
| functions represented by .oct files in
| /usr/local/libexec/octave/2.0.11/oct/i586-pc-linux-gnulibc1.

Since you say that there are .oct files in this directory, I assume
that you ran make install.  What is your LOADPATH?  If you set it
yoursel, does it include a leading or trailing colon to ensure that
the default directories are prepended or appended to the path you set?
Are the file permissions set so that you can read the .oct files?

| 2. Configure with
| 
|    ./configure --with-f2c --enable-shared --enable-dld
| 
| and all was well. Is there a straightforward suggestion as to why
| this may have occurred?

The difference is that with --enable-lite-kernel, some of the
`built-in' functions are actually .oct files and are dynamically
loaded.  It sounds like there is some reason Octave can't find the
.oct files when you used --enable-lite-kernel.

| B: It seems gammai(a,x) is the wrong way round, in that it gives the
| result you would expect if x were the exponent and a were the
| integration limit. It turns out, looking at the m-file which calls
| gammainc as gammainc(x,a), and testing gammainc, that it is gammainc
| which is the wrong way round (i.e. gammainc(x,a) gives the result
| you would expect if x were the exponent and a the limit).
| 
| Is this a bug or is it intentional? (I've changed the gammai m-file
| which is easy, but it might be worth re-compiling the gammainc .oct
| file since that's where the trouble really is).

This is a bug.  Here's my fix:

*** liboctave/lo-specfun.cc~    Thu Feb 19 01:28:15 1998
--- liboctave/lo-specfun.cc     Mon Apr  6 00:27:28 1998
***************
*** 477,483 ****
  gammainc (double x, double a)
  {
    double retval;
!   F77_XFCN (xdgami, XDGAMI, (x, a, retval));
    return retval;
  }
  
--- 477,483 ----
  gammainc (double x, double a)
  {
    double retval;
!   F77_XFCN (xdgami, XDGAMI, (a, x, retval));
    return retval;
  }
  
*** libcruft/slatec-fn/xdgami.f~        Sun Nov 30 18:22:24 1997
--- libcruft/slatec-fn/xdgami.f Mon Apr  6 00:26:16 1998
***************
*** 1,5 ****
!       subroutine xdgami (x, a, result)
!       double precision x, a, result, dgami
!       result = dgami (x, a)
        return
        end
--- 1,5 ----
!       subroutine xdgami (a, x, result)
!       double precision a, x, result, dgami
!       result = dgami (a, x)
        return
        end

However, the order of the arguments in the gammai and gammainc
functions is correct.  gammainc is compatible with Matlab, gammai is
compatible with older versions of Octave.

| --------------------------------------------------------------------------
| 
| C: The example function "oregonator" is intriguing --
| nearly-periodic sudden bursts with long quiescent intervals! Is
| there some background to the invention of this function?

I thought there was a reference in the source file, but it looks like
it got wiped out somewhere along the way.  Here it is:

  Oscillations in chemical systems.  IV.  Limit cycle behavior in a
  model of a real chemical reaction. Richard J. Field and Richard
  M. Noyes, The Journal of Chemical Physics, Volume 60 Number 5,
  March 1974.

jwe