octave-dev — GNU Octave developers' list

Re: [OctDev] Release details

[Per P. <per...@ma...>]

On Sep 9, 2004, at 05:45, Paul Kienzle wrote:

>>
>> are. Probably I have to delete the default rules before defining my 
>> on in
>> the Makefile under OS X... I just changed "%.o:%.cc" to "%.o:%.cc %d".
>> Could you change it back and see what happens...
>
> That fixes it.  Adding the following line above the rule also works, so
> I will commit the change:
>
> 	%.o: %.cc
>
>
> With a correction to the HAVE_SWAP_BYTES test in configure.base
> which I committed earlier, I can now run comm and fixed tests 
> successfully
> for Octave 2.1.55 on OS X.

Works for Octave 2.1.58 on OS X too :-), thanks!

/Per

Re: [OctDev] Release details

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

According to Josep Mon=E9s i Teixidor <jm...@pu...> (on 09/09/04=
):
> cmpermute and uintlut don't work in 2.1.57 (with all the uint=BF stuff =
it
> hasn't got much sense) but qtdecomp does.

Then it probably makes sense to move cpermute.m and uintlut.m to
cpermute.m.in and uintlut.m.in respectively, then add something
like the following to your makefile

t2.1.58=3Dcpermute.m uintlut.m
UINT_TARGETS=3D$($(word 1, $(sort t$(OCTAVE_VERSION) t2.1.58)))

all : $(UINT_TARGETS) onv2.oct cordflt2.oct bwlabel.oct bwfill.oct \
	rotate_scale.oct houghtf.oct graycomatrix.oct \
	$(JPEG) $(PNG)

%.m: %.m.in
        -$(INSTALL) $< $@

In that way the m-files don't exist for vesrions of octave prior to 2.1.5=
8

D.

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

Re: [OctDev] Release details

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

On Sep 8, 2004, at 4:52 PM, David Bateman wrote:

>
> According to Per Persson <per...@ma...> (on 09/08/04):
>> mkoctfile -DHAVE_OCTAVE_21 -v -c Array-f.cc
>
> This is wrong as I have the define
>
> DEFINES = -DOCTAVE_FORGE $(HAVE_DO_FORTRAN_INDEXING) \
>         $(HAVE_PROPAGATE_EMPTY_MATRICES) \
>         $(HAVE_OK_TO_LOSE_IMAGINARY_PART) \
>         $(HAVE_ND_ARRAYS) $(TYPEID_HAS_CLASS) \
>         $(CLASS_HAS_LOAD_SAVE) $(HAVE_6ARG_MX_ND_RED) \
>         $(HAVE_OCTAVE_CONCAT) $(HAVE_SWAP_BYTES)
>
> in the Makefile and then I have the rule
>
> %.o:%.cc %.d
>         @echo "Compiling $@"; \
>         $(MKOCTFILE) $(MOFLAGS) $(DEFINES) -c $<
>
> So it seems that this rule is not taking effect on OS X, and the base 
> rules
> from Makeconf
>
> %.o: %.c ; $(MKOCTFILE) -c $<
> %.o: %.f ; $(MKOCTFILE) -c $<
> %.o: %.cc ; $(MKOCTFILE) -c $<
> %.oct: %.cc ; $(MKOCTFILE) $<
>
> are. Probably I have to delete the default rules before defining my on 
> in
> the Makefile under OS X... I just changed "%.o:%.cc" to "%.o:%.cc %d".
> Could you change it back and see what happens...

That fixes it.  Adding the following line above the rule also works, so
I will commit the change:

	%.o: %.cc


With a correction to the HAVE_SWAP_BYTES test in configure.base
which I committed earlier, I can now run comm and fixed tests 
successfully
for Octave 2.1.55 on OS X.

Thanks,

- Paul

Re: [OctDev] Release details

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

According to David Bateman <Dav...@mo...> (on 09/08/04):
> I just changed "%.o:%.cc" to "%.o:%.cc %d".
> Could you change it back and see what happens...

Yeah, that was it... Try the CVS again...

Sorry
D.

-- 
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] Release details

[Josep i T. <jm...@pu...>]

Hi,


On dc, 2004-09-08 at 15:27, Josep Mon=E9s i Teixidor wrote:
> Paul Kienzle wrote:
>=20
> >
> > There are a number of test failures that I don't expect.  Could someone
> > familiar with the following please look into them:
> >
> >     cmpermute
> >     qtdecomp
>=20
> I'll check these two.
>=20
> >     uintlut
>=20
>=20
> This won't work on 2.1.57.
>=20
>=20
> All check these three ASAP (this evening).


I'm recompiling Octave 2.1.58... I won't be able to test it today as I
promised.

cmpermute and uintlut don't work in 2.1.57 (with all the uint=BF stuff it
hasn't got much sense) but qtdecomp does.

cmpermute should work now in 2.1.58 and I still have to test uintlut and
qtdecomp. If compilation went ok (and I didn't any mistake) I'll test
them tomorrow.

Good night!
--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] Release details

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

According to Per Persson <per...@ma...> (on 09/08/04):
> mkoctfile -DHAVE_OCTAVE_21 -v -c Array-f.cc

This is wrong as I have the define

DEFINES = -DOCTAVE_FORGE $(HAVE_DO_FORTRAN_INDEXING) \
        $(HAVE_PROPAGATE_EMPTY_MATRICES) \
        $(HAVE_OK_TO_LOSE_IMAGINARY_PART) \
        $(HAVE_ND_ARRAYS) $(TYPEID_HAS_CLASS) \
        $(CLASS_HAS_LOAD_SAVE) $(HAVE_6ARG_MX_ND_RED) \
        $(HAVE_OCTAVE_CONCAT) $(HAVE_SWAP_BYTES)

in the Makefile and then I have the rule

%.o:%.cc %.d
        @echo "Compiling $@"; \
        $(MKOCTFILE) $(MOFLAGS) $(DEFINES) -c $< 

So it seems that this rule is not taking effect on OS X, and the base rules 
from Makeconf

%.o: %.c ; $(MKOCTFILE) -c $<
%.o: %.f ; $(MKOCTFILE) -c $<
%.o: %.cc ; $(MKOCTFILE) -c $<
%.oct: %.cc ; $(MKOCTFILE) $<

are. Probably I have to delete the default rules before defining my on in
the Makefile under OS X... I just changed "%.o:%.cc" to "%.o:%.cc %d".
Could you change it back and see what happens...

D.





> g++ -c -I/usr/local/include/octave-2.1.58 
> -I/usr/local/include/octave-2.1.58/octave -I/usr/local/include -g -O2 
> -DHAVE_OCTAVE_21 Array-f.cc -o Array-f.o
> Array-f.cc:63:28: octave/Array2.cc: No such file or directory
> [snip]
> Array-f.cc:84: error: template-id `assign<>' for `int
>    assign(Array2<FixedPointComplex>&, const Array2<FixedPointComplex>&, 
> const
>    FixedPointComplex&)' does not match any template declaration
> make: *** [Array-f.o] Error 1
> 
> This seems to be related to a missing HAVE_ND_ARRAYS definition (and 
> thus shouldn't be unique to OS X?)
> 
> Problem 2)
> 
> mkoctfile -DHAVE_OCTAVE_21 -v -c ov-fixed-mat.cc
> g++ -c -I/usr/local/include/octave-2.1.58 
> -I/usr/local/include/octave-2.1.58/octave -I/usr/local/include -g -O2 
> -DHAVE_OCTAVE_21 ov-fixed-mat.cc -o ov-fixed-mat.o
> ov-fixed-mat.cc:82:73: macro "DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA" 
> requires 3 arguments, but only 2 given
> ov-fixed-mat.cc:82: warning: ISO C++ forbids declaration of `
>    DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA' with no type
> make: *** [ov-fixed-mat.o] Error 1
> 
> Could this be a GCC 3.1 vs 3.3 issue?
> 
> I'll see if I can find the cause of this.
> 
> /Per
> --------
> Per Persson, Ph.D. Applied Signal Processing
> Resume, contact info and more:
> http://homepage.mac.com/persquare
> 
> 

-- 
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] Release details

[Per P. <per...@ma...>]

On Sep 8, 2004, at 07:30, Paul Kienzle wrote:
>
> There are issues in the OS X build against 2.1.55 (swap_4_bytes in
> galois and fixed types is causing problems) that I haven't resolved 
> yet,
> but these are not show stoppers.  The same issues in 2.1.58 would
> be cause for concern.  Anyone tried it?

OK, I may have spoken too soon (again;-)

While main/fixed worked on OS X 10.2.8/GCC 3.1 yesterday, it is broken 
on OS X 10.3.5/GCC 3.3 here and now.

Problem 1)

mkoctfile -DHAVE_OCTAVE_21 -v -c Array-f.cc
g++ -c -I/usr/local/include/octave-2.1.58 
-I/usr/local/include/octave-2.1.58/octave -I/usr/local/include -g -O2 
-DHAVE_OCTAVE_21 Array-f.cc -o Array-f.o
Array-f.cc:63:28: octave/Array2.cc: No such file or directory
[snip]
Array-f.cc:84: error: template-id `assign<>' for `int
    assign(Array2<FixedPointComplex>&, const Array2<FixedPointComplex>&, 
const
    FixedPointComplex&)' does not match any template declaration
make: *** [Array-f.o] Error 1

This seems to be related to a missing HAVE_ND_ARRAYS definition (and 
thus shouldn't be unique to OS X?)

Problem 2)

mkoctfile -DHAVE_OCTAVE_21 -v -c ov-fixed-mat.cc
g++ -c -I/usr/local/include/octave-2.1.58 
-I/usr/local/include/octave-2.1.58/octave -I/usr/local/include -g -O2 
-DHAVE_OCTAVE_21 ov-fixed-mat.cc -o ov-fixed-mat.o
ov-fixed-mat.cc:82:73: macro "DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA" 
requires 3 arguments, but only 2 given
ov-fixed-mat.cc:82: warning: ISO C++ forbids declaration of `
    DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA' with no type
make: *** [ov-fixed-mat.o] Error 1

Could this be a GCC 3.1 vs 3.3 issue?

I'll see if I can find the cause of this.

/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare

Re: [OctDev] Release details

[<jm...@pu...>]

Paul Kienzle wrote:

>
> There are a number of test failures that I don't expect.  Could someone
> familiar with the following please look into them:
>
>     cmpermute
>     qtdecomp

I'll check these two.

>     uintlut


This won't work on 2.1.57.


All check these three ASAP (this evening).

Josep

Re: [OctDev] Release details

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

According to Stefan van der Walt <st...@su...> (on 09/08/04):
> On Wed, Sep 08, 2004 at 01:30:37AM -0400, Paul Kienzle wrote:
> > Hi all,
> > 
> > I posted RELEASE-NOTES.  Check that I've got everything.
> > 
> > Quite the effort for the last couple of months!  Lots of work on
> > comm and fixed as usual.  Some long standing issues addressed
> > in sparse (thanks Andy and David!).  Many extensions to the image
> > processing toolbox.  And of course the usual maintenance
> > (thanks everybody!).
> 
> Somewhat related: what is the current status of the sparse toolbox?
> Will the sparse types eventually go into liboctave?  For now, can one
> use it in oct files?

John has stated on these lists that he doesn't like the use of malloc
in the sparse toolbox and wouldn't accept it as is due to that. He
also pointed out that UMFPACK has better performance than SuperLU and
would prefer that a sparse type in liboctave was based on that.

That said there is no limitation on you using the sparse type within
oct-files, except on the cygwin platform. On cygwin the symbols are
resolved at compile time and so the oct-file would need to be linked
as a shareable library to your own oct-file. I did something like this
with the examples in the fixed point type. See the  files in
main/fixed/examples on how to go about using your types in oct-files..

D.

-- 
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] check integer type in DLD function?

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

Comparing the double_value and int_value works, although there is
bound to be a more elegant way.

There seems to be a movement away from the is_xxx_type() functions.
People use:

type x = args(0).type_value();
if (error_state) {
  error("not happy");
  return retval;
}

Regards
Stefan

On Wed, Sep 08, 2004 at 12:25:37PM +0200, Michael Creel wrote:
> I can't see an easy way to check if an input argument to a DLD function is an 
> integer.
> 
> I can check for a real scalar using foo.is_real_scalar(),
> 
> What's the analogous way to check if it's an integer?
> 
> I hope this is a stupid question!
> 
> Michael

Re: [OctDev] check integer type in DLD function?

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

Here's an answer to my own question that seems to work ok.
Michael


#include "error.h"

<snip>
int tmp = control(i).int_value();
if (error_state)
{
  error("bfgsmin: 3rd argument must be a cell array of 4 integers");
  return true;
}

On Wednesday 08 September 2004 12:25, Michael Creel wrote:
> I can't see an easy way to check if an input argument to a DLD function is
> an integer.
>
> I can check for a real scalar using foo.is_real_scalar(),
>
> What's the analogous way to check if it's an integer?
>
> I hope this is a stupid question!
>
> Michael
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] Release details

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

On Wed, Sep 08, 2004 at 01:30:37AM -0400, Paul Kienzle wrote:
> Hi all,
> 
> I posted RELEASE-NOTES.  Check that I've got everything.
> 
> Quite the effort for the last couple of months!  Lots of work on
> comm and fixed as usual.  Some long standing issues addressed
> in sparse (thanks Andy and David!).  Many extensions to the image
> processing toolbox.  And of course the usual maintenance
> (thanks everybody!).

Somewhat related: what is the current status of the sparse toolbox?
Will the sparse types eventually go into liboctave?  For now, can one
use it in oct files?

Regards
Stefan

[OctDev] check integer type in DLD function?

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

I can't see an easy way to check if an input argument to a DLD function is an 
integer.

I can check for a real scalar using foo.is_real_scalar(),

What's the analogous way to check if it's an integer?

I hope this is a stupid question!

Michael

Re: [OctDev] Release details

[Per P. <per...@ma...>]

On Sep 8, 2004, at 07:30, Paul Kienzle wrote:

> There are issues in the OS X build against 2.1.55 (swap_4_bytes in
> galois and fixed types is causing problems) that I haven't resolved 
> yet,
> but these are not show stoppers.  The same issues in 2.1.58 would
> be cause for concern.  Anyone tried it?

I built 2.1.58 and octave-forge from CVS yesterday on OS X 10.2.8 
without problems. I haven't run any tests other than Fixed which passed 
its self-test.

/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare

Re: [OctDev] Release details

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

According to Paul Kienzle <pki...@us...> (on 09/08/04):
> There are issues in the OS X build against 2.1.55 (swap_4_bytes in
> galois and fixed types is causing problems) that I haven't resolved yet,
> but these are not show stoppers.  The same issues in 2.1.58 would
> be cause for concern.  Anyone tried it?

The use of swap_4_bytes was introduced in R2004-02-12 to allow saving
of binary files.. Does this mean that comm and fixed haven't been building 
on OS X since then? I don't see how octave itself can build in that case
since swap_4_bytes was used in data-conv.cc in octave itself...

If it doesn't work for 2.1.55 there is no fundamental reason it would
work with 2.1.58...

D.

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

[OctDev] Release details

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

Hi all,

I posted RELEASE-NOTES.  Check that I've got everything.

Quite the effort for the last couple of months!  Lots of work on
comm and fixed as usual.  Some long standing issues addressed
in sparse (thanks Andy and David!).  Many extensions to the image
processing toolbox.  And of course the usual maintenance
(thanks everybody!).

Build works fine on Debian 2.1.57 and 2.1.58.

There are a number of test failures that I don't expect.  Could someone
familiar with the following please look into them:

	cmpermute
	qtdecomp
	uintlut
	fzero
	pcr

There are a couple of errors I'm responsible for that I have left in
as a reminder to go back and finish things, namely kaiserord and
princomp.  I'm happy to see that Andy removed all those I put in
for sparse.

There are lots of expected failures in 2.1.57 and below which are
not properly flagged in the tests.  Do we need syntactic support
for version specific tests?

There are issues in the OS X build against 2.1.55 (swap_4_bytes in
galois and fixed types is causing problems) that I haven't resolved yet,
but these are not show stoppers.  The same issues in 2.1.58 would
be cause for concern.  Anyone tried it?

I would appreciate any comments on the status of the Cygwin builds
against 2.1.58.  I'm still stalled on fftw problems I mentioned 
elsewhere.

Thanks,

	- Paul

Re: [OctDev] argument checking in minimization functions

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

Hi again,
All 3 algorithms, bfgsmin, lbfgsmin and samin are written so that the 
parameter with respect to which minimization is done should be a column 
vector. Unfortunately, I don't seem to have explicitly stated that 
anywhere.... Also, type checking doesn't currently go that far. I'll take 
care of it tomorrow. Thanks again - hopefully it'll eventually get harder for 
you to find these :-)

M.


On Tuesday 07 September 2004 13:57, Teemu Ikonen wrote:
> On 07/09/04 11:56, Michael Creel wrote:
> > Forget it please. As is predictable, the error is mine. The CVS versions
> > will be fixed in 10 minutes or so. Thanks for the bug reports, Teemu.
>
> Here's another one. This is with CVS version with your latest fixes:
>
> function chi2=chigl(a, x, y)
>
>   f = a(1).*x.^2 + a(2);
>   chi2 = sum( (y - f).^2);
>
> endfunction
>
> > x = linspace(-5, 5, 10);
> > y = -1.0 .* x.^2;
> > a = zeros(1,2);
> > [aopt, chi2min] = bfgsmin("chigl", {a, x, y, y}, {10,2,1,1});
>
> error: invalid conversion from matrix to real column vector
> octave: /usr/local/include/octave-2.1.58/octave/dim-vector.h:104: int&
> dim_vector::dim_vector_rep::elem(int): Assertion i >= 0 && i < ndims'
> failed. panic: Aborted -- stopping myself...
> attempting to save variables to octave-core'...
> save to octave-core' complete
> Aborted
>
> When the first argument is a column vector, there's no crash.
>
> Teemu
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

Re: [OctDev] argument checking in minimization functions

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

On 07/09/04 11:56, Michael Creel wrote:
> Forget it please. As is predictable, the error is mine. The CVS versions will 
> be fixed in 10 minutes or so. Thanks for the bug reports, Teemu.

Here's another one. This is with CVS version with your latest fixes:

function chi2=chigl(a, x, y)

  f = a(1).*x.^2 + a(2);
  chi2 = sum( (y - f).^2);
    
endfunction
        
> x = linspace(-5, 5, 10);
> y = -1.0 .* x.^2;
> a = zeros(1,2);
> [aopt, chi2min] = bfgsmin("chigl", {a, x, y, y}, {10,2,1,1});
error: invalid conversion from matrix to real column vector
octave: /usr/local/include/octave-2.1.58/octave/dim-vector.h:104: int&
dim_vector::dim_vector_rep::elem(int): Assertion i >= 0 && i < ndims' failed.
panic: Aborted -- stopping myself...
attempting to save variables to octave-core'...
save to octave-core' complete
Aborted

When the first argument is a column vector, there's no crash.

Teemu

Re: [OctDev] argument checking in minimization functions

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

On Tuesday 07 September 2004 11:23, Michael Creel wrote:
> Hello, all,
>
> Teemu Ikonen sent me this bug report:
> > octave:2> bfgsmin_example
> > EXAMPLE 1: Numeric gradientSegmentation fault
> >
> > Teemu
>
> I just verified that this occurs with both Octave 2.1.57 and 2.1.58, using
> octave-forge CVS. But it doesn't occur using the octave-forge .deb package
> for Octave 2.1.57.  I haven't made any changes myself in the minimization
> files, except for the argument checking added yesterday. So before I start
> trying to figure this out, does anyone have ideas as to what the problem
> might be? Thanks, Michael
>

Forget it please. As is predictable, the error is mine. The CVS versions will 
be fixed in 10 minutes or so. Thanks for the bug reports, Teemu.

Re: [OctDev] argument checking in minimization functions

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

Hello, all,
Teemu Ikonen sent me this bug report:
>
> octave:2> bfgsmin_example
> EXAMPLE 1: Numeric gradientSegmentation fault
>
> Teemu

I just verified that this occurs with both Octave 2.1.57 and 2.1.58, using 
octave-forge CVS. But it doesn't occur using the octave-forge .deb package 
for Octave 2.1.57.  I haven't made any changes myself in the minimization 
files, except for the argument checking added yesterday. So before I start 
trying to figure this out, does anyone have ideas as to what the problem 
might be? Thanks, Michael

[OctDev] argument checking in minimization functions

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

I have added full argument checking to all of the .cc functions I contributed 
to main/optim, so the reported crashes should no longer happen. Any other bug 
will be SHELLTOXed when seen...

Michael

Re: [OctDev] quick release

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

According to Michael Creel <mic...@ua...> (on 09/06/04):
> 
> So far I haven't seen use of bfgsmin or the other routines that are documented 
> as being intended for end users cause core dumps, but that's not to say that 
> it can't happen. It's true that Teemu's example for calling newtonstep 
> without arguments dumps core, but as the source code says, newtonstep is not 
> intended for use by end users. For the moment, I'd point people to the 
> documentation in main/optim/doc, but in the medium term I'll try to add 
> proper argument checking to all functions.
> 
> The reason bsgsmin doesn't do bulletproofing internally is because that leads 
> to users minimizing a different function than they think they are, and the 
> end point the algorithm converges to may depend upon the specific 
> implementation. Difficulties in minimization can lead to learning about where 
> the problematic spots are in the function. Different users may like to 
> bulletproof in different ways. The documentation does suggest how 
> bulletproofing might be done, but I'm reluctant to use a one-size-fits-all 
> approach internally to the minimization algorithms.
> 
> Suggestions are welcome, however.
> 
> Michael

Bulletproofing in this case means throwing an error rather than a seg fault.
It doesn't mean using the incorrect constraint function.

D.

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

[OctDev] class reference web page updated

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

http://pareto.uab.es/mcreel/OctaveClassReference/html/index.html

has been updated for version 2.1.58

Michael

Re: [OctDev] quick release

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

On Friday 03 September 2004 16:09, David Bateman wrote:
> If this causes a core-dump, the bulletproofing should be in bfgsmin itself
> rather than in the objective function. Nothing the user can do should cause
> a core-dump, otherwise it is a bug..
>
> D.
>
> According to Michael Creel <mic...@ua...> (on 09/03/04):
> > On Friday 03 September 2004 14:24, Teemu Ikonen wrote:
> > > bfgsmin consistently makes octave dump core on at least one fitting
> > > problem I have. Unfortunately I don't have the time to send a more
> > > detailed bug report just now.
> > >
> > > Teemu
> >

So far I haven't seen use of bfgsmin or the other routines that are documented 
as being intended for end users cause core dumps, but that's not to say that 
it can't happen. It's true that Teemu's example for calling newtonstep 
without arguments dumps core, but as the source code says, newtonstep is not 
intended for use by end users. For the moment, I'd point people to the 
documentation in main/optim/doc, but in the medium term I'll try to add 
proper argument checking to all functions.

The reason bsgsmin doesn't do bulletproofing internally is because that leads 
to users minimizing a different function than they think they are, and the 
end point the algorithm converges to may depend upon the specific 
implementation. Difficulties in minimization can lead to learning about where 
the problematic spots are in the function. Different users may like to 
bulletproof in different ways. The documentation does suggest how 
bulletproofing might be done, but I'm reluctant to use a one-size-fits-all 
approach internally to the minimization algorithms.

Suggestions are welcome, however.

Michael

Re: [OctDev] quick release

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

Hi Teemu and list,

The source code for newtonstep explains that it is for use by bfgsmin (and 
lbfgsmin). As it's an internally used function, it doesn't have proper 
argument checking (which causes the crash you report) and it is poorly 
documented. Right now the "help newtonstep" message doesn't tell you that. 
I'll add the message to the help string, and try to do the same for other 
internal files later. There is a more extensive help document in 
main/optim/doc that explains some of this, e.g., which are the files that are 
expected to be of use to end users.

Thanks for pointing out the problem with the example in the help string - when 
I added the possibility to set tolerances I forgot to update the example. 
Will fix today. 

Michael

On Monday 06 September 2004 10:20, Teemu Ikonen wrote:
> On 03/09/04 14:39, Michael Creel wrote:
> > On Friday 03 September 2004 14:24, Teemu Ikonen wrote:
> > > bfgsmin consistently makes octave dump core on at least one fitting
> > > problem I have. Unfortunately I don't have the time to send a more
> > > detailed bug report just now.
> >
> > I'll be happy to look at it when you have time to send it in. Just
> > guessing,
>
> Ok,
>
> At least this is easy to repeat:
> > octave --no-init-file
>
> [...]
> octave:1> newtonstep
> panic: Segmentation fault -- stopping myself...
> attempting to save variables to octave-core'...
> save to octave-core' complete
> Segmentation fault
>
> This is with recent CVS versions of both Octave and Octave-forge. If nobody
> can repeat this, let me know.
>
> There are also some cosmetic things that need fixing, like the non-working
> example on bfgsmin help, but I'll report more on those later.
>
> Teemu
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev