octave-1.0.11 Comments and Queries

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

octave-1.0.11 Comments and Queries

Ted.Harding
Hi,

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.

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?
--------------------------------------------------------------------------

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).
--------------------------------------------------------------------------

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?

--------------------------------------------------------------------------
Apart from (A) and (B), very happy with 2.0.11 -- usual brilliant job!

Thanks,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <[hidden email]>
Date: 05-Apr-98                                       Time: 23:36:20
--------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

octave-1.0.11 Comments and Queries

John W. Eaton-6
On  5-Apr-1998, (Ted Harding) <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

RE: octave-1.0.11 Comments and Queries

Ted.Harding
On 06-Apr-98 John W. Eaton wrote:
> On  5-Apr-1998, (Ted Harding) <[hidden email]> wrote:
>| B: It seems gammai(a,x) is the wrong way round
>|
>| Is this a bug or is it intentional?
>
> This is a bug.  Here's my fix:

Thanks! All is now well.

>| --------------------------------------------------------------------------
>|
>| 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.

And many thanks for the reference.

Best wishes,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <[hidden email]>
Date: 06-Apr-98                                       Time: 10:58:45
--------------------------------------------------------------------


Reply | Threaded
Open this post in threaded view
|

Re: octave-1.0.11 Comments and Queries

Jim Van Zandt
In reply to this post by John W. Eaton-6

John -

Thanks!  This must be why my calculations of the chi-square function
have been wrong with recent releases of Octave.  (I have downgraded to
2.0.5, until Dirk Eddelbuettel <[hidden email]>, the Debian
maintainer, can incorporate your patch.)

                         - Jim Van Zandt

> | 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.