octave-dev — GNU Octave developers' list

Re: [OctDev] new release?

[David B. <Dav...@mo...>]

The stuff in the directory main/fixed/examples doesn't build on OS X,
but as I don't have this OS I can't debug it. It was Per Persson who
pointed this out, and suggested he might find time to fix it, but as
he hasn't yet, I just added a test to disable building of this code
if the canonical_host_type includes the string "darwin".

The only other possible thing in my code was a bug report by Tom
G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate
his problem, and I can make no sense of why this problem occurs for
him, except to think he might have a problem with the install of his
compiler. So at this point I can propose no fix. If you really want to
be on the save side, I can disable the building of the parts of the
code that caused his problem as it only occurs in the classes for
fixed point NDArrays. As I haven't integrated this with the rest of
the code yet, they could only be used from within an oct-file in any
case. during the lead-up to a release I expect more people will do
builds of octave-forge and we'll see if other people have the same
problems as Tom G. Smith and if so we can then think about disabling
the build..

Cheers
David

Dapr=E8s Paul Kienzle <pki...@us...> (le 15/06/2004):
> I would like make a new octave-forge release.  Please let me
> know when you all are ready.
>=20
> - Paul
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN=
D
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph)=20
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)=20
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:=20

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

[OctDev] new release?

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

I would like make a new octave-forge release.  Please let me
know when you all are ready.

- Paul

[OctDev] =?iso-8859-2?Q?arpack_+_octave_=3D_problem?=

[<ctk...@o2...>]

Hello,

I am trying to implement function eigs(), as Matlab does it, using an Arp=
ack library. Unfortunately I’ve stacked at the beginning and can't =
move any step forward.

Problem is as follows...
Simple program using arpack written in C  works OK. But almost the same c=
ode used as a function in oct-file produces wrong results. For example ap=
rack function asked for starting vector always returns [NaN NaN NaN ....]
Of course, the same problem arise in C++ instead if C.

I think of some memory problem. It looks like aprack functions are referr=
ing to wrong place in memory when called from octave function. However, s=
ome of them do it all right. I've debug Arpack some how, and notice that =
i.e. this starting vector looks all right till it is normalized. =20

I wonder if:
1)anybody has faced similar problem?
2)anybody is interested in helping me? If so, I'll put some more details.

Regards,
Czarek Tkaczyk

Re: [OctDev] Octave-forge Development

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

Please update the text of the new developer guide as you feel is
appropriate.  It is in admin/template.ndev and is rebuilt using
admin/get_contents.

Post your patches to oct...@li...  and somebody
with write privileges will update the CVS tree.  Regular
contributors can get write privileges by asking.

Paul Kienzle
pki...@us...

On Jun 11, 2004, at 11:14 AM, Mark P. Esplin wrote:

> I am trying to figure out how octave-forge development works.  For the 
> main
> part of octave, John Eaton set's the direction, adds patches etc., but 
> how
> about for octave-forge?  When I look at the "Octave-forge developer's 
> guide"
> at http://octave.sourceforge.net/ it has instructions for adding 
> modules to
> octave-forge. Does each module's author maintain the module?  I 
> probably
> don't have the ability or the time to add major modules to 
> octave-forge, but
> I can do some bug-fixes, documentation, etc.  How would I go about 
> doing
> that? Just having a few comments on what works and what doesn't seems 
> like it
> would be helpful.  Should this go on http://wiki.octave.org/?   Maybe 
> we
> could avoid some of the frustration expressed recently by Tom in his 
> post to
> he...@oc....
>
>> From: "Tom G. Smith (Smitty)" <sm...@kc...>
>> To: he...@oc...
>
>> I've gotten octave-forge to compile and install on octave 2.1.57,
>> but I'm not at all sure I have anything more than compiled garbage.
>> I had to make numerous source code changes, some of which were
>> correcting simple typographical errors, so I know this code has never
>> been successfully compiled and tested.
>
> Some things in octave-forge work very well. It is a shame for the 
> whole system
> to be judged by the parts that don't work.
>
>                        -Mark
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] Octave-forge Development

[Teemu I. <tpi...@pc...>]

On 11/06/04 11:14, Mark P. Esplin wrote:
> I am trying to figure out how octave-forge development works.  For the main 
> part of octave, John Eaton set's the direction, adds patches etc., but how 
> about for octave-forge?  When I look at the "Octave-forge developer's guide" 
> at http://octave.sourceforge.net/ it has instructions for adding modules to 
> octave-forge. Does each module's author maintain the module?  I probably 
> don't have the ability or the time to add major modules to octave-forge, but 
> I can do some bug-fixes, documentation, etc.  How would I go about doing 
> that? 

Octave-forge development is not very coordinated. Usually each author
maintains his/her own modules, but others are free to fix bugs, especially
when they're related to the build system or brokennes caused by the core
Octave changes. I think CVS commit access is given to anyone who wants it,
you just have to ask. The other option is to mail patches to the maintainer
of the module in question.

> > From: "Tom G. Smith (Smitty)" <sm...@kc...>
> > To: he...@oc...
> 
> > I've gotten octave-forge to compile and install on octave 2.1.57,
> > but I'm not at all sure I have anything more than compiled garbage.
> > I had to make numerous source code changes, some of which were
> > correcting simple typographical errors, so I know this code has never
> > been successfully compiled and tested.
> 
> Some things in octave-forge work very well. It is a shame for the whole system 
> to be judged by the parts that don't work.

Octave and octave-forge are not very coordinated with each other either. The
core Octave is that much of a moving target, that the versions usually need
to be in sync. The version requirements can usually be found on the release
notes. I've just today compiled CVS checkout of octave-forge on a
CVS version of Octave and the sequence 
./autogen.sh; ./configure; make; make install; 
worked with no problems what so ever.

On the other hand, if one wants some get some work done instead of compiling
the bleeding edge stuff from CVS, I recommend the excellent Debian packages
of Octave and octave-forge.

Teemu

Re: [OctDev] Octave-forge Development

[Quentin S. <qsp...@ie...>]

Mark P. Esplin wrote:

>I am trying to figure out how octave-forge development works.  For the main 
>part of octave, John Eaton set's the direction, adds patches etc., but how 
>about for octave-forge?  When I look at the "Octave-forge developer's guide" 
>at http://octave.sourceforge.net/ it has instructions for adding modules to 
>octave-forge. Does each module's author maintain the module?  I probably 
>don't have the ability or the time to add major modules to octave-forge, but 
>I can do some bug-fixes, documentation, etc.  How would I go about doing 
>that? Just having a few comments on what works and what doesn't seems like it 
>would be helpful.  Should this go on http://wiki.octave.org/?   Maybe we 
>could avoid some of the frustration expressed recently by Tom in his post to 
>he...@oc....
>  
>
This and another recent post by Dirk to the octave list about splitting 
octave-forge because of dependencies has got me thinking. Octave-forge 
has become quite large and includes some very stable as well as some 
bleeding-edge code. I seem to recall that John has expressed a desire to 
avoid adding too much extra stuff to the core octave distribution, while 
at the same time some of the octave-forge functions have become a 
necessity for many people (including myself). Many of them roughly 
approximate the MATLAB "toolboxes", and some of them comprise easy 
solutions to questions that seem to come up on help-octave at least 
weekly (how do I save a figure, etc...), so the evidence would suggest 
that it's not advertized well enough. I'm not sure about the solution to 
that problem, but I would like to suggest we split octave-forge into 
some smaller packages. Here's a suggestion:

"octave-extras" or "octave-toolboxes": a well-tested core of 
octave-forge with minimal external dependencies

"octave-geom" and "octave-symbolic": separate packages that depend on 
external packages (like GiNaC and qhull)

"octave-forge": bleeding edge stuff

I welcome any thoughts on this.

-Quentin

[OctDev] Octave-forge Development

[Mark P. E. <ma...@sr...>]

I am trying to figure out how octave-forge development works.  For the main 
part of octave, John Eaton set's the direction, adds patches etc., but how 
about for octave-forge?  When I look at the "Octave-forge developer's guide" 
at http://octave.sourceforge.net/ it has instructions for adding modules to 
octave-forge. Does each module's author maintain the module?  I probably 
don't have the ability or the time to add major modules to octave-forge, but 
I can do some bug-fixes, documentation, etc.  How would I go about doing 
that? Just having a few comments on what works and what doesn't seems like it 
would be helpful.  Should this go on http://wiki.octave.org/?   Maybe we 
could avoid some of the frustration expressed recently by Tom in his post to 
he...@oc....

> From: "Tom G. Smith (Smitty)" <sm...@kc...>
> To: he...@oc...

> I've gotten octave-forge to compile and install on octave 2.1.57,
> but I'm not at all sure I have anything more than compiled garbage.
> I had to make numerous source code changes, some of which were
> correcting simple typographical errors, so I know this code has never
> been successfully compiled and tested.

Some things in octave-forge work very well. It is a shame for the whole system 
to be judged by the parts that don't work.

                       -Mark

Re: [OctDev] Space bug

[Laurent M. <lau...@mo...>]

On Tue, 8 Jun 2004 07:59:07 -0400
Paul Kienzle <pki...@us...> wrote:

> Yes, I see.  I'm annoyed that these are still there since I thought I 
> fixed
> them all long ago.  Please fix the rest.
> 

I correct those functions

extra/tk_octave/tk_scale.m
main/general/cplxpair.m
main/signal/dct.m

main/vrml/select_3D_points.m
main/vrml/vrml_browse.m
main/vrml/vrml_cyl.m
main/vrml/vrml_demo_tutorial_2.m
main/vrml/vrml_demo_tutorial_4.m
main/vrml/vrml_points.m
main/vrml/vrml_select_points.m

Some lines like: 
[ 1;
  foo (2);
 3];
aren't detectable by my script. So some functions night still be impacted.

Regards

     Laurent
-- 
Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de MOTOROLA
Tel: +33 (0)1 69 35 48 30 =-=-=-=-=-=-=-=-=-=-= Email: ma...@cr...

[OctDev] Space bug

[John W. E. <jw...@be...>]

On  8-Jun-2004, Laurent Mazet <lau...@mo...> wrote:

| I found a concatenation trouble in hankel.m (Octave-forge). Since [f (x), 2]
| means[f, x, 2] but not [f(x), 2], the hankel function failed on line 88.
| 
| It seems that this problem will appear in many other function. See the output
| of: find -name \*.m | xargs grep'\[[^]]*(.*).*\]'
| 
| Do you want I check most of the file ?
| 
|    Laurent
| 
| PS: Some functions from the native octave distribution are also affected

Which ones?  Please report these problems.

Thanks,

jwe

[OctDev] Space bug

[Laurent M. <lau...@mo...>]

Hi,

I found a concatenation trouble in hankel.m (Octave-forge). Since [f (x), 2]
means[f, x, 2] but not [f(x), 2], the hankel function failed on line 88.

It seems that this problem will appear in many other function. See the output
of: find -name \*.m | xargs grep'\[[^]]*(.*).*\]'

Do you want I check most of the file ?

   Laurent

PS: Some functions from the native octave distribution are also affected
-- 
Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de MOTOROLA
Tel: +33 (0)1 69 35 48 30 =-=-=-=-=-=-=-=-=-=-= Email: ma...@cr...

[OctDev] Regular Expressions

[Stefan v. d. W. <st...@su...>]

Hi Paul

Is there a way to make the regexps less greedy?

For example, the regexp

A.*A

on a string like

AbbbbbbbbAbbbbbbbbbbbbbbA

will match the whole string.

In Python, you can use the regexp

A.*?A which is less greedy, and only will match

AbbbbbbbbA

Is there a way to do this with the current implementation?

Regards
Stefan

On Wed, Jun 02, 2004 at 08:03:35AM -0400, Paul Kienzle wrote:
> I added some regexp support a couple of releases back (shortly before
> the first matlab release with regexps --- of course it isn't=20
> compatible).
> Look in main/strings.
>=20
> - Paul
>=20
> On Jun 2, 2004, at 3:31 AM, Stefan van der Walt wrote:
>=20
> >If we add enough supporting functions, each package can be distributed=
=20
> >with an install.m file?
> >
> >Supporting functions would, for example, be
> >
> >add_toolbox(id, description)
> >add_category(id, description, parent_toolbox)
> >add_function([category1 category2 ...])
> >rebuild()
> >
> >The install.m file can then be renamed to <package>-install.m and=20
> >stored in a directory -- needed for rebuilding the index from scratch=20
> >later on.
> >
> >Every time a function is added the appropriate toolbox contents.m=20
> >should be rebuilt, using the descriptions extracted by an octave=20
> >function. What is the current level of regular expression support? =20
> >With regular expressions this problem becomes a lot simpler.
> >
> >Comments and ideas?
> >
> >Regards
> >St=E9fan
> >
> >Paul Kienzle wrote:
> >>Here are some features that I consider important:
> >>(1) distributed description --- adding a package to the system
> >>should automatically update the indices to reflect the presence
> >>of that package.   E.g., adding octave forge should add a number
> >>of functions to Octave's existing string categories, amongst others.
> >>An install=3Dtime step is sufficient --- it doesn't need to happen
> >>every time a directory is added to the path, though it's okay if it
> >>does so.  A single function can belong to multiple subcategories in
> >>different toolboxes.
> >>(2) easy syntax --- it is hard to get more minimal than the INDEX
> >>file format that make_index is using.
> >>(3) minimal tools --- you cannot require python on user
> >>systems.   For developer systems, the fewer languages
> >>required the better.  I guess beating Octave's string
> >>handling into shape so that it is up to the task itself is a bit
> >>too ambitious.
> >>(4) multiple output targets, including matlab-style contents.m.
> >>I'm sure there's others, but not that I can think of tonight.
> >>- Paul
> >>On Jun 1, 2004, at 12:20 PM, Stefan van der Walt wrote:
> >>>Hi Paul
> >>>
> >>>I started working on this today.  Wrote a python script similar in
> >>>functionality to make_index. It uses octave to provide the function
> >>>descriptions, however -- which means that you can build indeces=20
> >>>having
> >>>only a binary distribution available.
> >>>
> >>>An example config file looks like this:
> >>>
> >>>---
> >>>
> >>>octave =3D "/usr/share/octave/2.1.57/m"
> >>>forge =3D "/usr/share/octave/2.1.57/site/m/octave-forge/"
> >>>
> >>>signal {
> >>>  name =3D "Signal Processing Toolbox"
> >>>  add_dirs =3D "signal"
> >>>  add_files =3D "ifft ifft2"
> >>>  unsupported =3D "nosup neithersup"
> >>>  sub =3D "numeric"
> >>>}
> >>>
> >>>numeric {
> >>>  name =3D "Numerical Games"
> >>>  add_dirs =3D "blah"
> >>>}
> >>>
> >>>---
> >>>
> >>>It scans all the directories specified in "add_dirs" directives for=20
> >>>.m
> >>>files and then queries octave for their descriptions, doing some
> >>>gung-ho parsing to take care of all the different comment formats ou=
t
> >>>there.
> >>>
> >>>The generated file signal.m can be generated (note: I havn't include=
d
> >>>any sub-categories here):
> >>>
> >>>##
> >>>## Signal Processing Toolbox
> >>>##
> >>>## arburg       - fits an AR (p)-model using Burg method (a so=20
> >>>called maximum entropy model).
> >>>## arch_fit     - Fit an ARCH regression model to the time series Y=20
> >>>using the scoring algorithm in Engle's original ARCH paper.
> >>>## arch_rnd     - Simulate an ARCH sequence of length T with AR=20
> >>>coefficients B and CH coefficients A.
> >>>## arch_test    - For a linear regression model
> >>>## arma_rnd     - Return a simulation of the ARMA model
> >>>## aryule       - fits an AR (p)-model with Yule-Walker estimates.
> >>>## autocor      - Return the autocorrelations from lag 0 to H of=20
> >>>vector X.
> >>>.
> >>>.
> >>>.
> >>>## zplane       - Plot the poles and zeros.
> >>>##
> >>>## Unsupported functions:
> >>>##
> >>>## nosup
> >>>## neithersup
> >>>##
> >>>
> >>>It would also be easy to factor this out into a module so that only
> >>>the front-end changes with every other method of presentation.  This
> >>>way you can generate a web page index, category descriptions like
> >>>signal.m or anything else you want in any format.
> >>>
> >>>If the generated category descriptions are in the loadpath, calling
> >>>"help signal" should do the job.  It will be trivial to generate a
> >>>toolbox.m for "help toolbox" to get a list of all toolboxes.
> >>>
> >>>Also, a toolbox can "contain" any other toolbox.  You can, for
> >>>example, make an image processing toolbox and include the signal=20
> >>>processing
> >>>toolbox if you so wish.
> >>>
> >>>Is this going in the right direction?  If not, I would appreciate a
> >>>few pointers!
> >>>
> >>>I attach the scripts.
> >>>
> >>>Regards
> >>>Stefan
> >>>
> >>>On Sun, May 30, 2004 at 12:00:46AM -0400, Paul Kienzle wrote:
> >>>
> >>>>Stefan,
> >>>>
> >>>>I've extended dispatch() so that even functions called with no
> >>>>parameters can be dispatched so octave-forge could now provide
> >>>>categorical help independent of octave if we so choose.
> >>>>
> >>>>There's a small caveat in that dispatch already dispatches on help,=
=20
> >>>>so
> >>>>we need to remove it and call our own
> >>>>
> >>>>    ##PKG_ADD: dispatch('help','string')
> >>>>    ##PKG_ADD: dispatch('help','cathelp','any')
> >>>>    function cathelp(varargin)
> >>>>      ...
> >>>>      dispatch_help(pars{:})
> >>>>
> >>>>The call to dispatch_help at the end in order to fill in base help=20
> >>>>for
> >>>>dispatched functions.
> >>>>
> >>>>Are you still interested?
> >>>>
> >>>>My rule lately has been to not do anything too sophisticated=20
> >>>>otherwise
> >>>>nothing ever gets done.  At least that's my excuse for not fixing=20
> >>>>the
> >>>>problem I just noticed in dispatch which is that dispatches can't
> >>>>chain.  You could
> >>>>fake it if dispatch('name','type') returned the dispatch function=20
> >>>>for
> >>>>that type, or if dispatch('name','new','type') returned the old
> >>>>dispatch function for that type.
> >>>>
> >>>>- Paul
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> >installation-authoring solution that does it all. Learn more and
> >evaluate today! http://www.installshield.com/Dev2Dev/0504
> >_______________________________________________
> >Octave-dev mailing list
> >Oct...@li...
> >https://lists.sourceforge.net/lists/listinfo/octave-dev
> >
>=20

Re: [OctDev] Re: email not getting through

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

On Jun 3, 2004, at 6:42 AM, David Bateman wrote:

> According to Stefan van der Walt <st...@su...> (on 06/03/04):
>> Getting a function's description would be a lot easier if 'help' could
>> return the string produced by help(func)... Would this be easy to add?
> ...
> An alternative is that you can have access to the symbol table and 
> files
> helps from within an oct-file  (but not the keywords or operators, as
> these are static in help.cc). A test implementation that allows the 
> help
> text to be accessed in this manner is in the attached oct-file. You can
> do something like 'fft_help = helpstring("fft")' to get the help text 
> of
> the fft in this manner.

To handle help for dispatched functions without preloading
the base function I'm already playing some of these games
in main/miscellaneous/dispatch.cc.  You could easily extend
it to return the help string as per David's suggestion.  Indeed
you would have to, since the doc string for a dispatched function
contains:

	<>
	Overloaded function:
	...

with the <> replaced by the docstring of the base function
by a call to dispatch_help.

A couple of related things on the help wishlist:

(1) the examples that I provide for some of the functions ought
to be incorporated into the docstring.  Right now I have them
embedded as a special kind of test block, but there is no reason
we couldn't encode them directly in the help text.  With suitable
markup, they could be automatically extracted and run from the
returned help string.

(2) since we can now overload help, interested parties could
provide internationalization support based on if
file_in_loadpath([fn,".",locale_lang]) then display that file with
the help system rather than the usual doc string.  I don't know
that any parties are interested though.

(3) wikipedia is starting to become useful for engineering math
concepts.  Putting live links in the help text to wikipedia articles
(and if it seems appropriate, mathworld, though I prefer to support
materials using the FDL).  Along with cross-indexing the see-also
text (and indeed, any text in the help string that happens to be a
documented octave symbol), the html version of the docs
becomes very useful.

Paul Kienzle
pki...@us...

Re: [OctDev] Re: email not getting through

[David B. <Dav...@mo...>]

According to Stefan van der Walt <st...@su...> (on 06/03/04):
> Getting a function's description would be a lot easier if 'help' could
> return the string produced by help(func)... Would this be easy to add?

The problem is that "help" is a function that itself calls different
functions that return void, who themselves call other functions that
are void. So the change is likely to be large if we try and get all of
these functions to return a string.

An alternative, is that all of these functions write to the stream "os"
and so you could hijack this stream and replace it with a string
stream that is used to create your return value. You'd also need to
turn off the pager and ignore calls like "help -i <file>". You'll then
need to put the pager and stream os back in place before returning

Unfortunately you can't write your own version of help that does this as 
the functions simple_help and builtin_help in help.cc are both static.
So you'll either need octave to be modified to include the above change
or at least make simple_help and builtin_help callable externally....

An alternative is that you can have access to the symbol table and files
helps from within an oct-file  (but not the keywords or operators, as
these are static in help.cc). A test implementation that allows the help
text to be accessed in this manner is in the attached oct-file. You can
do something like 'fft_help = helpstring("fft")' to get the help text of
the fft in this manner.

Regards
David


-- 
David Bateman                                Dav...@mo...
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

Re: [OctDev] Re: email not getting through

[Stefan v. d. W. <st...@su...>]

Getting a function's description would be a lot easier if 'help' could
return the string produced by help(func)... Would this be easy to add?

Regards
Stefan

On Wed, Jun 02, 2004 at 07:56:00AM -0400, Paul Kienzle wrote:
> David,
>=20
> I think rebuild() is referring just to rebuilding the doc tie-ins.
>=20
> Keep it simple for now (adding just categorical help to
> octave-forge), but leave room for growth into independent
> packages which can be built from source.
>=20
> - Paul
>=20
> On Jun 2, 2004, at 5:12 AM, David Bateman wrote:
>=20
> >Stefan,
> >
> >If I get this right your function "rebuild()" would build the oct-file=
s
> >in a particular package? At the moment this is rather complex, since
> >you have to first configure octave-forge with the packages=20
> >"configure.add"
> >taken into account, then build the oct-files.
> >
> >One advantage you'll have running from within octave is that you'll
> >have access to a number of built-in variables with lots of the
> >necessary information. You might also like to have a support function
> >"configure()" that does something similar to the current octave-forge
> >configure.base autoconf code, then calls a toolbox specific configure
> >function, and then finally writes out a file that the build process
> >can find (perhaps Makeconf).
> >
> >One problem I see that you'll have is a case like mine where I have=20
> >three
> >versions of octave installed. At the moment I have
> >
> >/usr/bin/octave                (2.1.57)
> >/opt/octave/bin/octave         (CVS)
> >/opt/octave-2.1.50/bin/octave  (2.1.50)
> >
> >In general I have the /usr/bin/octave first in my path, and if I want
> >to work with the CVS I call /opt/octave/bin/octave directly. However,=20
> >your
> >build process will have to take this into account when finding the=20
> >version
> >of mkoctfile to be used. It can't just do "system('mkoctfile=20
> ><file>')", but
> >rather must reference the version of mkoctfile with an absolute path,=20
> >that
> >it must find out somehow..
> >
> >Regards
> >David
> >
> >
> >
> >According to Stefan van der Walt <st...@su...> (on 06/02/04):
> >>If we add enough supporting functions, each package can be distribute=
d
> >>with an install.m file?
> >>
> >>Supporting functions would, for example, be
> >>
> >>add_toolbox(id, description)
> >>add_category(id, description, parent_toolbox)
> >>add_function([category1 category2 ...])
> >>rebuild()
> >>
> >>The install.m file can then be renamed to <package>-install.m and
> >>stored in a directory -- needed for rebuilding the index from scratch
> >>later on.
> >>
> >>Every time a function is added the appropriate toolbox contents.m=20
> >>should
> >>be rebuilt, using the descriptions extracted by an octave function.
> >>What is the current level of regular expression support?  With regula=
r
> >>expressions this problem becomes a lot simpler.
> >>
> >>Comments and ideas?
> >>
> >>Regards
> >>St=E9fan
> >>
> >>Paul Kienzle wrote:
> >>>
> >>>Here are some features that I consider important:
> >>>
> >>>(1) distributed description --- adding a package to the system
> >>>should automatically update the indices to reflect the presence
> >>>of that package.   E.g., adding octave forge should add a number
> >>>of functions to Octave's existing string categories, amongst others.
> >>>An install=3Dtime step is sufficient --- it doesn't need to happen
> >>>every time a directory is added to the path, though it's okay if it
> >>>does so.  A single function can belong to multiple subcategories in
> >>>different toolboxes.
> >>>
> >>>(2) easy syntax --- it is hard to get more minimal than the INDEX
> >>>file format that make_index is using.
> >>>
> >>>(3) minimal tools --- you cannot require python on user
> >>>systems.   For developer systems, the fewer languages
> >>>required the better.  I guess beating Octave's string
> >>>handling into shape so that it is up to the task itself is a bit
> >>>too ambitious.
> >>>
> >>>(4) multiple output targets, including matlab-style contents.m.
> >>>
> >>>I'm sure there's others, but not that I can think of tonight.
> >>>
> >>>- Paul
> >>>
> >>>
> >>>On Jun 1, 2004, at 12:20 PM, Stefan van der Walt wrote:
> >>>
> >>>>Hi Paul
> >>>>
> >>>>I started working on this today.  Wrote a python script similar in
> >>>>functionality to make_index. It uses octave to provide the function
> >>>>descriptions, however -- which means that you can build indeces=20
> >>>>having
> >>>>only a binary distribution available.
> >>>>
> >>>>An example config file looks like this:
> >>>>
> >>>>---
> >>>>
> >>>>octave =3D "/usr/share/octave/2.1.57/m"
> >>>>forge =3D "/usr/share/octave/2.1.57/site/m/octave-forge/"
> >>>>
> >>>>signal {
> >>>> name =3D "Signal Processing Toolbox"
> >>>> add_dirs =3D "signal"
> >>>> add_files =3D "ifft ifft2"
> >>>> unsupported =3D "nosup neithersup"
> >>>> sub =3D "numeric"
> >>>>}
> >>>>
> >>>>numeric {
> >>>> name =3D "Numerical Games"
> >>>> add_dirs =3D "blah"
> >>>>}
> >>>>
> >>>>---
> >>>>
> >>>>It scans all the directories specified in "add_dirs" directives for=
=20
> >>>>.m
> >>>>files and then queries octave for their descriptions, doing some
> >>>>gung-ho parsing to take care of all the different comment formats=20
> >>>>out
> >>>>there.
> >>>>
> >>>>The generated file signal.m can be generated (note: I havn't=20
> >>>>included
> >>>>any sub-categories here):
> >>>>
> >>>>##
> >>>>## Signal Processing Toolbox
> >>>>##
> >>>>## arburg       - fits an AR (p)-model using Burg method (a so=20
> >>>>called
> >>>>maximum entropy model).
> >>>>## arch_fit     - Fit an ARCH regression model to the time series Y
> >>>>using the scoring algorithm in Engle's original ARCH paper.
> >>>>## arch_rnd     - Simulate an ARCH sequence of length T with AR
> >>>>coefficients B and CH coefficients A.
> >>>>## arch_test    - For a linear regression model
> >>>>## arma_rnd     - Return a simulation of the ARMA model
> >>>>## aryule       - fits an AR (p)-model with Yule-Walker estimates.
> >>>>## autocor      - Return the autocorrelations from lag 0 to H of
> >>>>vector X.
> >>>>.
> >>>>.
> >>>>.
> >>>>## zplane       - Plot the poles and zeros.
> >>>>##
> >>>>## Unsupported functions:
> >>>>##
> >>>>## nosup
> >>>>## neithersup
> >>>>##
> >>>>
> >>>>It would also be easy to factor this out into a module so that only
> >>>>the front-end changes with every other method of presentation.  Thi=
s
> >>>>way you can generate a web page index, category descriptions like
> >>>>signal.m or anything else you want in any format.
> >>>>
> >>>>If the generated category descriptions are in the loadpath, calling
> >>>>"help signal" should do the job.  It will be trivial to generate a
> >>>>toolbox.m for "help toolbox" to get a list of all toolboxes.
> >>>>
> >>>>Also, a toolbox can "contain" any other toolbox.  You can, for
> >>>>example, make an image processing toolbox and include the signal
> >>>>processing
> >>>>toolbox if you so wish.
> >>>>
> >>>>Is this going in the right direction?  If not, I would appreciate a
> >>>>few pointers!
> >>>>
> >>>>I attach the scripts.
> >>>>
> >>>>Regards
> >>>>Stefan
> >>>>
> >>>>On Sun, May 30, 2004 at 12:00:46AM -0400, Paul Kienzle wrote:
> >>>>
> >>>>>Stefan,
> >>>>>
> >>>>>I've extended dispatch() so that even functions called with no
> >>>>>parameters can be dispatched so octave-forge could now provide
> >>>>>categorical help independent of octave if we so choose.
> >>>>>
> >>>>>There's a small caveat in that dispatch already dispatches on=20
> >>>>>help, so
> >>>>>we need to remove it and call our own
> >>>>>
> >>>>>   ##PKG_ADD: dispatch('help','string')
> >>>>>   ##PKG_ADD: dispatch('help','cathelp','any')
> >>>>>   function cathelp(varargin)
> >>>>>     ...
> >>>>>     dispatch_help(pars{:})
> >>>>>
> >>>>>The call to dispatch_help at the end in order to fill in base help=
=20
> >>>>>for
> >>>>>dispatched functions.
> >>>>>
> >>>>>Are you still interested?
> >>>>>
> >>>>>My rule lately has been to not do anything too sophisticated=20
> >>>>>otherwise
> >>>>>nothing ever gets done.  At least that's my excuse for not fixing=20
> >>>>>the
> >>>>>problem I just noticed in dispatch which is that dispatches can't
> >>>>>chain.  You could
> >>>>>fake it if dispatch('name','type') returned the dispatch function=20
> >>>>>for
> >>>>>that type, or if dispatch('name','new','type') returned the old
> >>>>>dispatch function for that type.
> >>>>>
> >>>>>- Paul
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by the new InstallShield X.
> >>>From Windows to Linux, servers to mobile, InstallShield X is the one
> >>installation-authoring solution that does it all. Learn more and
> >>evaluate today! http://www.installshield.com/Dev2Dev/0504
> >>_______________________________________________
> >>Octave-dev mailing list
> >>Oct...@li...
> >>https://lists.sourceforge.net/lists/listinfo/octave-dev
> >
> >--=20
> >David Bateman                                Dav...@mo...=
m
> >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
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> >installation-authoring solution that does it all. Learn more and
> >evaluate today! http://www.installshield.com/Dev2Dev/0504
> >_______________________________________________
> >Octave-dev mailing list
> >Oct...@li...
> >https://lists.sourceforge.net/lists/listinfo/octave-dev
> >
>=20

[OctDev] Re: email not getting through

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

On Jun 2, 2004, at 7:58 AM, David Bateman wrote:

> According to Paul Kienzle <pki...@us...> (on 
> 06/02/04):
>>
>> Does building octave-forge from a release version require perl?
>> Certainly generating new octave-forge releases requires perl
>> and other tools.
>
> The comms and fixed stuff use a script mktexi and mkdoc which are in
> perl to create the texinfo documentation, in a process similar to that
> in octave itself (except there it is don't with c++ code). These 
> packages
> also use the texinfo package to build the docs, which I chosen also to
> be compatiable with octave itself.
>
> If I'm required to get rid of these dependencies, then ok. But a good
> means of producing documentation that is
>
> 1) available from with octave, and
> 2) can be built into postscript, pdf and html
>
> must be defined, that is preferable common to all packages.
>
>> I suppose so long as the output files needed for installation
>> can be created by hand reasonably if the author doesn't
>> want to install python, then the use of python as an aid is
>> acceptable. Again, it is not acceptable requirement for an
>> end-user system.
>
> so what do you think of perl and texinfo :-)

texinfo is not a problem since a correct octave installation will
have already required it if necessary (or not, in which case the
doc is a little uglier).

John is very good about pre-building targets that depend on
flex, bison and perl, etc., before he makes a new octave release.
That way users don't need these tools on their systems unless
they want to modify the parts of octave that require them.  We
ought to be doing so as well if we are not already.

So in an idealized packaging environment, if authors want to
create compliant packages, they should be able to fill in all the
bits by hand, but we can provide tools to automate the process
if they are willing to install more stuff on their system.  Does that
sound right?

- Paul

Re: [OctDev] Re: email not getting through

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

I added some regexp support a couple of releases back (shortly before
the first matlab release with regexps --- of course it isn't=20
compatible).
Look in main/strings.

- Paul

On Jun 2, 2004, at 3:31 AM, Stefan van der Walt wrote:

> If we add enough supporting functions, each package can be distributed=20=

> with an install.m file?
>
> Supporting functions would, for example, be
>
> add_toolbox(id, description)
> add_category(id, description, parent_toolbox)
> add_function([category1 category2 ...])
> rebuild()
>
> The install.m file can then be renamed to <package>-install.m and=20
> stored in a directory -- needed for rebuilding the index from scratch=20=

> later on.
>
> Every time a function is added the appropriate toolbox contents.m=20
> should be rebuilt, using the descriptions extracted by an octave=20
> function. What is the current level of regular expression support? =20
> With regular expressions this problem becomes a lot simpler.
>
> Comments and ideas?
>
> Regards
> St=E9fan
>
> Paul Kienzle wrote:
>> Here are some features that I consider important:
>> (1) distributed description --- adding a package to the system
>> should automatically update the indices to reflect the presence
>> of that package.   E.g., adding octave forge should add a number
>> of functions to Octave's existing string categories, amongst others.
>> An install=3Dtime step is sufficient --- it doesn't need to happen
>> every time a directory is added to the path, though it's okay if it
>> does so.  A single function can belong to multiple subcategories in
>> different toolboxes.
>> (2) easy syntax --- it is hard to get more minimal than the INDEX
>> file format that make_index is using.
>> (3) minimal tools --- you cannot require python on user
>> systems.   For developer systems, the fewer languages
>> required the better.  I guess beating Octave's string
>> handling into shape so that it is up to the task itself is a bit
>> too ambitious.
>> (4) multiple output targets, including matlab-style contents.m.
>> I'm sure there's others, but not that I can think of tonight.
>> - Paul
>> On Jun 1, 2004, at 12:20 PM, Stefan van der Walt wrote:
>>> Hi Paul
>>>
>>> I started working on this today.  Wrote a python script similar in
>>> functionality to make_index. It uses octave to provide the function
>>> descriptions, however -- which means that you can build indeces=20
>>> having
>>> only a binary distribution available.
>>>
>>> An example config file looks like this:
>>>
>>> ---
>>>
>>> octave =3D "/usr/share/octave/2.1.57/m"
>>> forge =3D "/usr/share/octave/2.1.57/site/m/octave-forge/"
>>>
>>> signal {
>>>   name =3D "Signal Processing Toolbox"
>>>   add_dirs =3D "signal"
>>>   add_files =3D "ifft ifft2"
>>>   unsupported =3D "nosup neithersup"
>>>   sub =3D "numeric"
>>> }
>>>
>>> numeric {
>>>   name =3D "Numerical Games"
>>>   add_dirs =3D "blah"
>>> }
>>>
>>> ---
>>>
>>> It scans all the directories specified in "add_dirs" directives for=20=

>>> .m
>>> files and then queries octave for their descriptions, doing some
>>> gung-ho parsing to take care of all the different comment formats =
out
>>> there.
>>>
>>> The generated file signal.m can be generated (note: I havn't =
included
>>> any sub-categories here):
>>>
>>> ##
>>> ## Signal Processing Toolbox
>>> ##
>>> ## arburg       - fits an AR (p)-model using Burg method (a so=20
>>> called maximum entropy model).
>>> ## arch_fit     - Fit an ARCH regression model to the time series Y=20=

>>> using the scoring algorithm in Engle's original ARCH paper.
>>> ## arch_rnd     - Simulate an ARCH sequence of length T with AR=20
>>> coefficients B and CH coefficients A.
>>> ## arch_test    - For a linear regression model
>>> ## arma_rnd     - Return a simulation of the ARMA model
>>> ## aryule       - fits an AR (p)-model with Yule-Walker estimates.
>>> ## autocor      - Return the autocorrelations from lag 0 to H of=20
>>> vector X.
>>> .
>>> .
>>> .
>>> ## zplane       - Plot the poles and zeros.
>>> ##
>>> ## Unsupported functions:
>>> ##
>>> ## nosup
>>> ## neithersup
>>> ##
>>>
>>> It would also be easy to factor this out into a module so that only
>>> the front-end changes with every other method of presentation.  This
>>> way you can generate a web page index, category descriptions like
>>> signal.m or anything else you want in any format.
>>>
>>> If the generated category descriptions are in the loadpath, calling
>>> "help signal" should do the job.  It will be trivial to generate a
>>> toolbox.m for "help toolbox" to get a list of all toolboxes.
>>>
>>> Also, a toolbox can "contain" any other toolbox.  You can, for
>>> example, make an image processing toolbox and include the signal=20
>>> processing
>>> toolbox if you so wish.
>>>
>>> Is this going in the right direction?  If not, I would appreciate a
>>> few pointers!
>>>
>>> I attach the scripts.
>>>
>>> Regards
>>> Stefan
>>>
>>> On Sun, May 30, 2004 at 12:00:46AM -0400, Paul Kienzle wrote:
>>>
>>>> Stefan,
>>>>
>>>> I've extended dispatch() so that even functions called with no
>>>> parameters can be dispatched so octave-forge could now provide
>>>> categorical help independent of octave if we so choose.
>>>>
>>>> There's a small caveat in that dispatch already dispatches on help,=20=

>>>> so
>>>> we need to remove it and call our own
>>>>
>>>>     ##PKG_ADD: dispatch('help','string')
>>>>     ##PKG_ADD: dispatch('help','cathelp','any')
>>>>     function cathelp(varargin)
>>>>       ...
>>>>       dispatch_help(pars{:})
>>>>
>>>> The call to dispatch_help at the end in order to fill in base help=20=

>>>> for
>>>> dispatched functions.
>>>>
>>>> Are you still interested?
>>>>
>>>> My rule lately has been to not do anything too sophisticated=20
>>>> otherwise
>>>> nothing ever gets done.  At least that's my excuse for not fixing=20=

>>>> the
>>>> problem I just noticed in dispatch which is that dispatches can't
>>>> chain.  You could
>>>> fake it if dispatch('name','type') returned the dispatch function=20=

>>>> for
>>>> that type, or if dispatch('name','new','type') returned the old
>>>> dispatch function for that type.
>>>>
>>>> - Paul
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> =46rom Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] Re: email not getting through

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

David,

I think rebuild() is referring just to rebuilding the doc tie-ins.

Keep it simple for now (adding just categorical help to
octave-forge), but leave room for growth into independent
packages which can be built from source.

- Paul

On Jun 2, 2004, at 5:12 AM, David Bateman wrote:

> Stefan,
>
> If I get this right your function "rebuild()" would build the =
oct-files
> in a particular package? At the moment this is rather complex, since
> you have to first configure octave-forge with the packages=20
> "configure.add"
> taken into account, then build the oct-files.
>
> One advantage you'll have running from within octave is that you'll
> have access to a number of built-in variables with lots of the
> necessary information. You might also like to have a support function
> "configure()" that does something similar to the current octave-forge
> configure.base autoconf code, then calls a toolbox specific configure
> function, and then finally writes out a file that the build process
> can find (perhaps Makeconf).
>
> One problem I see that you'll have is a case like mine where I have=20
> three
> versions of octave installed. At the moment I have
>
> /usr/bin/octave                (2.1.57)
> /opt/octave/bin/octave         (CVS)
> /opt/octave-2.1.50/bin/octave  (2.1.50)
>
> In general I have the /usr/bin/octave first in my path, and if I want
> to work with the CVS I call /opt/octave/bin/octave directly. However,=20=

> your
> build process will have to take this into account when finding the=20
> version
> of mkoctfile to be used. It can't just do "system('mkoctfile=20
> <file>')", but
> rather must reference the version of mkoctfile with an absolute path,=20=

> that
> it must find out somehow..
>
> Regards
> David
>
>
>
> According to Stefan van der Walt <st...@su...> (on 06/02/04):
>> If we add enough supporting functions, each package can be =
distributed
>> with an install.m file?
>>
>> Supporting functions would, for example, be
>>
>> add_toolbox(id, description)
>> add_category(id, description, parent_toolbox)
>> add_function([category1 category2 ...])
>> rebuild()
>>
>> The install.m file can then be renamed to <package>-install.m and
>> stored in a directory -- needed for rebuilding the index from scratch
>> later on.
>>
>> Every time a function is added the appropriate toolbox contents.m=20
>> should
>> be rebuilt, using the descriptions extracted by an octave function.
>> What is the current level of regular expression support?  With =
regular
>> expressions this problem becomes a lot simpler.
>>
>> Comments and ideas?
>>
>> Regards
>> St=E9fan
>>
>> Paul Kienzle wrote:
>>>
>>> Here are some features that I consider important:
>>>
>>> (1) distributed description --- adding a package to the system
>>> should automatically update the indices to reflect the presence
>>> of that package.   E.g., adding octave forge should add a number
>>> of functions to Octave's existing string categories, amongst others.
>>> An install=3Dtime step is sufficient --- it doesn't need to happen
>>> every time a directory is added to the path, though it's okay if it
>>> does so.  A single function can belong to multiple subcategories in
>>> different toolboxes.
>>>
>>> (2) easy syntax --- it is hard to get more minimal than the INDEX
>>> file format that make_index is using.
>>>
>>> (3) minimal tools --- you cannot require python on user
>>> systems.   For developer systems, the fewer languages
>>> required the better.  I guess beating Octave's string
>>> handling into shape so that it is up to the task itself is a bit
>>> too ambitious.
>>>
>>> (4) multiple output targets, including matlab-style contents.m.
>>>
>>> I'm sure there's others, but not that I can think of tonight.
>>>
>>> - Paul
>>>
>>>
>>> On Jun 1, 2004, at 12:20 PM, Stefan van der Walt wrote:
>>>
>>>> Hi Paul
>>>>
>>>> I started working on this today.  Wrote a python script similar in
>>>> functionality to make_index. It uses octave to provide the function
>>>> descriptions, however -- which means that you can build indeces=20
>>>> having
>>>> only a binary distribution available.
>>>>
>>>> An example config file looks like this:
>>>>
>>>> ---
>>>>
>>>> octave =3D "/usr/share/octave/2.1.57/m"
>>>> forge =3D "/usr/share/octave/2.1.57/site/m/octave-forge/"
>>>>
>>>> signal {
>>>>  name =3D "Signal Processing Toolbox"
>>>>  add_dirs =3D "signal"
>>>>  add_files =3D "ifft ifft2"
>>>>  unsupported =3D "nosup neithersup"
>>>>  sub =3D "numeric"
>>>> }
>>>>
>>>> numeric {
>>>>  name =3D "Numerical Games"
>>>>  add_dirs =3D "blah"
>>>> }
>>>>
>>>> ---
>>>>
>>>> It scans all the directories specified in "add_dirs" directives for=20=

>>>> .m
>>>> files and then queries octave for their descriptions, doing some
>>>> gung-ho parsing to take care of all the different comment formats=20=

>>>> out
>>>> there.
>>>>
>>>> The generated file signal.m can be generated (note: I havn't=20
>>>> included
>>>> any sub-categories here):
>>>>
>>>> ##
>>>> ## Signal Processing Toolbox
>>>> ##
>>>> ## arburg       - fits an AR (p)-model using Burg method (a so=20
>>>> called
>>>> maximum entropy model).
>>>> ## arch_fit     - Fit an ARCH regression model to the time series Y
>>>> using the scoring algorithm in Engle's original ARCH paper.
>>>> ## arch_rnd     - Simulate an ARCH sequence of length T with AR
>>>> coefficients B and CH coefficients A.
>>>> ## arch_test    - For a linear regression model
>>>> ## arma_rnd     - Return a simulation of the ARMA model
>>>> ## aryule       - fits an AR (p)-model with Yule-Walker estimates.
>>>> ## autocor      - Return the autocorrelations from lag 0 to H of
>>>> vector X.
>>>> .
>>>> .
>>>> .
>>>> ## zplane       - Plot the poles and zeros.
>>>> ##
>>>> ## Unsupported functions:
>>>> ##
>>>> ## nosup
>>>> ## neithersup
>>>> ##
>>>>
>>>> It would also be easy to factor this out into a module so that only
>>>> the front-end changes with every other method of presentation.  =
This
>>>> way you can generate a web page index, category descriptions like
>>>> signal.m or anything else you want in any format.
>>>>
>>>> If the generated category descriptions are in the loadpath, calling
>>>> "help signal" should do the job.  It will be trivial to generate a
>>>> toolbox.m for "help toolbox" to get a list of all toolboxes.
>>>>
>>>> Also, a toolbox can "contain" any other toolbox.  You can, for
>>>> example, make an image processing toolbox and include the signal
>>>> processing
>>>> toolbox if you so wish.
>>>>
>>>> Is this going in the right direction?  If not, I would appreciate a
>>>> few pointers!
>>>>
>>>> I attach the scripts.
>>>>
>>>> Regards
>>>> Stefan
>>>>
>>>> On Sun, May 30, 2004 at 12:00:46AM -0400, Paul Kienzle wrote:
>>>>
>>>>> Stefan,
>>>>>
>>>>> I've extended dispatch() so that even functions called with no
>>>>> parameters can be dispatched so octave-forge could now provide
>>>>> categorical help independent of octave if we so choose.
>>>>>
>>>>> There's a small caveat in that dispatch already dispatches on=20
>>>>> help, so
>>>>> we need to remove it and call our own
>>>>>
>>>>>    ##PKG_ADD: dispatch('help','string')
>>>>>    ##PKG_ADD: dispatch('help','cathelp','any')
>>>>>    function cathelp(varargin)
>>>>>      ...
>>>>>      dispatch_help(pars{:})
>>>>>
>>>>> The call to dispatch_help at the end in order to fill in base help=20=

>>>>> for
>>>>> dispatched functions.
>>>>>
>>>>> Are you still interested?
>>>>>
>>>>> My rule lately has been to not do anything too sophisticated=20
>>>>> otherwise
>>>>> nothing ever gets done.  At least that's my excuse for not fixing=20=

>>>>> the
>>>>> problem I just noticed in dispatch which is that dispatches can't
>>>>> chain.  You could
>>>>> fake it if dispatch('name','type') returned the dispatch function=20=

>>>>> for
>>>>> that type, or if dispatch('name','new','type') returned the old
>>>>> dispatch function for that type.
>>>>>
>>>>> - Paul
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the new InstallShield X.
>>> =46rom Windows to Linux, servers to mobile, InstallShield X is the =
one
>> installation-authoring solution that does it all. Learn more and
>> evaluate today! http://www.installshield.com/Dev2Dev/0504
>> _______________________________________________
>> Octave-dev mailing list
>> Oct...@li...
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>
> --=20
> David Bateman                                =
Dav...@mo...
> 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
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> =46rom Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] Re: email not getting through

[David B. <Dav...@mo...>]

Stefan,

If I get this right your function "rebuild()" would build the oct-files
in a particular package? At the moment this is rather complex, since=20
you have to first configure octave-forge with the packages "configure.add=
"
taken into account, then build the oct-files.

One advantage you'll have running from within octave is that you'll
have access to a number of built-in variables with lots of the
necessary information. You might also like to have a support function=20
"configure()" that does something similar to the current octave-forge
configure.base autoconf code, then calls a toolbox specific configure
function, and then finally writes out a file that the build process
can find (perhaps Makeconf).

One problem I see that you'll have is a case like mine where I have three
versions of octave installed. At the moment I have

/usr/bin/octave                (2.1.57)
/opt/octave/bin/octave         (CVS)
/opt/octave-2.1.50/bin/octave  (2.1.50)

In general I have the /usr/bin/octave first in my path, and if I want
to work with the CVS I call /opt/octave/bin/octave directly. However, you=
r
build process will have to take this into account when finding the versio=
n
of mkoctfile to be used. It can't just do "system('mkoctfile <file>')", b=
ut
rather must reference the version of mkoctfile with an absolute path, tha=
t
it must find out somehow..

Regards
David



According to Stefan van der Walt <st...@su...> (on 06/02/04):
> If we add enough supporting functions, each package can be distributed=20
> with an install.m file?
>=20
> Supporting functions would, for example, be
>=20
> add_toolbox(id, description)
> add_category(id, description, parent_toolbox)
> add_function([category1 category2 ...])
> rebuild()
>=20
> The install.m file can then be renamed to <package>-install.m and=20
> stored in a directory -- needed for rebuilding the index from scratch=20
> later on.
>=20
> Every time a function is added the appropriate toolbox contents.m shoul=
d=20
> be rebuilt, using the descriptions extracted by an octave function.=20
> What is the current level of regular expression support?  With regular=20
> expressions this problem becomes a lot simpler.
>=20
> Comments and ideas?
>=20
> Regards
> St=E9fan
>=20
> Paul Kienzle wrote:
> >
> >Here are some features that I consider important:
> >
> >(1) distributed description --- adding a package to the system
> >should automatically update the indices to reflect the presence
> >of that package.   E.g., adding octave forge should add a number
> >of functions to Octave's existing string categories, amongst others.
> >An install=3Dtime step is sufficient --- it doesn't need to happen
> >every time a directory is added to the path, though it's okay if it
> >does so.  A single function can belong to multiple subcategories in
> >different toolboxes.
> >
> >(2) easy syntax --- it is hard to get more minimal than the INDEX
> >file format that make_index is using.
> >
> >(3) minimal tools --- you cannot require python on user
> >systems.   For developer systems, the fewer languages
> >required the better.  I guess beating Octave's string
> >handling into shape so that it is up to the task itself is a bit
> >too ambitious.
> >
> >(4) multiple output targets, including matlab-style contents.m.
> >
> >I'm sure there's others, but not that I can think of tonight.
> >
> >- Paul
> >
> >
> >On Jun 1, 2004, at 12:20 PM, Stefan van der Walt wrote:
> >
> >>Hi Paul
> >>
> >>I started working on this today.  Wrote a python script similar in
> >>functionality to make_index. It uses octave to provide the function
> >>descriptions, however -- which means that you can build indeces havin=
g
> >>only a binary distribution available.
> >>
> >>An example config file looks like this:
> >>
> >>---
> >>
> >>octave =3D "/usr/share/octave/2.1.57/m"
> >>forge =3D "/usr/share/octave/2.1.57/site/m/octave-forge/"
> >>
> >>signal {
> >>  name =3D "Signal Processing Toolbox"
> >>  add_dirs =3D "signal"
> >>  add_files =3D "ifft ifft2"
> >>  unsupported =3D "nosup neithersup"
> >>  sub =3D "numeric"
> >>}
> >>
> >>numeric {
> >>  name =3D "Numerical Games"
> >>  add_dirs =3D "blah"
> >>}
> >>
> >>---
> >>
> >>It scans all the directories specified in "add_dirs" directives for .=
m
> >>files and then queries octave for their descriptions, doing some
> >>gung-ho parsing to take care of all the different comment formats out
> >>there.
> >>
> >>The generated file signal.m can be generated (note: I havn't included
> >>any sub-categories here):
> >>
> >>##
> >>## Signal Processing Toolbox
> >>##
> >>## arburg       - fits an AR (p)-model using Burg method (a so called=
=20
> >>maximum entropy model).
> >>## arch_fit     - Fit an ARCH regression model to the time series Y=20
> >>using the scoring algorithm in Engle's original ARCH paper.
> >>## arch_rnd     - Simulate an ARCH sequence of length T with AR=20
> >>coefficients B and CH coefficients A.
> >>## arch_test    - For a linear regression model
> >>## arma_rnd     - Return a simulation of the ARMA model
> >>## aryule       - fits an AR (p)-model with Yule-Walker estimates.
> >>## autocor      - Return the autocorrelations from lag 0 to H of=20
> >>vector X.
> >>.
> >>.
> >>.
> >>## zplane       - Plot the poles and zeros.
> >>##
> >>## Unsupported functions:
> >>##
> >>## nosup
> >>## neithersup
> >>##
> >>
> >>It would also be easy to factor this out into a module so that only
> >>the front-end changes with every other method of presentation.  This
> >>way you can generate a web page index, category descriptions like
> >>signal.m or anything else you want in any format.
> >>
> >>If the generated category descriptions are in the loadpath, calling
> >>"help signal" should do the job.  It will be trivial to generate a
> >>toolbox.m for "help toolbox" to get a list of all toolboxes.
> >>
> >>Also, a toolbox can "contain" any other toolbox.  You can, for
> >>example, make an image processing toolbox and include the signal=20
> >>processing
> >>toolbox if you so wish.
> >>
> >>Is this going in the right direction?  If not, I would appreciate a
> >>few pointers!
> >>
> >>I attach the scripts.
> >>
> >>Regards
> >>Stefan
> >>
> >>On Sun, May 30, 2004 at 12:00:46AM -0400, Paul Kienzle wrote:
> >>
> >>>Stefan,
> >>>
> >>>I've extended dispatch() so that even functions called with no
> >>>parameters can be dispatched so octave-forge could now provide
> >>>categorical help independent of octave if we so choose.
> >>>
> >>>There's a small caveat in that dispatch already dispatches on help, =
so
> >>>we need to remove it and call our own
> >>>
> >>>    ##PKG_ADD: dispatch('help','string')
> >>>    ##PKG_ADD: dispatch('help','cathelp','any')
> >>>    function cathelp(varargin)
> >>>      ...
> >>>      dispatch_help(pars{:})
> >>>
> >>>The call to dispatch_help at the end in order to fill in base help f=
or
> >>>dispatched functions.
> >>>
> >>>Are you still interested?
> >>>
> >>>My rule lately has been to not do anything too sophisticated otherwi=
se
> >>>nothing ever gets done.  At least that's my excuse for not fixing th=
e
> >>>problem I just noticed in dispatch which is that dispatches can't
> >>>chain.  You could
> >>>fake it if dispatch('name','type') returned the dispatch function fo=
r
> >>>that type, or if dispatch('name','new','type') returned the old
> >>>dispatch function for that type.
> >>>
> >>>- Paul
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

--=20
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 48 04 (Ph)=20
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)=20
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:=20

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

[OctDev] Re: email not getting through

[Stefan v. d. W. <st...@su...>]

If we add enough supporting functions, each package can be distributed 
with an install.m file?

Supporting functions would, for example, be

add_toolbox(id, description)
add_category(id, description, parent_toolbox)
add_function([category1 category2 ...])
rebuild()

The install.m file can then be renamed to <package>-install.m and 
stored in a directory -- needed for rebuilding the index from scratch 
later on.

Every time a function is added the appropriate toolbox contents.m should 
be rebuilt, using the descriptions extracted by an octave function. 
What is the current level of regular expression support?  With regular 
expressions this problem becomes a lot simpler.

Comments and ideas?

Regards
Stéfan

Paul Kienzle wrote:
> 
> Here are some features that I consider important:
> 
> (1) distributed description --- adding a package to the system
> should automatically update the indices to reflect the presence
> of that package.   E.g., adding octave forge should add a number
> of functions to Octave's existing string categories, amongst others.
> An install=time step is sufficient --- it doesn't need to happen
> every time a directory is added to the path, though it's okay if it
> does so.  A single function can belong to multiple subcategories in
> different toolboxes.
> 
> (2) easy syntax --- it is hard to get more minimal than the INDEX
> file format that make_index is using.
> 
> (3) minimal tools --- you cannot require python on user
> systems.   For developer systems, the fewer languages
> required the better.  I guess beating Octave's string
> handling into shape so that it is up to the task itself is a bit
> too ambitious.
> 
> (4) multiple output targets, including matlab-style contents.m.
> 
> I'm sure there's others, but not that I can think of tonight.
> 
> - Paul
> 
> 
> On Jun 1, 2004, at 12:20 PM, Stefan van der Walt wrote:
> 
>> Hi Paul
>>
>> I started working on this today.  Wrote a python script similar in
>> functionality to make_index. It uses octave to provide the function
>> descriptions, however -- which means that you can build indeces having
>> only a binary distribution available.
>>
>> An example config file looks like this:
>>
>> ---
>>
>> octave = "/usr/share/octave/2.1.57/m"
>> forge = "/usr/share/octave/2.1.57/site/m/octave-forge/"
>>
>> signal {
>>   name = "Signal Processing Toolbox"
>>   add_dirs = "signal"
>>   add_files = "ifft ifft2"
>>   unsupported = "nosup neithersup"
>>   sub = "numeric"
>> }
>>
>> numeric {
>>   name = "Numerical Games"
>>   add_dirs = "blah"
>> }
>>
>> ---
>>
>> It scans all the directories specified in "add_dirs" directives for .m
>> files and then queries octave for their descriptions, doing some
>> gung-ho parsing to take care of all the different comment formats out
>> there.
>>
>> The generated file signal.m can be generated (note: I havn't included
>> any sub-categories here):
>>
>> ##
>> ## Signal Processing Toolbox
>> ##
>> ## arburg       - fits an AR (p)-model using Burg method (a so called 
>> maximum entropy model).
>> ## arch_fit     - Fit an ARCH regression model to the time series Y 
>> using the scoring algorithm in Engle's original ARCH paper.
>> ## arch_rnd     - Simulate an ARCH sequence of length T with AR 
>> coefficients B and CH coefficients A.
>> ## arch_test    - For a linear regression model
>> ## arma_rnd     - Return a simulation of the ARMA model
>> ## aryule       - fits an AR (p)-model with Yule-Walker estimates.
>> ## autocor      - Return the autocorrelations from lag 0 to H of 
>> vector X.
>> .
>> .
>> .
>> ## zplane       - Plot the poles and zeros.
>> ##
>> ## Unsupported functions:
>> ##
>> ## nosup
>> ## neithersup
>> ##
>>
>> It would also be easy to factor this out into a module so that only
>> the front-end changes with every other method of presentation.  This
>> way you can generate a web page index, category descriptions like
>> signal.m or anything else you want in any format.
>>
>> If the generated category descriptions are in the loadpath, calling
>> "help signal" should do the job.  It will be trivial to generate a
>> toolbox.m for "help toolbox" to get a list of all toolboxes.
>>
>> Also, a toolbox can "contain" any other toolbox.  You can, for
>> example, make an image processing toolbox and include the signal 
>> processing
>> toolbox if you so wish.
>>
>> Is this going in the right direction?  If not, I would appreciate a
>> few pointers!
>>
>> I attach the scripts.
>>
>> Regards
>> Stefan
>>
>> On Sun, May 30, 2004 at 12:00:46AM -0400, Paul Kienzle wrote:
>>
>>> Stefan,
>>>
>>> I've extended dispatch() so that even functions called with no
>>> parameters can be dispatched so octave-forge could now provide
>>> categorical help independent of octave if we so choose.
>>>
>>> There's a small caveat in that dispatch already dispatches on help, so
>>> we need to remove it and call our own
>>>
>>>     ##PKG_ADD: dispatch('help','string')
>>>     ##PKG_ADD: dispatch('help','cathelp','any')
>>>     function cathelp(varargin)
>>>       ...
>>>       dispatch_help(pars{:})
>>>
>>> The call to dispatch_help at the end in order to fill in base help for
>>> dispatched functions.
>>>
>>> Are you still interested?
>>>
>>> My rule lately has been to not do anything too sophisticated otherwise
>>> nothing ever gets done.  At least that's my excuse for not fixing the
>>> problem I just noticed in dispatch which is that dispatches can't
>>> chain.  You could
>>> fake it if dispatch('name','type') returned the dispatch function for
>>> that type, or if dispatch('name','new','type') returned the old
>>> dispatch function for that type.
>>>
>>> - Paul

[OctDev] MEX

[Dhoto <dh...@ao...>]

i have this source, when i compiled it success, but when i run it, octave  
can not define this command

mex vqlabel.c
dhoto@earth:~> mex vqlabel.c
building vqlabel.c
+ mkoctfile -DHAVE_OCTAVE_21 -v -o vqlabel.oct mex_vqlabel.cc  
/usr/octave-forge/mex.o -I/usr/octave-forge vqlabel.c
gcc -c -fPIC -I/usr//include/octave-2.1.57  
-I/usr//include/octave-2.1.57/octave -I/usr//include -g -O2  
-I/usr/octave-forge -DHAVE_OCTAVE_21 vqlabel.c -o vqlabel.o
g++ -c -fPIC -I/usr//include/octave-2.1.57  
-I/usr//include/octave-2.1.57/octave -I/usr//include -g -O2  
-I/usr/octave-forge -DHAVE_OCTAVE_21 mex_vqlabel.cc -o mex_vqlabel.o
g++ -shared -o vqlabel.oct /usr/octave-forge/mex.o vqlabel.o mex_vqlabel.o  
-L/usr//lib/octave-2.1.57 -loctinterp -loctave -lcruft -llapack -lblas  
-lfftw3 -lreadline -lncurses -ldl -lhdf5 -lz -lm  
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1  
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../../../x86_64-suse-linux/lib  
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../../../lib64  
-L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.1/../../.. -L/lib/../lib64  
-L/usr/lib/../lib64 -lhdf5 -lz -lfrtbegin -lg2c -lm -lgcc_s


vqlabel.c

#include "mex.h"

void mexFunction(int nlhs, mxArray *plhs[ ],
                  int nrhs, const mxArray *prhs[ ])
{
   int N_center;
   int y1,y2,x1,x2;
   int height,width;
   int i,c,t,y,x,min;
   double *CENTER,*C1,*C2,*C3,*X1,*X2,*D,*I_vq;
   double V1,V2,V3,V4,V5;

   height = mxGetM(prhs[0]);
   width = mxGetN(prhs[0]);
   C1 = mxGetPr(prhs[0]);
   C2 = mxGetPr(prhs[1]);
   C3 = mxGetPr(prhs[2]);
   X1 = mxGetPr(prhs[3]);
   X2 = mxGetPr(prhs[4]);

   y1 = (int)*mxGetPr(prhs[5]);
   x1 = (int)*mxGetPr(prhs[6]);
   y2 = (int)*mxGetPr(prhs[7]);
   x2 = (int)*mxGetPr(prhs[8]);

   N_center = mxGetM(prhs[9]);
   CENTER = mxGetPr(prhs[9]);

   I_vq = (double *) mxMalloc(height*width*sizeof(double));
   D = (double *) mxMalloc(N_center*sizeof(double));

   for (i=0; i<height*width; i++) I_vq[i] = 0;

   for (y=y1; y<=y2; y++)
     for (x=x1; x<=x2; x++)
     {
       c = (x-1)*height+y-1;
       for (i=0; i<N_center; i++)
       {
         V1 = (CENTER[i]-C1[c]);
         t = i+N_center;
         V2 = (CENTER[t]-C2[c]);
         t += N_center;
         V3 = (CENTER[t]-C3[c]);
         t += N_center;
         V4 = (CENTER[t]-X1[c]);
         t += N_center;
         V5 = (CENTER[t]-X2[c]);
         D[i] = V1*V1+V2*V2+V3*V3+V4*V4+V5*V5;
       }
       min = 0;
       for (i=1; i<N_center; i++)
         if (D[i]<D[min]) min = i;
       I_vq[c] = min+1;
     }

   plhs[0] = mxCreateDoubleMatrix(height,width,mxREAL);
   mxSetPr(plhs[0],I_vq);
}

Thank you

-- 
Best regard,
Dhoto

----------------------------------------{@
dh...@ao...

Re: [OctDev] changes in optim

[Michael C. <mic...@ua...>]

On Thursday 20 May 2004 12:08, Etienne Grossmann wrote:
>   Hi all,
>
> On Thu, May 20, 2004 at 02:36:50PM +0200, Michael Creel wrote:
> # Hello all,
> # I have made some significant changes in the ./main/optim directory.
> #
> # bfgs.m and bs_gradient.m have been replaced with bfgsmin.cc and
> # numgradient.cc. The first change introduces interface incompatibilities,
> but # the second has a common interface.
> #
> # There will be some errors in functions that call bfgs.m until the new
> # interface and function name are adopted.
>
> I would have prefered to have bfgs and bfgsmin coexist for some time,
> i.e. until 'minimize' uses 'bfgsmin' and a warning message
>
>  'bfgs is obsolete and will be removed from future octave-forge releases'
>
> has amply warned users of 'bfgs' to do the switch. Is it still time to
> put back bfgs and dependencies?
>
>   Just my 2c,
>
>   Etienne
Hi Etienne and others,
Well, they _have_ coexisted for quite some time, and we discussed replacing 
bfgs a few months ago. The reason I made the change now is that I learned 
that the new functions wouldn't go into new releases if they were in a 3rd 
level subdir. I'm attaching copies of the most recent versions of the 
replaced functions, and I won't touch them again if you decide to restore 
them, but I really think that modifying the other files would not be much 
work, and would help to get people to use routines which are both faster and 
more robust. It will also help to keep the optim directory from being 
overcrowded and confusing.  I myself modified the test_min_1, 2, and 3 
functions to make them use the new function, and it's not hard to do.
Regards, Michael

>
> # There are also two new minimization routines: lbfgsmin.cc and samin.cc,
> that # implement limited memory BFGS, and Simulated Annealing.
> #
> # There is also a celleval.cc, which is like leval.cc, but for cells.
> Perhaps # this might be useful in contexts other that optimization.
> #
> # The motivation for the change is the greater speed and reliability of the
> new # routines. I can post documentation if anyone is interested.
> #
> # I'm sorry for any inconveniences adapting interfaces might cause. I have
> kept # snapshots of the replaced functions if anyone needs them.
> #
> # Regards, Michael
> #
> #
> # -------------------------------------------------------
> # This SF.Net email is sponsored by: Oracle 10g
> # Get certified on the hottest thing ever to hit the market... Oracle 10g.
> # Take an Oracle 10g class now, and we'll give you the exam FREE.
> # http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> # _______________________________________________
> # Octave-dev mailing list
> # Oct...@li...
> # https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] changes in optim

[Michael C. <mic...@ua...>]

On Thursday 20 May 2004 18:42, Paul Kienzle wrote:
> On May 20, 2004, at 8:36 AM, Michael Creel wrote:
> > There is also a celleval.cc, which is like leval.cc, but for cells.
> > Perhaps
> > this might be useful in contexts other that optimization.
>
> Can you remind me again how celleval('f',x) differs from f(x{:})?
>
You can use it inside an .oct function. See bfgsmin.cc for an example. If 
there is a more straightforward way to do this, I'd be happy to know about 
it. The problem inside bfgsmin is that we don't know how many arguments the 
function to be minimized has. So, they are all collected into a cell array, 
so that feval is called with the function name "celleval" and a single 
argument, which holds the name of the function to be evaluated and its 
arguments.
Michael

Re: [OctDev] changes in optim

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

On May 20, 2004, at 8:36 AM, Michael Creel wrote:

> There is also a celleval.cc, which is like leval.cc, but for cells. 
> Perhaps
> this might be useful in contexts other that optimization.

Can you remind me again how celleval('f',x) differs from f(x{:})?

Thanks,

Paul Kienzle
pki...@us...

Re: [OctDev] changes in optim

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

  Hi again,

my previous mail set aside, I approve entirely having a C++
implementation of bfgs.

  Cheers,

  Etienne

On Thu, May 20, 2004 at 12:08:25PM -0400, Etienne Grossmann wrote:
# 
#   Hi all,
# 
# On Thu, May 20, 2004 at 02:36:50PM +0200, Michael Creel wrote:
# # Hello all,
# # I have made some significant changes in the ./main/optim directory.
# # 
# # bfgs.m and bs_gradient.m have been replaced with bfgsmin.cc and 
# # numgradient.cc. The first change introduces interface incompatibilities, but 
# # the second has a common interface.
# #
# # There will be some errors in functions that call bfgs.m until the new 
# # interface and function name are adopted.
# 
# I would have prefered to have bfgs and bfgsmin coexist for some time,
# i.e. until 'minimize' uses 'bfgsmin' and a warning message
# 
#  'bfgs is obsolete and will be removed from future octave-forge releases'
# 
# has amply warned users of 'bfgs' to do the switch. Is it still time to
# put back bfgs and dependencies?
# 
#   Just my 2c,
# 
#   Etienne
# 
# # There are also two new minimization routines: lbfgsmin.cc and samin.cc, that 
# # implement limited memory BFGS, and Simulated Annealing.
# # 
# # There is also a celleval.cc, which is like leval.cc, but for cells. Perhaps 
# # this might be useful in contexts other that optimization.
# # 
# # The motivation for the change is the greater speed and reliability of the new 
# # routines. I can post documentation if anyone is interested.
# # 
# # I'm sorry for any inconveniences adapting interfaces might cause. I have kept 
# # snapshots of the replaced functions if anyone needs them.
# # 
# # Regards, Michael
# # 
# # 
# # -------------------------------------------------------
# # This SF.Net email is sponsored by: Oracle 10g
# # Get certified on the hottest thing ever to hit the market... Oracle 10g. 
# # Take an Oracle 10g class now, and we'll give you the exam FREE.
# # http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
# # _______________________________________________
# # Octave-dev mailing list
# # Oct...@li...
# # https://lists.sourceforge.net/lists/listinfo/octave-dev
# 
# -- 
# Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] changes in optim

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

  Hi all,

On Thu, May 20, 2004 at 02:36:50PM +0200, Michael Creel wrote:
# Hello all,
# I have made some significant changes in the ./main/optim directory.
# 
# bfgs.m and bs_gradient.m have been replaced with bfgsmin.cc and 
# numgradient.cc. The first change introduces interface incompatibilities, but 
# the second has a common interface.
#
# There will be some errors in functions that call bfgs.m until the new 
# interface and function name are adopted.

I would have prefered to have bfgs and bfgsmin coexist for some time,
i.e. until 'minimize' uses 'bfgsmin' and a warning message

 'bfgs is obsolete and will be removed from future octave-forge releases'

has amply warned users of 'bfgs' to do the switch. Is it still time to
put back bfgs and dependencies?

  Just my 2c,

  Etienne

# There are also two new minimization routines: lbfgsmin.cc and samin.cc, that 
# implement limited memory BFGS, and Simulated Annealing.
# 
# There is also a celleval.cc, which is like leval.cc, but for cells. Perhaps 
# this might be useful in contexts other that optimization.
# 
# The motivation for the change is the greater speed and reliability of the new 
# routines. I can post documentation if anyone is interested.
# 
# I'm sorry for any inconveniences adapting interfaces might cause. I have kept 
# snapshots of the replaced functions if anyone needs them.
# 
# Regards, Michael
# 
# 
# -------------------------------------------------------
# This SF.Net email is sponsored by: Oracle 10g
# Get certified on the hottest thing ever to hit the market... Oracle 10g. 
# Take an Oracle 10g class now, and we'll give you the exam FREE.
# http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne