Octave 2.1.63 available for ftp

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

Octave 2.1.63 available for ftp

John W. Eaton-6
Octave 2.1.63 is now available for ftp from ftp.octave.org in the
directory /pub/octave/bleeding-edge:

  -rw-r--r--  1 1005 5508209 Nov 17 10:12 octave-2.1.63.tar.gz
  -rw-r--r--  1 1005 4339124 Nov 17 10:12 octave-2.1.63.tar.bz2
  -rw-r--r--  1 1005    1976 Nov 17 10:14 octave-2.1.62-2.1.63.patch.gz
  -rw-r--r--  1 1005    2124 Nov 17 10:14 octave-2.1.62-2.1.63.patch.bz2

  e358f561d31cbb784acd35c51cec80f3  octave-2.1.63.tar.gz
  3f6322b30edb79ee26659dbebefdfcfc  octave-2.1.63.tar.bz2
  ef37b6540f9f530b118f6b9262d21152  octave-2.1.62-2.1.63.patch.gz
  467f7880db1b959271b0760aec609bac  octave-2.1.62-2.1.63.patch.bz2

Thanks again to David Bateman for all his hard work to get this
snapshot ready.

This version includes many new features, including integer data types,
inline functions, function handles, concatenation of structs, cell
arrays and user-defined types, and better compatibility with the
leading brand.

As always, if your favorite bug is still not fixed, please report it.

There have only been a few bug fixes since 2.1.62 so 2.1.63 will be
labelled the "testing" (or recommended) version of Octave.

The snapshot is tagged in the usual way (ss-2-1-63) in the CVS
archive and I have also created a branch tag (ss-2-1-63-patches) so we
can check out that branch and apply any patches for a 2.1.64 snapshot
if that is needed.  I plan to start applying more interesting changes
to the main branch now, including removing gplot from the core parser,
and adding the new implementation of sparse matrices.  In addition to
these changes, I think we still have the following items for Octave
3.0:

  * allow [x{:}] = f (...) to work

  * private functions

  * some support for MPI

  * bring the manual up to date

I've done some work on the first item but did not finish my changes
(it was a bit messy).

Private functions should not be too difficult, but will require some
changes to the way the pathsearching code works.

I'm willing to drop the MPI item as I think this can be handled in an
external package.

It is not absolutely necessary to have the manual up to date for the
initial 3.0 release.

For later 3.x releases:

  * 64-bit addressing for >2GB arrays

  * support for >2GB files

  * single precision N-d arrays

  * package system for contributed code

  * Matlab-compatible objects

  * handle graphics

  * ?

Comments?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

Stéfan van der Walt
>   * Matlab-compatible objects

Does this include user definable classes?  Now that would be
useful.

>   * handle graphics

I'm all for this.  It's also something the gnuplot people should be
paying attention to.

Regards
Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

David Bateman-3
In reply to this post by John W. Eaton-6
> In addition to these changes, I think we still have the following
> items for Octave 3.0:
>
>  * allow [x{:}] = f (...) to work
>
>  * private functions
>
>  * some support for MPI
>
>  * bring the manual up to date

If we are discussing the wish-list for 3.0 again, I'd suggest that if
private functions are in the classes should also be added, since the
two are closely related. Classes are just private directories for a
certain data-type. Once such a private direcory for a data-type
existing adding the overload functions won't be too difficult.

Another thing you might need in that case is the dispatch code from
octave-forge, rewritten to fit into the class structure. In any case,
unless you intend to add the sparse code to all of the functions like
lu, inv, chol, qr, det, ranks, sum, reshape, atan2, diag, etc, etc,
etc, then a proper dispatch/class structure will be needed.

Another thing that I'd wish for, for version 3, would be that the
FIXES and patches directories of octave-forge are gone through and the
stuff there either updated and ported to the version 3.0 or definitely
dropped. These directories shouldn't exist in octave-forge.

It would also be nice if the "\" and "/" operators could recognize a
triangular matrix and call the appropriate lapack/blas code. The stuff in
octave-forge for this is a bit of a kludge as it only works for chol and
doesn't use the lapack code for "\" and "/". Maybe something like

   enum {diagonal = 0, upper, lower, full} matrix_type;
   matrix_type typ = diagonal;

   int i, r, c;
   for (i = 0; i < numel (); i++)
     if (elem (i) != 0.)
       {
         r = i % nr;
    c = i / nc;
         if (r != c)
           break;
       }

   if (i != numel ())
     if (r < c)
       {
         type = lower;
         for (int j = i + 1; j < numel (); j++)
           {
             int r2 = i2 % nr;
        int c2 = i2 / nc;
             if (r2 > c2)
               {
                 type = full;
                 break;
               }
           }
       }
     else
       {
         type = upper;
         for (int j = i + 1; j < numel (); j++)
           {
             int r2 = i2 % nr;
        int c2 = i2 / nc;
             if (r2 < c2)
              {
                type = full;
                break;
              }
          }
       }
   }

   if (type == lower || type == lower)
     {
       char typ = 'L';
       if (type = upper)
         type = 'U';

       retval = Matrix (b);
       double *result = retval.fortran_vec ();
       const double *a_data = a.fortran_vec ();
       double one = 1.0;
       char job = '1';
       F77_XFCN (dtrcon, DTRCON, (F77_CONST_CHAR_ARG2 (&job, 1),
                                  F77_CONST_CHAR_ARG2 (&typ, 1),
                                  F77_CONST_CHAR_ARG2 ("N", 1),
                                  nc, tmp_data, nr,
                                  rcond, pz, piz, info
                                  F77_CHAR_ARG_LEN (1)));
             
       if (f77_exception_encountered)
        (*current_liboctave_error_handler)
          ("unrecoverable error in dtrcon");
             
       if (info != 0)
         info = -2;

       volatile double rcond_plus_one = rcond + 1.0;

       if (rcond_plus_one == 1.0 || xisnan (rcond))
         {
           info = -2;

          if (sing_handler)
            sing_handler (rcond);
          else
            (*current_liboctave_error_handler)
              ("matrix singular to machine precision, rcond = %g",
               rcond);
         }
       else
         {
           F77_XFCN (dtrsm, DTRSM, (F77_CONST_CHAR_ARG2 ("L", 1),
                     F77_CONST_CHAR_ARG2 (&typ, 1),
                     F77_CONST_CHAR_ARG2 ("N", 1),
                     F77_CONST_CHAR_ARG2 ("N", 1), nr, b_nc,
                     one, a_data, nr, result, b.rows ()));

           if (f77_exception_encountered)
             (*current_liboctave_error_handler) ("unrecoverable error in dgetrf")
         }
     }
   else
     {
       // existing solve code

       ...
     }

this might be added to the Matrix::solve and ComplexMatrix::solve
functions. I don't think this would be very costly, as in most cases
you'd quickly identify full matrices. It would be interest to see how
this performs ralative to the chol function in octave-forge.

I also think version 3.0 should be the release where octave-forge is
decruftified; there is lots of stuff to support older releases, that
should be dropped at that point, though that has nothing to do with
octave per-se...

Cheers
David

--
David Bateman                                [hidden email]
Motorola CRM                                 +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

Daniel Sebald
In reply to this post by Stéfan van der Walt
Stefan van der Walt wrote:

>>  * Matlab-compatible objects
>>    
>>
>
>Does this include user definable classes?  Now that would be
>useful.
>
>  
>
>>  * handle graphics
>>    
>>
>
>I'm all for this.  It's also something the gnuplot people should be
>paying attention to.
>  
>

Having used handle graphics quite a bit, I never came to be much of an
advocate.  Following the parent-child-child-child tree seemed so
tedious.  First identify the handle, then look at those children and
identify what they are, e.g., and axis, a label, a datapoint.  Then
identify the properties of what you want to change... whew.  I suppose
like anything, once you get used to it, perhaps it's easier.

But the versatility of "graw()" is what I like.  In gnuplot, different
terminal types, useful options beyond what the Matlab graphics syntax
can provide.  If you are moving gnuplot to a localized, interchangable
graphics module, I'd wish for keeping the "graw()" command who's new
meaning would be to issue a command to the graphics engine.  Depending
upon what graphics engine is being run, the command could be shuffled
to, say, gnuplot or maybe just discarded.

Now the idea of making gnuplot more "object-like", that's a different
issue; one that's been discussed on the gnuplot list.  It would help for
working with plots once they appear on the screen.  For example, could
zoom all plots, not just the most recent.  Could maybe print a plot to a
different terminal (i.e., printer, file) without having to reissue all
the plot commands.  Not a top priority because of the many fixes and
improvements in gnuplot's operation, but it comes up from time to time.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

Ole Jacob Hagen-3
In reply to this post by Stéfan van der Walt
Handle graphics support is starting to be supported in two Visualisation
applications:

1. OctPlot
2. Oplot

Should h-g implementation be inside Octave, or should the visualisation
application, use this?
Both OctPlot and Oplot are using this strategy with success.

How should it be implemented?
There a lot of postings regarding implementation of handle graphics, and
where it should be.

Cheers,
Ole J.



Stefan van der Walt wrote:

>>  * Matlab-compatible objects
>>    
>>
>
>Does this include user definable classes?  Now that would be
>useful.
>
>  
>
>>  * handle graphics
>>    
>>
>
>I'm all for this.  It's also something the gnuplot people should be
>paying attention to.
>
>Regards
>Stefan
>
>
>  
>


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

John W. Eaton-6
In reply to this post by David Bateman-3
On 17-Nov-2004, David Bateman <[hidden email]> wrote:

| > In addition to these changes, I think we still have the following
| > items for Octave 3.0:
| >
| >  * allow [x{:}] = f (...) to work
| >
| >  * private functions
| >
| >  * some support for MPI
| >
| >  * bring the manual up to date
|
| If we are discussing the wish-list for 3.0 again, I'd suggest that if
| private functions are in the classes should also be added, since the
| two are closely related. Classes are just private directories for a
| certain data-type. Once such a private direcory for a data-type
| existing adding the overload functions won't be too difficult.

OK, but we have to draw the line somewhere...

| Another thing you might need in that case is the dispatch code from
| octave-forge, rewritten to fit into the class structure.

Yes, with classes, we will need some method of dispatch.

| In any case,
| unless you intend to add the sparse code to all of the functions like
| lu, inv, chol, qr, det, ranks, sum, reshape, atan2, diag, etc, etc,
| etc, then a proper dispatch/class structure will be needed.

Yes, I'd rather have a method for dispatch than have to modify all
these functions.

| Another thing that I'd wish for, for version 3, would be that the
| FIXES and patches directories of octave-forge are gone through and the
| stuff there either updated and ported to the version 3.0 or definitely
| dropped. These directories shouldn't exist in octave-forge.

I agree.  Having obsolete updates and patches in octave-forge can
cause trouble.

| It would also be nice if the "\" and "/" operators could recognize a
| triangular matrix and call the appropriate lapack/blas code. The stuff in
| octave-forge for this is a bit of a kludge as it only works for chol and
| doesn't use the lapack code for "\" and "/". Maybe something like
|
|    enum {diagonal = 0, upper, lower, full} matrix_type;
|    matrix_type typ = diagonal;

You could also add banded matrices.

Again, since these are just storage techniques (as is sparse), perhaps
they should be handled by different internal rep types in the Array
class?  At the very least, even if we don't have special methods of
storage for the different types, we should probably cache the
attribute once it is discovered.
|
| this might be added to the Matrix::solve and ComplexMatrix::solve
| functions. I don't think this would be very costly, as in most cases
| you'd quickly identify full matrices. It would be interest to see how
| this performs ralative to the chol function in octave-forge.

Is it only useful for a few solvers?  Would it be too much work (with
too many operators to define) to have new data types for each of these
special storage types?

| I also think version 3.0 should be the release where octave-forge is
| decruftified;

Yes, that would probably be a good thing.  I think it will eventually
be too much trouble to try to keep octave-forge compatible with very
obsolete versions of Octave.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

David Bateman-3
According to John W. Eaton <[hidden email]> (on 11/18/04):
> | If we are discussing the wish-list for 3.0 again, I'd suggest that if
> | private functions are in the classes should also be added, since the
> | two are closely related. Classes are just private directories for a
> | certain data-type. Once such a private direcory for a data-type
> | existing adding the overload functions won't be too difficult.
>
> OK, but we have to draw the line somewhere...

I only suggested classes as it would be relatively trivial after private
functions are added.

> You could also add banded matrices.
>
> Again, since these are just storage techniques (as is sparse), perhaps
> they should be handled by different internal rep types in the Array
> class?  At the very least, even if we don't have special methods of
> storage for the different types, we should probably cache the
> attribute once it is discovered.

Ahh, but I suggested using the DTR* blas/lapack functions not the DTP*
for packed triangular storage. The idea being that its the same storage
class as a matrix, but we can make use of the matrices special properties
to accelerate things.

However, if you add banded matrices to the mix, then yes that really
only makes sense if we add a banded storage class. It is also not clear
to me at what point the probing of an arbitrary matrix to determine its
type should be done. At its creation in the maybe_mutate function? At the
first use of the matrix in a function whose general version is much slower
(eg Matrix::solve, etc), or elsewhere?

> |
> | this might be added to the Matrix::solve and ComplexMatrix::solve
> | functions. I don't think this would be very costly, as in most cases
> | you'd quickly identify full matrices. It would be interest to see how
> | this performs ralative to the chol function in octave-forge.
>
> Is it only useful for a few solvers?  Would it be too much work (with
> too many operators to define) to have new data types for each of these
> special storage types?

Frankly I believe triangular matrices would profit enormously in the solvers,
and much less so elsewhere. This idea is pretty much what is currently done
in octave-forge. However adding banded matrices to the mix changes things.

Maybe we could consider that a banded matrix should be represented by a general
sparse matrix, which if done well should have similar properties to the
banded matrix, if only a slight memory overhead. In that case its upto the
user to identify a banded matrix at its creation. In that case have seperate
types for triangular matrices makes sense, and is easy to do. I'll suggest
a patch when I have time.

>
> | I also think version 3.0 should be the release where octave-forge is
> | decruftified;
>
> Yes, that would probably be a good thing.  I think it will eventually
> be too much trouble to try to keep octave-forge compatible with very
> obsolete versions of Octave.

Yes, the cruft is really beginning to accumulate in octave-forge...
Some of it is obvious as it is marked with a config option and is easy
to remove with sed. However, there is code like

  try ar = automatic_replot;
  catch ar = 0;
  end

  unwind_protect
    automatic_replot = 1;
    ...
  unwind_protect_cleanup
    automatic_replot = ar;
  end_unwind_protect

in quite a few m-files that is less obvious, that should also be cleaned
up for version 3.0.

Regards
David

--
David Bateman                                [hidden email]
Motorola CRM                                 +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


Reply | Threaded
Open this post in threaded view
|

octave and MPI

Michael Creel
In reply to this post by John W. Eaton-6
On Wednesday 17 November 2004 18:47, John W. Eaton wrote:
<snip>
> and adding the new implementation of sparse matrices.  In addition to
> these changes, I think we still have the following items for Octave
> 3.0:
>
>   * allow [x{:}] = f (...) to work
>
>   * private functions
>
>   * some support for MPI

<snip>

>
> I'm willing to drop the MPI item as I think this can be handled in an
> external package.
>

MPITB (http://atc.ugr.es/javier-bin/mpitb) works very well. I'm attaching a
pdf of a research paper that is almost done to provide evidence of this.
Please be sure to look at Figure 1. All of the code will be made public as
soon as the paper is done. I think it would be great if this MPI
functionality could make it into octave, and incorporating it would help to
keep compiling problems under control. Whenever octave's internal types
change, Javier has to do some under the hood work to get MPITB to compile
again.

OK, I'm holding my breath until Christmas!
Michael

mpitb.pdf (272K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

Paul Kienzle
In reply to this post by David Bateman-3

On Nov 18, 2004, at 4:03 AM, David Bateman wrote:

>>
>> | I also think version 3.0 should be the release where octave-forge is
>> | decruftified;

That suits me fine.

>> Yes, that would probably be a good thing.  I think it will eventually
>> be too much trouble to try to keep octave-forge compatible with very
>> obsolete versions of Octave.
>
> Yes, the cruft is really beginning to accumulate in octave-forge...
> Some of it is obvious as it is marked with a config option and is easy
> to remove with sed. However, there is code like
>
>   try ar = automatic_replot;
>   catch ar = 0;
>   end
>
>   unwind_protect
>     automatic_replot = 1;
>     ...
>   unwind_protect_cleanup
>     automatic_replot = ar;
>   end_unwind_protect
>
> in quite a few m-files that is less obvious, that should also be
> cleaned
> up for version 3.0.

A different way of handling whatever flags remain so that you
can harmlessly test and reset them even if they don't exist
would remove the initial if-block.  If in addition the flag
was automatically reset on returning from the function that
would remove the try-catch block. Assuming the special variable
control, the above code reduces to:

        control.automatic_replot = 1;
        ...

The implementation should do the correct thing with evalin.  A
more complicated issue is whether the flag should only apply
to the current function, or also to the functions that it calls.

Note that I haven't looked at what flags will remain after
decrufting.  There may be few enough that these extraordinary
efforts are not called for.

- Paul


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.63 available for ftp

Paul Kienzle
In reply to this post by John W. Eaton-6

On Nov 17, 2004, at 1:47 PM, John W. Eaton wrote:

> For later 3.x releases:
> ...
> Comments?

The current situation with automatic_replot and gnuplot
is difficult.  The only solution I can see is for Octave
to hold off plotting the graph for a while until it knows
whether or not titles, etc. are forthcoming.

For 3.0, you may want to force a clear plot command
each time a new plot is started so that titles, etc.
are cleared, unless hold is on of course.

Handling plotting properly in octave-forge will be crufty
without some changes before 3.0.  Currently it isn't
handled properly.

- Paul