octave-dev — GNU Octave developers' list

Re: [OctDev] Re: Nonlinear optimization tutorial

[Matthew W. R. <ma...@fr...>]

> Something tex based certainly seems to be in order since it makes the math
> easier to typeset.  I'm partial to latex myself.

I would be partial to LaTeX as well, but we might want to consider
texinfo for info support.  I haven't used texinfo much, though.

> I don't know what to make of lyx.  While ascii based, I'm guessing that lyx
> would not be very happy if you make modifications directly on the file with
> a plain text editor, so everyone would have to use lyx.

I'd rather not.

> Anyone have experience with MathML?  Is there common browser support?
> Latex2html can be really ugly.  Is MathML something you could edit directly
> (like html), or is it only really usuable with a sophisticated editor.

You be the judge:

Latex:  $\frac{dy}{dx} = \frac{1}{y^2}$

MathML:  (From mozilla homepage)
<math xmlns="&mathml;">
  <mrow>
    <mfrac>
      <mrow>
        <mi>d</mi>
        <mi>y</mi>
      </mrow>
      <mrow>
        <mi>d</mi>
        <mi>x</mi>
      </mrow>
    </mfrac>
    <mo>=</mo>
    <mfrac>
      <mn>1</mn>
      <msup>
        <mi>y</mi>
        <mn>2</mn>
      </msup>
    </mfrac>
  </mrow>
</math>

See also:
http://www.w3.org/Math/mathml-faq.html#syntax

Re: [OctDev] Re: Nonlinear optimization tutorial

[Paul K. <pki...@ja...>]

Thanks!

I would say stick with the name minimize.  If you also happen to give your
minimization some constraint options, then minimize can choose a constraint
algorithm.  If that is too awkward, then we can find a new name for the
constrained version, such as mincon.

Any opinions as to whether matlab's minimization function interface is
acceptable?  My preference is to not introduce new interfaces unless they
are clearly better.

We need to settle on a document format, or maybe a small number of
formats.  That way it will be easier to work together on documentation.
Standard layout of documentation in the directory would also be helpful so
that the build/install docs can work like install m-files.

Something tex based certainly seems to be in order since it makes the math
easier to typeset.  I'm partial to latex myself.

I don't know what to make of lyx.  While ascii based, I'm guessing that lyx
would not be very happy if you make modifications directly on the file with
a plain text editor, so everyone would have to use lyx.

Anyone have experience with MathML?  Is there common browser support?
Latex2html can be really ugly.  Is MathML something you could edit directly
(like html), or is it only really usuable with a sophisticated editor.

That Octave uses texinfo is a good argument for using texinfo ourselves.
What I've seen from octave function headers, though, tells me I won't like
it much.  I still am avoiding going through and fixing up all our function
headers to use texinfo format ;-)

Other suggestions?

- Paul

On Mon, Mar 18, 2002 at 08:58:01AM +0000, Etienne Grossmann wrote:
>   Hello,
> 
> this is just to send a slightly polished version of the previous
> tutorial. Amongst other things, I replaced the front-end's name by
> u_minimize(), so that it may be later possible to add other front ends
> such as 
> 
>   u_minimize      :     unconstrained minimization
>   c_minimize      :     constrained minimization
>   l_minimize      :     linear programming
>   leasqr          :     least squares
>   ... your favorite optimization problem here ...
> 
> If these front-ends take care to call similar options by the same
> name, it may be possible to then write a front-end for them all, why
> not?
> 
>   Any opinions, suggestions? Shall I upload u_minimize (perhaps w/
> another name) and the tutorial?
> 
>   Cheers,
> 
>   Etienne
> 
> -- 
> Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

[OctDev] Re: Nonlinear optimization tutorial

[Etienne G. <et...@is...>]

  Hello,

this is just to send a slightly polished version of the previous
tutorial. Amongst other things, I replaced the front-end's name by
u_minimize(), so that it may be later possible to add other front ends
such as 

  u_minimize      :     unconstrained minimization
  c_minimize      :     constrained minimization
  l_minimize      :     linear programming
  leasqr          :     least squares
  ... your favorite optimization problem here ...

If these front-ends take care to call similar options by the same
name, it may be possible to then write a front-end for them all, why
not?

  Any opinions, suggestions? Shall I upload u_minimize (perhaps w/
another name) and the tutorial?

  Cheers,

  Etienne

-- 
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

[OctDev] Specification for nonlinear optim. front-end

[Etienne G. <et...@an...>]

  Hello,

here is a possible specification for a front-end to unconstrained
nonlinear optimization functions. The current "optimize()" function
does more or less this already, but only has the Nelder-Mead,
conjugate gradient and Levenberg-Marquardt ("D2" below) algorithms.


Synopsis of a front-end for optimization
----------------------------------------

  [x_best,v_best,...] = minimize (func, start_point, ...)

  start_point is the starting point for the iterative minimization
              method.

              If func takes more than one argument, start_point may be
              a list. By default, func will be minimized with respect
              to the first argument, but any other argument may be
              specified with the "narg" option below.

Implemented methods and their applicability
-------------------------------------------

  +--------------------+---+-------+-------+------+
  |                    |   | Deriv |       |      |
  | METHOD             |Dim| Order | Domain| Func |
  +--------------------+---+-------+-------+------+
  | Newton-Ralphson    | 1 |   2   |  all  |  C2  |
  | Nelder-Mead        | N |   0   |  all  | cont |
  | BFGS               | N |   1   |  all  |  C1  |
  | Conjugate Gradient | N |   1   |  all  |  C1  |
  | DFP                | N |   1   |  all  |  C1  |
  | D2                 | N |   2   |  all  |  C2  |
  +--------------------+---+-------+-------+------+

Options indication 1st or second differential
---------------------------------------------

"dfunc" dfuncname
  => Use an algorithm that uses the differential.
     Assumes the differential df can be calculated with 
    
       df = dfuncname (x)

"d2func" dfuncname
  => Use an algorithm that uses the 1st and 2nd differentials.
     Assumes the function value f, differentials df and d2f can be
     calculated with  
    
       [f,d2,d2f] = d2funcname (x)

"ndif"
  => Use numerical differentiation.

Options indicating the algorithm
--------------------------------

newton_ralphson       (nr)
  => Dim == 1

nelder_mead           (nm)

bfgs
  => Need Dfunc

cong_grad             (cg)
  => Need Dfunc

dfp
  => Need Dfunc

levenberg_marquardt   (lm)
  => Need D2func

-- Default :
   If    Dfunc  is given : Method == bfgs, cg or dfp
   Elsif D2func is given
     If Dim == 1 : Method == nr
     Else        : Method == lm

Options controling termination
------------------------------

  Option    Description                   Applicable methods  
  -----------------------------------------------------------
  ftol h    Absolute function improvement (nm, dfp, bfgs, lm)
  vtol h    Volume   of simplex	          (nm)
  rtol h    Radius of simplex		  (nm)
  dtol h    Amplitude of derivative	  (dfp, bfgs, lm)
  xtol h    Amplitude of step		  (nm, dfp, bfgs, lm)

Other options
-------------
narg n               Indicate which argument with respect to which
                     func is optimized (when it takes multiple
                     arguments).

step h               Indicate the initial step size (not for method
                     that uses 2nd diff)

maxev n          Maximum number of function evaluations

verbose          Show status during algorithm run

shorthand        Do not perform the optimization, but return the name
                 of the backend function and the options that are
                 passed to it. The backend can then be called
                 directly, with little overhead.

Checks that should be done on the coherence of the input 
--------------------------------------------------------

If Dfunc  is needed, but not specified : do numerical differentiation

If D2func is needed, but not specified :

  If Dim == 1 : do numerical differentiation
  Else        : error (not yet implemented)

If Dim == 1 but size Xstart != 1 : error

If termination criterion is used w/ inappropriate method : error

If Dfunc or  D2func are specified but not required by method : warn

If both Dfunc and D2func are specified : warn



-- 
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

[OctDev] Nonlinear optimization tutorial

[Etienne G. <et...@is...>]

  Hello,

I attach a little (3 pages) tutorial which I just wrote on how to do
nonlinear optimization using octave. Feedback welcome.

  In it, I use a front-end function (optimize()) and one of the
back-ends is my conjugate-gradient function cg_min(). The front-end
allows me to make the tutorial very simple and I prefer cg_min() to
dfp() or bfgs() because it has the same interface as my other optim
functions.

  Uploading the tutorial would only make sense if I also upload the
minimize() and cg_min() functions. I will send in a few minutes a mail
with my opinion on how a front-end to optimization could be. It is
mostly the same as the actual optimize() function. This is just a
suggestion, and is open for changes.

  Cheers,

  Etienne

-- 
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

[OctDev] next release

[Paul K. <pki...@ja...>]

Hi all,

Thanks to the good folks at Debian we need to do another octave-forge
release to accomodate builds on a wide variety of architectures.  Let
the list know in the next day or two if there is anything that should go
into this release, and give an estimate of how long it will take you
to get it there.

Thanks,

Paul Kienzle
pki...@us...

[OctDev] [Fwd: Re: using source forge]

[Paul K. <pki...@us...>]

Backups of the cvs tarball are now being done.

	- Paul

-------- Original Message --------
Subject: Re: using source forge
Date: Wed, 14 Nov 2001 17:26:33 +0100
From: Francesco Potorti` <po...@gn...>
To: Paul Kienzle <pki...@us...>
References: <3BF...@us...><E16...@po...>
<3BF...@us...><E16...@po...> <3BF...@us...>

   > Ok, I'll do that on ftp://fly.cnuce.cnr.it/octave-cvs/

Done.  Every Sunday night, last seven kept.

[OctDev] Re: using source forge

[Francesco P. <po...@gn...>]

   BTW, is anyone mirroring the nightly CVS tarball that source forge 
   produces?
   
         http://cvs.sourceforge.net/cvstarballs/octave-cvsroot.tar.gz

I can do it, if requested.

[OctDev] using source forge

[Paul K. <pki...@us...>]

Hi all,

Given that we are light users of source forge services (really only 
CVS) I don't see a compelling reason to move elsewhere.  If (when?)
VA shuts down source forge because of buyout, bankruptcy or whatever
we will still have our tarball and we can use the help-octave list
to decide where to set it up.

BTW, is anyone mirroring the nightly CVS tarball that source forge 
produces?

      http://cvs.sourceforge.net/cvstarballs/octave-cvsroot.tar.gz

Paul Kienzle
pki...@us...

-------- Original Message --------
Subject: Re: Sparse Matrix
Resent-Date: Wed, 14 Nov 2001 02:27:52 -0600
Resent-From: hel...@be...
Date: Wed, 14 Nov 2001 09:27:50 +0100
From: Francesco Potorti` <po...@gn...>
To: hel...@be...
References: <3BF...@fr...>

For those who work on Octave: thanks to all.  I'd like to make you aware
that recently the FSF has issued a warning against Sourceforge, which
is getting more and more closed, and making ever more difficult to
escape from it.  An alternative exists, which is named savannah.gnu.org.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

Re: [OctDev] [markespl@yahoo.com: Re: Reading netcdf files]

[Rafael L. <ra...@ic...>]

* Paul Kienzle <pki...@us...> [2001-11-05 15:15]:

> One problem I see is the following:
> 
> --------------------------------------------------
> Copyright 1993-1999 University Corporation for Atmospheric Research/Unidata
> 
> [...]
> software or in any product that includes this software. The names UCAR
>                                                                                       ^^^^^^^^^^^^^^^^^
> and/or Unidata, however, may not be used in any advertising or publicity
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to endorse or promote any products or commercial entity unless specific
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> written permission is obtained from UCAR/Unidata. The user also
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [...]

It's mostly fairly standard "keep our copyrights on the stuff, and
don't mess with the name of our Institution."  They are not requiring
permission for distribution.

At any rate, the netCFD library is part of the main section of the Debian
distribution, hence its license has to be DFSG-compliant.  There are at
least five other packages in Debian that are linked against netCDF:
xmgr, gri, grace, gmt, and dx, all of them in main.

I am pretty sure we are safe here.

> The other issue is whether we would rather have the mexCDF interface on
> octave-forge.  It works, but I haven't yet heard from the author under
> which license he will release the script files he uses to run it (if any).
> The mex files are already appropriately licensed, but they are not callable
> in a user-friendly fashion.

This is a sensible issue.  If the package you mention works in a
satisfactory way, nobody will need Mark's and mine ncload/ncsave. I do not
have any special interested in getting those two files into OctaveForge, and
I let to your appreciation if they should or not be included.

-- 
Rafael

[OctDev] Re: forwarded message from Debian Installer

[Paul K. <pki...@us...>]

Dirk Eddelbuettel wrote:

> Subject: octave-forge_2001.11.02-1_i386.changes INSTALLED
> Date: Mon, 05 Nov 2001 15:04:34 -0500
> From: Debian Installer <ins...@ft...>
> To: Dirk Eddelbuettel <ed...@de...>
>
> Installing:
> octave-forge_2001.11.02-1.diff.gz
>   to pool/main/o/octave-forge/octave-forge_2001.11.02-1.diff.gz
> octave-forge_2001.11.02-1_i386.deb
>   to pool/main/o/octave-forge/octave-forge_2001.11.02-1_i386.deb
> octave-forge_2001.11.02.orig.tar.gz
>   to pool/main/o/octave-forge/octave-forge_2001.11.02.orig.tar.gz
> octave-forge_2001.11.02-1.dsc
>   to pool/main/o/octave-forge/octave-forge_2001.11.02-1.dsc
> Announcing to deb...@li...
> Closing bugs:
>
> Thank you for your contribution to Debian.
>
>   --------------------------------------------------------------------------------
> Octave-forge is now part of Debian. So let the bug reports roll...
>
> Dirk
>
> --
> Better to have an approximate answer to the right question
> than a precise answer to the wrong question. -- John Tukey

They are rolling just fine as it is ;-)

- Paul

Re: [OctDev] [markespl@yahoo.com: Re: Reading netcdf files]

[Paul K. <pki...@us...>]

One problem I see is the following:

--------------------------------------------------
Copyright 1993-1999 University Corporation for Atmospheric Research/Unidata

Portions of this software were developed by the Unidata Program at the
University Corporation for Atmospheric Research.

Access and use of this software shall impose the following obligations
and understandings on the user. The user is granted the right, without
any fee or cost, to use, copy, modify, alter, enhance and distribute
this software, and any derivative works thereof, and its supporting
documentation for any purpose whatsoever, provided that this entire
notice appears in all copies of the software, derivative works and
supporting documentation.  Further, UCAR requests that the user credit
UCAR/Unidata in any publications that result from the use of this
software or in any product that includes this software. The names UCAR
                                                                                      ^^^^^^^^^^^^^^^^^
and/or Unidata, however, may not be used in any advertising or publicity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to endorse or promote any products or commercial entity unless specific
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
written permission is obtained from UCAR/Unidata. The user also
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
understands that UCAR/Unidata is not obligated to provide the user with
any support, consulting, training or assistance of any kind with regard
to the use, operation and performance of this software nor to provide
the user with any updates, revisions, new versions or "bug fixes."
----------------------------------------------------

That is according to RMS a restriction which is not in the GPL and
so is not a GPL compatible license, and so we are not allowed to
redistribute netCDF linked to Octave, which means we have to put
it into nonfree/netCDF with NOINSTALL in the directory  :-(

The other issue is whether we would rather have the mexCDF
interface on octave-forge.  It works, but I haven't yet heard from
the author under which license he will release the script files he
uses to run it (if any).  The mex files are already appropriately
licensed, but they are not callable in a user-friendly fashion.

Paul Kienzle
pki...@us...

Rafael Laboissiere wrote:

> Hi,
>
> Some time ago, Mark Esplin posted in help-octave a DLD file for loading
> NetCDF files into Octave.  He sent to me a distributable version of his
> file, containing a copyright and a license statement.  Together with the
> ncsave.cc file that I posted two years ago in help-octave, this could be a
> interesting addition to OctaveForge.  They are attached below.
>
> I will commit our files to the CVS repository, if nobody objects.  I am
> accepting suggestions about the place to put it (I am too lazy to figure out
> by myself...)
>
> --
> Rafael Laboissiere
>
>   --------------------------------------------------------------------------------
>
> Subject: Re: Reading netcdf files
> Date: Sun, 25 Nov 2001 14:08:50 -0500
> From: Mark Esplin <mar...@ya...>
> Reply-To: mar...@sd...
> To: Rafael Laboissiere <ra...@ic...>
> References: <200...@be...> <200...@cr...> <200...@ga...>
>
>         Here is my new and improved extension for reading a netcdf file.  I changed
> the name to ncload.  You volunteered to pass it on to were it needs to go to
> be of use didn't you?
>
>                             -Mark Esplin
>
> On Friday 02 November 2001 05:16 pm, you wrote:
> > * Mark Esplin <mar...@ya...> [2001-11-02 15:54]:
> > > I want to fix ncrdvar.cc a bit so that I don't have to read an entire
> > > variable.  I might should also rename it to ncload to make it more
> > > consistent with the rest of octave and your extention.
> >
> > Yhat sounds reasonable.
> >
> > > To copyright it GPL is all I have to do is put in a copyright statement?
> >
> > See http://www.gnu.org/licenses/gpl-howto.html.
>
>   --------------------------------------------------------------------------------
>                 Name: ncload.cc
>    ncload.cc    Type: Plain Text (text/plain)
>             Encoding: base64
>
>   --------------------------------------------------------------------------------
>
>    ncsave.ccName: ncsave.cc
>             Type: text/x-c++src

[OctDev] [markespl@yahoo.com: Re: Reading netcdf files]

[Rafael L. <ra...@ic...>]

Hi,

Some time ago, Mark Esplin posted in help-octave a DLD file for loading
NetCDF files into Octave.  He sent to me a distributable version of his
file, containing a copyright and a license statement.  Together with the
ncsave.cc file that I posted two years ago in help-octave, this could be a
interesting addition to OctaveForge.  They are attached below.

I will commit our files to the CVS repository, if nobody objects.  I am
accepting suggestions about the place to put it (I am too lazy to figure out
by myself...)

-- 
Rafael Laboissiere

[OctDev] new octave-forge release

[Paul K. <pki...@us...>]

I've put together yet another release tarball for octave-forge.

Note the new ChangeLog file.  I found a wonderful program to
automatically generate it from the CVS archive, so be sure to put
useful log messages on the files when you commit.  I talk about it in
octave-forge/release.sh

Does anyone know how to automatically paste the log messages back into
the individual files themselves?  The GPL requires that each modified file
carry a prominent notice of who changed it  and when, though you don't
have to say what changes were made.

Assuming this release is good enough for Debian (and I don't need to
go to r1 v4), I will in future give more notice so that we can coordinate
releases.

Paul Kienzle
pki...@us...

Re: [OctDev] Re: matcompat for PC?

[<ad...@fr...>]

On Thu, 25 Oct 2001, Paul Kienzle wrote:
> If you  must have
> the functions in the oct file, then you will need to recompile octave with the
> source in the the src/DLD-FUNCTIONS subdirectory and listed on the DLD_XSRC line
> in src/Makefile.  I don't know what flags are used to build on the PC.  It may be
> that "./configure ; make " is all you need to do and it will figure out that it
> is a PC and that it should compile a static version of Octave, or it may be that you
> have to explicitly force it to be static.  Whatever the case, write it up on
> INSTALL.win so we can include it on the octave-forge site.  Thanks,

you need to edit a Makefile, and edit the oct files and put them
in the src/DLD-FUNCTIONS directory.

The build works fine with ./configure ; make

Here is an old email about it.

_______________________________________
Andy Adler,                ad...@nc...

>On Tue, 12 Jun 2001, John W. Eaton wrote:
>> I assume you are using 2.1.x.  As Dirk said, you can drop the
>> functions in with the sources, and that's about it.  If you put the
>> functions in the src/DLD-FUNCTIONS directory, then you would also
>> need to add the names of the .cc files to the DLD_XSRC list in
>> src/Makefile.in and then run
>>
>>   CONFIG_FILES=src/Makefile ./config.status
>>   make
>>
>> in the top-level build directory.
>>
>
>I've found (at least for the win32 build) that you need
>to edit the include files section as well. I posted my recipe
>in http://www.octave.org/mailing-lists/help-octave/2000/1639
>
>Change the includes in foobar.cc
>   replace #include <oct.h>
>   with    #ifdef HAVE_CONFIG_H
>           #include <config.h>
>           #endif
>           #include "defun-dld.h"
>           #include "error.h"
>           #include "gripes.h"
>           #include "oct-obj.h"
>           #include "utils.h"
>

[OctDev] Re: matcompat for PC?

[Paul K. <pki...@us...>]

Henrik,

I have never tried, but there are some people who have.  The .oct functions
won't
work because the people who build the PC version haven't figured out to make
oct files work on the PC, but the rest of the code should work fine.  If you
must have
the functions in the oct file, then you will need to recompile octave with the
source
in the the src/DLD-FUNCTIONS subdirectory and listed on the DLD_XSRC line
in src/Makefile.  I don't know what flags are used to build on the PC.  It may
be
that "./configure ; make " is all you need to do and it will figure out that it
is a PC
and that it should compile a static version of Octave, or it may be that you
have
to explicitly force it to be static.  Whatever the case, write it up on
INSTALL.win
so we can include it on the octave-forge site.  Thanks,

Paul Kienzle
pki...@us...

Henrik Olofsson wrote:

> Hi,I'm planning to install the matcompat on a PC.Is it possible?Do you have
> any help-file on how to do this? /henrik
> __________________________________
> Henrik Olofsson <he...@ol...>

Re: [OctDev] relation octave-forge <-> matcompat

[Paul K. <pki...@us...>]

matcompat is now part of octave-forge.

Paul Kienzle
pki...@us...

Hendrik Naumann wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> I just subscribed to this list, so this question may asked befor.
> Is matcompat a part of octave-forge ? Or is octave-forge a stand
> alone addon to octave?
>
> Thanks Hendrik
> - --
> PGP ID 21F0AC0265C92061
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE71vr5IfCsAmXJIGERAjroAJsG7CEWZfTmbLaDx71P1KHfp59ybACfUyhO
> 6fgDzz6wnCs4yoi5FQ0rA94=
> =wFs2
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

[OctDev] relation octave-forge <-> matcompat

[Hendrik N. <hn...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I just subscribed to this list, so this question may asked befor.
Is matcompat a part of octave-forge ? Or is octave-forge a stand 
alone addon to octave?

Thanks Hendrik 
- -- 
PGP ID 21F0AC0265C92061
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE71vr5IfCsAmXJIGERAjroAJsG7CEWZfTmbLaDx71P1KHfp59ybACfUyhO
6fgDzz6wnCs4yoi5FQ0rA94=
=wFs2
-----END PGP SIGNATURE-----

[OctDev] progress meter function

[Rafael L. <ra...@ic...>]

I am almost sure that somebody has already written such a thing, but I just
added comment to my own progress_meter.m function and thought it would be a
interesting addition to OctaveSF.

The file is attached below and I am reproducing the doc string here. Please,
feel free to send comments/patches.  If you do not object, I will add it to
the CVS repository.  I only need to know in which directory.

Enjoy.

## usage:   progress_meter (0, [label, [ncols]])
##          progress_meter (adv)
##
## This function shows a progress meter at stdout and is intended for
## giving visual feedback on the progress of long loop operations.
## A typical call would be like this:
##
##    progress_meter (0, "Computing ... ", 60);
##    N = 2000;
##    for j = 1:N
##      eig (randn (40)); # this is the core of the loop operation
##      progress_meter (j/N);
##    endfor
##
## and the following progress_meter will be shown:
##
##    Computing ... |==                           | - 10%  1m15s
##
## which changes over time, looking later like this:
##
##    Computing ... |============                 | / 42%    43s 
##
## progress_meter should always be called before the loop with the first
## argument equal to 0.  The third optional argument is the number of
## text columns spanned by the display (it defaults to the value of the
## COLUMNS environment variable).  The second optional argument is the
## label that will be shown at the left of the progress meter display.
##
## The other fields in the display are: a horizontal bar giving a
## pictorial indication of the advancement, a "flipping clock", a
## indication of percentage completed, and an estimated time of
## completion.
## 
## When calling progress_meter inside the loop, only one argument should
## be given, which is the amount of advancement.  Its is equal to 0 at
## the beginning and must reach 1 at the end of the loop.
##
## Implementation notes:  
##
## 1) A number of global variables are defined in order to keep the
##    internal state of the meter.  All Their names start with
##    "progress_meter_".  The user must avoid to mess with them in her
##    code. 
## 2) This implementation relies on Unix specificities, like the
##    getenv("COLUMNS") call and the use of "\r" in printf().  For now,
##    progress_meter has only be tested in Linux.
## 3) The estimated time of completion is noisy, since it is computed
##    from one iteration to another, with tic() and toc() calls.  

-- 
Rafael Laboissiere

Re: [OctDev] Packaging octaveSF

[Matthew W. R. <ma...@le...>]

> I have put together some control files for octaveSF so that the
> entire tree can be configured, compiled and built automatically.
> In the process, I have restructured the tree.

[...]

Good work.  I like the directory scheme.

In an earlier message on the directories you had suggested that each
package have a demo/ directory for demo scripts.  Are we still going
to do this?  I found one demo script not in a demo directory:

main/optim/leasqrdemo.m

There may be others.

Also, I have a bug fix for one of the files.  Should I send the file
to you (Paul), or just wait until the new CVS directory appears at
SourceForge.

Matt

[OctDev] Packaging octaveSF

[Paul K. <pki...@us...>]

I have put together some control files for octaveSF so that the entire
tree can be
configured, compiled and built automatically.  In the process, I have
restructured
the tree.  See:
    http://users.powernet.co.uk/kienzle/octaveSF-2001.09.21.tar.gz  (750
kB)
If there are no objections, I will ask the people at sourceforge to
replace the
current CVS tree with tree given in this tarball.

Dirk, you and Raphael will have to sort out the Debian packaging issues.

Particularly, nonfree/gpc has package control information in it
already.  Perhaps
anything that octave-SF.deb does not include could be packaged
separately?

Note that extra/tk_octave needs octave compiled with -lpthread, so you
will need to change how you build the octave package itself if you are
going
to package it.  AFAIK, it will not hurt octave in any way to compile it
with pthreads,
but I haven't run the test suite or tried any timing tests.

Anyone want to try their hand at writing a generic Octave package
installer?
instoct.sh.in is a start, but it would be nice if the path details were
also substituted
by ./configure so that the user could type:
     octpackage build <package-name>
            compile anything that needs compiling
     octpackage test  <package-name>
            run all the tests in the package
     octpackage install <package-name>
            build and test the package if you haven't already done so
            copy m-files, oct-files, data, bin, libs, manpages, etc. to
the users path
            update ~/.octavepackagerc with any initialization that needs
to be done
     octpackage installsite <package-name>
             like install, but install into the site paths rather than
the user paths.
     octpackage clean <package-name>
             remove any files that have been built
And in octave, type
     package <package-name>
             list the contents of the package, preferably categorized
with a description
             of each category and a one-line description of each
function.

The package documentation file could have a standard name like 00Index,
which
would be installed to something like <package-name>.index in the package

directory.  Then file_in_load_path will be able to fetch it for you.
Ideally, this
file would contain the category descriptions, with a tag such as
@category-name@
where the functions for that category are to be listed, and each
function file
would have something like the following:
          ##CAT: <list of categories this function belongs to>
          ##DESC: <one line description of the function>
If you are really ambitious, the "See also" lines in the function
documentation
could be generated automatically to contain other functions in the
category,
though this might not be enough.

[OctDev] New octave-cvsupdate mailing list

[Rafael L. <ra...@ic...>]

There is now a new mailing list for the octave@SF project, octave-cvsupdate,
to which the developers are encourage to subscribe. The log messages of all
cvs commits are automatically redirected to this list.  As usual, the list
is archived at geocrawler.  Although it is possible to send posts to
octave-cvsupdate, it is not really intended to be a discussion forum.  The
Reply-To field of messages sent to this list is set to
oct...@li.... 

Thanks to Paul for creating the list.

-- 
Rafael

Re: [OctDev] GPC bindings are in the CVS tree

[Paul K. <pki...@ki...>]

On Fri, Jul 20, 2001 at 11:25:53AM +0200, Rafael Laboissiere wrote:
> Thanks to Paul and Matthew, the Octave bindings for the GPC library have now
> a home.  I just added all the files to the CVS tree.  After discuting with
> Paul, I finally decided to put them in non-free/gpc.  I do not really care
> about the precise location of the files.  IMHO, the octave.sf project should
> concentrate on either making file releases or automating things  with a
> database, as Etienne told me privately.

My priority is to construct a package which Dirk can add to Debian.  Grabbing
things piecemeal is not appropriate for those of us with slow internet
connections.

Automating upload/download has merit.  Anyone know if sf projects can
host specialized cgi scripts?  I presume we would have a client process
which keeps a local copy of the SF tree, and accepts commands to update
the client tree, request new functions, request entire packages, post
new functions or post entire packages.  The server process would have
to keep track of dependencies.  Is there already code around to do this
sort of thing?

> 
> BTW, I am planing to do a file release of octave-gpc next week.  Although
> the package is usable now from CVS, I have yet to document the DLD functions
> and write a decent README.  I will do the first real release next week, I
> hope (otherwise it will be done in one month).
> 
> Another thing: in some of the other projects where I am involved at SF, we
> setup an automatic mail notification for cvs activity.  I find this very
> useful, and would suggest that we do the same for the octave project.  All
> we have to do is to create a new mailing list (octave-cvs, say), and modify
> things in the CVSROOT directory.  I volunteer myself to do the second part,
> but I have no privileges to create mailing lists.

That would be nice.  I'll create the octave-cvs mailing list.

> 
> -- 
> Rafael
> 
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> http://lists.sourceforge.net/lists/listinfo/octave-dev
> 

- Paul

[OctDev] GPC bindings are in the CVS tree

[Rafael L. <ra...@ic...>]

Thanks to Paul and Matthew, the Octave bindings for the GPC library have now
a home.  I just added all the files to the CVS tree.  After discuting with
Paul, I finally decided to put them in non-free/gpc.  I do not really care
about the precise location of the files.  IMHO, the octave.sf project should
concentrate on either making file releases or automating things  with a
database, as Etienne told me privately.

BTW, I am planing to do a file release of octave-gpc next week.  Although
the package is usable now from CVS, I have yet to document the DLD functions
and write a decent README.  I will do the first real release next week, I
hope (otherwise it will be done in one month).

Another thing: in some of the other projects where I am involved at SF, we
setup an automatic mail notification for cvs activity.  I find this very
useful, and would suggest that we do the same for the octave project.  All
we have to do is to create a new mailing list (octave-cvs, say), and modify
things in the CVSROOT directory.  I volunteer myself to do the second part,
but I have no privileges to create mailing lists.

-- 
Rafael

Re: [OctDev] Contributing the GPC bindings to octave.sf.net

[Rafael L. <ra...@ic...>]

* Paul Kienzle <pki...@ki...> [2001-07-17 21:26]:

> Put your files in the octave/non-free directory.

Although the GPC library can be classified as non-free, everything that I am
planning to put in the CVS tree is released under the GPL (it is my own
Octave DLD code).  I would prefer to put it elsewhere, like in
dld/geometry/gpc/, or whatever.  (I know, I know, that the CVS tree
organization is a quite sensible issue for you...)

What do you think?

--
Rafael