octave-dev — GNU Octave developers' list

Re: [OctDev] quick release

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

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

Re: [OctDev] griddata / delaunay

[Pedro T. <pt...@te...>]

Sorry I missed the thread from the beginning... out for holidays, you know...

> 1.  Griddata is used for (linear) interpolation and, as such, should
> suffer not at all when using delaunay with the QJ option.  Let's
> implement this, please.  It is a very easy fix, as indicated in my patch
> for griddata.m at the beginning of this thread.

I did contact Brad Barber months ago about this. He didn't recomend it. He 
said it would be better to tell qhull to triangulate the output. This is 
implemented in a function not included in octave-forge that I wrote to have 
better control over qhull. I'll attach it. If you pass a third 'true' 
parameter to the function it will triangulate the output. Maybe all the 
convhull,delaunay and voronoi functions should be just wrapper functions to 
this.

>
> 2.  Segfaults should never occur, but I have found an illustrative case
> where it does with delaunay.  I'll leave this to the experts.

But it does since some of the facets are coplanar and qhull tries to return 
n+1 vertices on an n columns matrix. This is solved in my qhull 
implementation by adding columns to the matrix and filling with 0 indexes 
when there's no vertex (in simplicial facets).

If you want to try qhull function, I send it attached. Just compile with like 
any other geometry package function. delaunayn(X) would be replaced by 
qhull(X,"d",true).


Regards,
Pedro

[OctDev] assert broken for int* uint* types

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

Hi!

I've realized that assert doesn't work with int and uint types. Current
behaviours is as follows:
* It doesn't check if classes are equal
* int* and uint* scalars doesn't work at all (since they don't support
indexing as it's being discussed in Octave maintainers list)
* int* and uint* arrays always return as being equal even if they are
not

I attach a proposed patch against CVS version, although I'm not 100%
sure it's ok.

Regards,
-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] quick release

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

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
> >
> 
> I'll be happy to look at it when you have time to send it in. Just guessing, 
> but if your objective function goes non-numeric, you might get problems. I do 
> something like the following to bullet-proof
> 
> Michael
> 
> 
> # this takes a general model and calculates average log likelihood
> function [obj_value, score] = mle_obj(theta, model, modelargs)
>  [obj_value, score] = feval(model, theta, modelargs);
>  obj_value = - mean(obj_value);
> 
>  # let's bullet-proof this in case the model goes nuts
>  if (((abs(obj_value) == Inf)) || (isnan(obj_value)))
>   obj_value = realmax;
>  endif
> 
>  if isnumeric(score) score = - mean(score)'; endif
> endfunction 
> 
> 
> 
> 
> -------------------------------------------------------
> 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

-- 
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] quick release

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

There's also a bug in histeq, which can be alleviated once the
int classes are in place.

Since we do not have a proper image viewer allowing writebacks,
colourmaps are also a pain.

Regards
Stefan

On Fri, Sep 03, 2004 at 03:27:02PM +0200, Josep Mon?s i Teixidor wrote:

> I also found a bug in imhist... I'll recheck all these things...

Re: [OctDev] quick release

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

Hi!


On dv, 2004-09-03 at 10:21, Stefan van der Walt wrote:
> Josep
>=20
> Since you are at it: if you have a chance, also take a look at the
> other imaging functions.  They should be made to use the uint classes
> too.

ok!

>=20
> imread should return the proper class, in MxNx3 (or 3xMxN, I
> forget).  Class 'double' implies an image in [0,1]; whereas uintx is
> in [0,2^x-1].

M*N*3

>=20
> Regards
> Stefan
>=20


Also isbw must behave as islogical (although MATLAB has deprecated isbw
it's still available).

I also found a bug in imhist... I'll recheck all these things...

Regards,

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

Re: [OctDev] quick release

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

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
>

I'll be happy to look at it when you have time to send it in. Just guessing, 
but if your objective function goes non-numeric, you might get problems. I do 
something like the following to bullet-proof

Michael


# this takes a general model and calculates average log likelihood
function [obj_value, score] = mle_obj(theta, model, modelargs)
 [obj_value, score] = feval(model, theta, modelargs);
 obj_value = - mean(obj_value);

 # let's bullet-proof this in case the model goes nuts
 if (((abs(obj_value) == Inf)) || (isnan(obj_value)))
  obj_value = realmax;
 endif

 if isnumeric(score) score = - mean(score)'; endif
endfunction 

Re: [OctDev] quick release

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

On 02/09/04 08:05, Paul Kienzle wrote:
> Any reason not to do a quick release of octave-forge to support 2.1.58?

Stuff in optim/ seems to be somewhat broken.

minimize() gives me:

error: scalar cannot be indexed with .
error: evaluating assignment expression near line 35, column 5
error: called from getfield' in file
/usr/local/share/octave/2.1.58/site/m/octave-forge/struct/getfield.m'
error: called from minimize' in file
/usr/local/share/octave/2.1.58/site/m/octave-forge/optim/minimize.m'

which is trivially fixed by changing calls to 'getfield' to calls to
'getfields'.

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

Re: [OctDev] quick release

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

Josep

Since you are at it: if you have a chance, also take a look at the
other imaging functions.  They should be made to use the uint classes
too.

imread should return the proper class, in MxNx3 (or 3xMxN, I
forget).  Class 'double' implies an image in [0,1]; whereas uintx is
in [0,2^x-1].

Regards
Stefan

On Thu, Sep 02, 2004 at 04:20:09PM +0200, Josep Mon?s i Teixidor wrote:
> Paul Kienzle wrote:
> 
> >Any reason not to do a quick release of octave-forge to support 2.1.58?
> >
> >Anyone have anything they are working on that they want to get into the
> >next release?
> >
> >- Paul
> >
> 
> It's ok for me... I may modify some of my files to better support uint* 
> and int* stuff though... but they should work ok as they are now though.
> 
> Josep

Re: [OctDev] quick release

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

On Sep 2, 2004, at 9:44 AM, David Bateman wrote:

> Dapr=E8s Paul Kienzle <pki...@us...> (le =
02/09/2004):
>> Any reason not to do a quick release of octave-forge to support=20
>> 2.1.58?
>>
>> Anyone have anything they are working on that they want to get into=20=

>> the
>> next release?
>>
>> - Paul
>
> I have nothing to go in at the moment, so feel free... It might be=20
> better
> waiting a week or so for the release just to be sure that 2.1.58 is=20
> stable
> and there aren't any other things that come along. When the octave=20
> release
> is marked as stable might be the time for the octave-forge release...

Since octave-forge doesn't currently build against 2.1.58, it will be=20
easier
for Dirk (or whoever has volunteered to do Debian releases) to add it
to Debian.

- Paul=

Re: [OctDev] quick release

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

Paul Kienzle wrote:

> Any reason not to do a quick release of octave-forge to support 2.1.58?
>
> Anyone have anything they are working on that they want to get into the
> next release?
>
> - Paul
>

It's ok for me... I may modify some of my files to better support uint* 
and int* stuff though... but they should work ok as they are now though.

Josep

Re: [OctDev] quick release

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

Dapr=E8s Paul Kienzle <pki...@us...> (le 02/09/2004):
> Any reason not to do a quick release of octave-forge to support 2.1.58?
>=20
> Anyone have anything they are working on that they want to get into the
> next release?
>=20
> - Paul

I have nothing to go in at the moment, so feel free... It might be better
waiting a week or so for the release just to be sure that 2.1.58 is stabl=
e
and there aren't any other things that come along. When the octave releas=
e
is marked as stable might be the time for the octave-forge release...

At that point a windows binary might be a great idea too, seeing as how 9=
0%
of our downloads are for the windows binary that is still locked at 2.1.5=
0..

Cheers
David

--=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] quick release

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

Any reason not to do a quick release of octave-forge to support 2.1.58?

Anyone have anything they are working on that they want to get into the
next release?

- Paul

Re: [OctDev] griddata / delaunay

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

According to Jonathan Stickel <jjs...@sb...> (on 09/02/04):
> OK, I see there has already been quite a bit of discussion and effort 
> regarding the qhull based functions.  I still have 2 issues:
> 
> 1.  Griddata is used for (linear) interpolation and, as such, should 
> suffer not at all when using delaunay with the QJ option.  Let's 
> implement this, please.  It is a very easy fix, as indicated in my patch 
> for griddata.m at the beginning of this thread.

I leave this point to someone who knows more..

> 2.  Segfaults should never occur, but I have found an illustrative case 
> where it does with delaunay.  I'll leave this to the experts.

Here I have to agree, qhull should not be allowed to crash octave. If you
implement the fix I suggested, I'll commit it... I started to do it then
couldn't be bothered since I'd also have to check for the case of 
NEED_OCTAVE_QUIT and manually define something for the macros 
BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE, as well as the function
octave_throw_interrupt_exception.... Just defining them to nothing 
is probably an option...

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] griddata / delaunay

[Jonathan S. <jjs...@sb...>]

OK, I see there has already been quite a bit of discussion and effort 
regarding the qhull based functions.  I still have 2 issues:

1.  Griddata is used for (linear) interpolation and, as such, should 
suffer not at all when using delaunay with the QJ option.  Let's 
implement this, please.  It is a very easy fix, as indicated in my patch 
for griddata.m at the beginning of this thread.

2.  Segfaults should never occur, but I have found an illustrative case 
where it does with delaunay.  I'll leave this to the experts.

Thanks,
Jonathan


Paul Kienzle wrote:
> See comments at:
> 
> http://www.octave.org/octave-lists/archive/help-octave.2003/ msg02420.html
> 
> and links therein.
> 
> - Paul
> 
> On Sep 1, 2004, at 7:09 PM, Jonathan Stickel wrote:
> 
>> Seems like a good solution to me.
>>
>> I'm rather new to open source development...  How do changes 
>> generally  get committed to octave-forge?  Should I submit a patch for 
>> delaunay  to this list?  Will someone then review and commit it?
>>
>> BTW:  I just started working with delaunay recently because griddata  
>> was giving me trouble.  I really don't know much about the other  
>> functions that use qhull, so I'd rather leave them alone right now.
>>
>> Thanks,
>> Jonathan
>>
>>
>> David Bateman wrote:
>>
>>> I'm not a user of delaunay and so you know better. I just proposed a  
>>> generic fix that should be applied wherever foreign code is used with
>>> octave to prevent just this type of problem. If the "QJ" to qhull is
>>> such a generic solution, why not just make the default for OPT in
>>> delaunay (and elsewhere?) be "QJ" with something like
>>>  if (nargin == 2)
>>>    opt = "QJ";
>>>  endif
>>> and be done with it. This combined with the previous fix, should be
>>> sufficient..
>>> D.

Re: [OctDev] griddata / delaunay

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

See comments at:

http://www.octave.org/octave-lists/archive/help-octave.2003/ 
msg02420.html

and links therein.

- Paul

On Sep 1, 2004, at 7:09 PM, Jonathan Stickel wrote:

> Seems like a good solution to me.
>
> I'm rather new to open source development...  How do changes generally  
> get committed to octave-forge?  Should I submit a patch for delaunay  
> to this list?  Will someone then review and commit it?
>
> BTW:  I just started working with delaunay recently because griddata  
> was giving me trouble.  I really don't know much about the other  
> functions that use qhull, so I'd rather leave them alone right now.
>
> Thanks,
> Jonathan
>
>
> David Bateman wrote:
>> I'm not a user of delaunay and so you know better. I just proposed a  
>> generic fix that should be applied wherever foreign code is used with
>> octave to prevent just this type of problem. If the "QJ" to qhull is
>> such a generic solution, why not just make the default for OPT in
>> delaunay (and elsewhere?) be "QJ" with something like
>>  if (nargin == 2)
>>    opt = "QJ";
>>  endif
>> and be done with it. This combined with the previous fix, should be
>> sufficient..
>> D.
>> According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
>>> David Bateman wrote:
>>>
>>>> According to Jonathan Stickel <jjs...@sb...> (on  
>>>> 09/01/04):
>>>>
>>>>
>>>>> I have encountered a problem with griddata when using semi-regular  
>>>>> input points.  The issue has to do with facet merging when running  
>>>>> delaunay, via qhull, with defualt options.  To avoid this,  
>>>>> delaunay should be run with the "QJ" option.  Perhaps this should  
>>>>> be mentioned explicitly in the delaunay help.  For the worst case  
>>>>> of a rectangular grid, a segmentation fault occcurs:
>>>>>
>>>>> octave:1> [x,y]=meshgrid(1:10,1:10);
>>>>> octave:2> delaunay(x(:),y(:),"QJ")
>>>>> (plot of triangles)
>>>>> octave:3> delaunay(x(:),y(:))
>>>>> panic: Segmentation fault -- stopping myself...
>>>>> attempting to save variables to `octave-core'...
>>>>> save to `octave-core' complete
>>>>> Segmentation fault
>>>>>
>>>>> Attached is a patch for griddata which calls delaunay with the  
>>>>> "QJ" option.
>>>>
>>>>
>>>> Not sure if this is the right approach. What is the real reason for  
>>>> the
>>>> seg fault. If it is in the underlying qhull code, it might be  
>>>> better to
>>>> surround the calls to the qhull stuff with
>>>>
>>>>     BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1;
>>>>
>>>>     error ("delaunay: Internal qhull error. Please try the 'QJ'      
>>>> option.");
>>>>     octave_throw_interrupt_exception ();
>>>>
>>>>     BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2;
>>>>
>>>>     <QHULL CODE HERE>
>>>>
>>>>     END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
>>>>
>>>> and inform the author of qhull of the problem within their code. At  
>>>> least
>>>> this way octave won't crash for qhulls problems....
>>>>
>>>
>>> I agree.  I do believe that qhull is the real cause of the example  
>>> segfault, and octave functions should catch the problem like you  
>>> suggest.  However, for other semi-regular grids, delaunay does not  
>>> always segfault but will "drop points" when used without the QJ  
>>> option.  I can provide an example if you like. I think this should  
>>> be mentioned in the help for qhull based functions.
>>>
>>> Please don't overlook my specific solution for griddata.  Griddata  
>>> does not currently take arguments to pass to qhull.  This could be  
>>> added, of course, but I see no reason not to always use the QJ  
>>> option for delaunay within griddata.
>>>
>>> Jonathan
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>
>
> -------------------------------------------------------
> 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] griddata / delaunay

[Jonathan S. <jjs...@sb...>]

Seems like a good solution to me.

I'm rather new to open source development...  How do changes generally 
get committed to octave-forge?  Should I submit a patch for delaunay to 
this list?  Will someone then review and commit it?

BTW:  I just started working with delaunay recently because griddata was 
giving me trouble.  I really don't know much about the other functions 
that use qhull, so I'd rather leave them alone right now.

Thanks,
Jonathan


David Bateman wrote:
> I'm not a user of delaunay and so you know better. I just proposed a 
> generic fix that should be applied wherever foreign code is used with
> octave to prevent just this type of problem. If the "QJ" to qhull is
> such a generic solution, why not just make the default for OPT in
> delaunay (and elsewhere?) be "QJ" with something like
> 
>  if (nargin == 2)
>    opt = "QJ";
>  endif
> 
> and be done with it. This combined with the previous fix, should be
> sufficient..
> 
> D.
> 
> 
> According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
> 
>>David Bateman wrote:
>>
>>>According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
>>>
>>>
>>>>I have encountered a problem with griddata when using semi-regular input 
>>>>points.  The issue has to do with facet merging when running delaunay, 
>>>>via qhull, with defualt options.  To avoid this, delaunay should be run 
>>>>with the "QJ" option.  Perhaps this should be mentioned explicitly in 
>>>>the delaunay help.  For the worst case of a rectangular grid, a 
>>>>segmentation fault occcurs:
>>>>
>>>>octave:1> [x,y]=meshgrid(1:10,1:10);
>>>>octave:2> delaunay(x(:),y(:),"QJ")
>>>>(plot of triangles)
>>>>octave:3> delaunay(x(:),y(:))
>>>>panic: Segmentation fault -- stopping myself...
>>>>attempting to save variables to `octave-core'...
>>>>save to `octave-core' complete
>>>>Segmentation fault
>>>>
>>>>Attached is a patch for griddata which calls delaunay with the "QJ" 
>>>>option.
>>>
>>>
>>>Not sure if this is the right approach. What is the real reason for the
>>>seg fault. If it is in the underlying qhull code, it might be better to
>>>surround the calls to the qhull stuff with
>>>
>>>     BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1;
>>>
>>>     error ("delaunay: Internal qhull error. Please try the 'QJ' 
>>>     option.");
>>>     octave_throw_interrupt_exception ();
>>>
>>>     BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2;
>>>
>>>     <QHULL CODE HERE>
>>>
>>>     END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
>>>
>>>and inform the author of qhull of the problem within their code. At least
>>>this way octave won't crash for qhulls problems....
>>>
>>
>>I agree.  I do believe that qhull is the real cause of the example 
>>segfault, and octave functions should catch the problem like you 
>>suggest.  However, for other semi-regular grids, delaunay does not 
>>always segfault but will "drop points" when used without the QJ option. 
>>  I can provide an example if you like. I think this should be 
>>mentioned in the help for qhull based functions.
>>
>>Please don't overlook my specific solution for griddata.  Griddata does 
>>not currently take arguments to pass to qhull.  This could be added, of 
>>course, but I see no reason not to always use the QJ option for delaunay 
>>within griddata.
>>
>>Jonathan
>>
>>
>>-------------------------------------------------------
>>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] imadjust recoded

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

On dc, 2004-08-25 at 19:23, Josep Mon=E9s i Teixidor wrote:
> Hello Kai and list,
[....]
>=20
> Since I've only keeped 3 lines of code, I've copyrighted it to me and
> inluded a reference to old code and original copyright. If you feel this
> is wrong or impolite please tell me.
>=20
> If someone could check if behaviour is ok it would be great. I attach
> the m-file.... I'll commit it if you agree.
>=20
[....]


Since I've received no response, I'll commit it. I someone (specially
Kai) believes it's not ok please tell me.

Regards,
--=20
Josep Mon=E9s i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

Re: [OctDev] griddata / delaunay

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

I'm not a user of delaunay and so you know better. I just proposed a 
generic fix that should be applied wherever foreign code is used with
octave to prevent just this type of problem. If the "QJ" to qhull is
such a generic solution, why not just make the default for OPT in
delaunay (and elsewhere?) be "QJ" with something like

 if (nargin == 2)
   opt = "QJ";
 endif

and be done with it. This combined with the previous fix, should be
sufficient..

D.


According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
> David Bateman wrote:
> >According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
> >
> >>I have encountered a problem with griddata when using semi-regular input 
> >>points.  The issue has to do with facet merging when running delaunay, 
> >>via qhull, with defualt options.  To avoid this, delaunay should be run 
> >>with the "QJ" option.  Perhaps this should be mentioned explicitly in 
> >>the delaunay help.  For the worst case of a rectangular grid, a 
> >>segmentation fault occcurs:
> >>
> >>octave:1> [x,y]=meshgrid(1:10,1:10);
> >>octave:2> delaunay(x(:),y(:),"QJ")
> >>(plot of triangles)
> >>octave:3> delaunay(x(:),y(:))
> >>panic: Segmentation fault -- stopping myself...
> >>attempting to save variables to `octave-core'...
> >>save to `octave-core' complete
> >>Segmentation fault
> >>
> >>Attached is a patch for griddata which calls delaunay with the "QJ" 
> >>option.
> >
> >
> >Not sure if this is the right approach. What is the real reason for the
> >seg fault. If it is in the underlying qhull code, it might be better to
> >surround the calls to the qhull stuff with
> >
> >      BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1;
> >
> >      error ("delaunay: Internal qhull error. Please try the 'QJ' 
> >      option.");
> >      octave_throw_interrupt_exception ();
> >
> >      BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2;
> >
> >      <QHULL CODE HERE>
> >
> >      END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
> >
> >and inform the author of qhull of the problem within their code. At least
> >this way octave won't crash for qhulls problems....
> >
> 
> I agree.  I do believe that qhull is the real cause of the example 
> segfault, and octave functions should catch the problem like you 
> suggest.  However, for other semi-regular grids, delaunay does not 
> always segfault but will "drop points" when used without the QJ option. 
>   I can provide an example if you like. I think this should be 
> mentioned in the help for qhull based functions.
> 
> Please don't overlook my specific solution for griddata.  Griddata does 
> not currently take arguments to pass to qhull.  This could be added, of 
> course, but I see no reason not to always use the QJ option for delaunay 
> within griddata.
> 
> Jonathan
> 
> 
> -------------------------------------------------------
> 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

-- 
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] griddata / delaunay

[Jonathan S. <jjs...@sb...>]

David Bateman wrote:
> According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
> 
>>I have encountered a problem with griddata when using semi-regular input 
>>points.  The issue has to do with facet merging when running delaunay, 
>>via qhull, with defualt options.  To avoid this, delaunay should be run 
>>with the "QJ" option.  Perhaps this should be mentioned explicitly in 
>>the delaunay help.  For the worst case of a rectangular grid, a 
>>segmentation fault occcurs:
>>
>>octave:1> [x,y]=meshgrid(1:10,1:10);
>>octave:2> delaunay(x(:),y(:),"QJ")
>>(plot of triangles)
>>octave:3> delaunay(x(:),y(:))
>>panic: Segmentation fault -- stopping myself...
>>attempting to save variables to `octave-core'...
>>save to `octave-core' complete
>>Segmentation fault
>>
>>Attached is a patch for griddata which calls delaunay with the "QJ" option.
> 
> 
> Not sure if this is the right approach. What is the real reason for the
> seg fault. If it is in the underlying qhull code, it might be better to
> surround the calls to the qhull stuff with
> 
>       BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1;
> 
>       error ("delaunay: Internal qhull error. Please try the 'QJ' option.");
>       octave_throw_interrupt_exception ();
> 
>       BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2;
> 
>       <QHULL CODE HERE>
> 
>       END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
> 
> and inform the author of qhull of the problem within their code. At least
> this way octave won't crash for qhulls problems....
> 

I agree.  I do believe that qhull is the real cause of the example 
segfault, and octave functions should catch the problem like you 
suggest.  However, for other semi-regular grids, delaunay does not 
always segfault but will "drop points" when used without the QJ option. 
   I can provide an example if you like. I think this should be 
mentioned in the help for qhull based functions.

Please don't overlook my specific solution for griddata.  Griddata does 
not currently take arguments to pass to qhull.  This could be added, of 
course, but I see no reason not to always use the QJ option for delaunay 
within griddata.

Jonathan

Re: [OctDev] griddata / delaunay

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

According to Jonathan Stickel <jjs...@sb...> (on 09/01/04):
> I have encountered a problem with griddata when using semi-regular input 
> points.  The issue has to do with facet merging when running delaunay, 
> via qhull, with defualt options.  To avoid this, delaunay should be run 
> with the "QJ" option.  Perhaps this should be mentioned explicitly in 
> the delaunay help.  For the worst case of a rectangular grid, a 
> segmentation fault occcurs:
> 
> octave:1> [x,y]=meshgrid(1:10,1:10);
> octave:2> delaunay(x(:),y(:),"QJ")
> (plot of triangles)
> octave:3> delaunay(x(:),y(:))
> panic: Segmentation fault -- stopping myself...
> attempting to save variables to `octave-core'...
> save to `octave-core' complete
> Segmentation fault
> 
> Attached is a patch for griddata which calls delaunay with the "QJ" option.

Not sure if this is the right approach. What is the real reason for the
seg fault. If it is in the underlying qhull code, it might be better to
surround the calls to the qhull stuff with

      BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_1;

      error ("delaunay: Internal qhull error. Please try the 'QJ' option.");
      octave_throw_interrupt_exception ();

      BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE_2;

      <QHULL CODE HERE>

      END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;

and inform the author of qhull of the problem within their code. At least
this way octave won't crash for qhulls problems....

D.


> 
> Regards,
> Jonathan


-- 
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] griddata / delaunay

[Jonathan S. <jjs...@sb...>]

I have encountered a problem with griddata when using semi-regular input 
points.  The issue has to do with facet merging when running delaunay, 
via qhull, with defualt options.  To avoid this, delaunay should be run 
with the "QJ" option.  Perhaps this should be mentioned explicitly in 
the delaunay help.  For the worst case of a rectangular grid, a 
segmentation fault occcurs:

octave:1> [x,y]=meshgrid(1:10,1:10);
octave:2> delaunay(x(:),y(:),"QJ")
(plot of triangles)
octave:3> delaunay(x(:),y(:))
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault

Attached is a patch for griddata which calls delaunay with the "QJ" option.

Regards,
Jonathan

[OctDev] octave-forge build failure on FreeBSD

[Joan P. <li...@bi...>]

[please honour MFT:, not subscribed; Cc:'ed mantainer]

Hi,

I can't build octave-forge on FreeBSD. I've tried the version from ports
(2004.02.12) and the latest (2004.07.07). I've also tried gcc33 from
freebsd ports.

501,p1,0$ uname -a
FreeBSD calvin.biaix.org 5.3-BETA2 FreeBSD 5.3-BETA2 #1: Mon Aug 30
11:06:55 CEST 2004     jo...@ca...:/mnt/obj/usr/src/sys/CALVIN
i386

501,p3,0$ gcc --version
gcc (GCC) 3.4.2 [FreeBSD] 20040728

The version from ports (2004.02.12) fails like:

===>  Building for octave-forge-2004.02.12
cd FIXES/ && gmake
gmake[1]: Entering directory
`/mnt/build/ports/fs/bulk/mount/FreeBSD/ports/math/octave-forge/work/octave-forge-2004.02.12/FIXES'
mkoctfile -DHAVE_OCTAVE_21 -v -DHAVE_IEEE754_COMPLIANCE sort.cc
c++ -c -I/usr/local/include -fPIC -I/usr/local/include/octave-2.1.57
-I/usr/local/include/octave-2.1.57/octave -I/usr/local/include -mieee-fp
-g -O -pipe -march=athlon-mp -DHAVE_OCTAVE_21 -DHAVE_IEEE754_COMPLIANCE
sort.cc -o sort.o
sort.cc:90: error: expected unqualified-id before ';' token
sort.cc:91: error: expected unqualified-id before ';' token
sort.cc:127: error: expected unqualified-id before ';' token
gmake[1]: *** [sort.oct] Error 1
gmake[1]: Leaving directory
`/mnt/build/ports/fs/bulk/mount/FreeBSD/ports/math/octave-forge/work/octave-forge-2004.02.12/FIXES'
gmake: *** [FIXES/] Error 2
*** Error code 2

Stop in /fs/bulk/mount/FreeBSD/ports/math/octave-forge.

And the latest version fails with:

c++ -c -I/usr/local/include -fPIC -I/usr/local/include/octave-2.1.57
-I/usr/local/include/octave-2.1.57/octave -I/usr/local/include -mieee-fp
-g -O -pipe -march=athlon-mp -DHAVE_OCTAVE_21 -DUSE_TERM -DHAVE_TERM_H
-DTYPEID_HAS_CLASS dispatch.cc -o dispatch.o
dispatch.cc:543: error: expected unqualified-id before ';
ke[2]: *** [dispatch.oct] Error 1
rm -f dispatch_help.oct

(see the attached build.log). The old
version also has the dispatch.cc error.

Any chance to fix it before the ports tree freeze?

tks
-- 
pica

[OctDev] imadjust recoded

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

Hello Kai and list,

Now that we have ND arrays, I began updating imadjust.m to add RGB
images and a few things more, but I ended up recoding it all. 

Behaviour has been modified as follows:
* Interface is now compatible with MATLAB docs
* RGB support has been added
* docs have been rewritten
* tests added
* now limits can be different for each plane in RGB or each color in a
colormap (using 1-by-3 arrays)

Since I've only keeped 3 lines of code, I've copyrighted it to me and
inluded a reference to old code and original copyright. If you feel this
is wrong or impolite please tell me.

If someone could check if behaviour is ok it would be great. I attach
the m-file.... I'll commit it if you agree.

The docs:
 -- Function File: J = imadjust (I)
 -- Function File: J = imadjust (I,[LOW_IN;HIGH_IN])
 -- Function File: J = imadjust (I,[LOW_IN;HIGH_IN],[LOW_OUT;HIGH_OUT])
 -- Function File: J = imadjust (..., GAMMA)
 -- Function File: NEWMAP = imadjust (MAP, ...)
 -- Function File: RGB_OUT = imadjust (RGB, ...)
     Adjust image or colormap values to a specified range

     `J=imadjust(I)' adjusts intensity image I values so that 1% of
     data on lower and higher values (2% in total) of the image is
     saturated; choosing for that the corresponding lower and higher
     bounds (using `stretchlim') and mapping them to 0 and 1. J is an
     image of the same size as I which contains mapped values.  This is
     equivalent to `imadjust(I,stretchlim(I))'.

     `J=imadjust(I,[low_in;high_in])' behaves as described but uses
     LOW_IN and HIGH_IN values instead of calculating them. It maps
     those values to 0 and 1; saturates values lower than first limit
     to 0 and values higher than second to 1; and finally maps all
     values between limits linearly to a value between 0 and 1. If `[]'
     is passes as `[low_in;high_in]' value, then `[0;1]' is taken as a
     default value.

     `J=imadjust(I,[low_in;high_in],[low_out;high_out])' behaves as
     described but maps output values between LOW_OUT and HIGH_OUT
     instead of 0 and 1. A default value `[]' can also be used for this
     parameter, which is taken as `[0;1]'.

     `J=imadjust(...,gamma)' takes, in addition of 3 parameters
     explained above, an extra parameter GAMMA, which specifies the
     shape of the mapping curve between input elements and output
     elements, which is linear (as taken if this parameter is omitted).
     If GAMMA is above 1, then function is weighted towards lower
     values, and if below 1, towards higher values.

     `newmap=imadjust(map,...)' applies a transformation to a colormap
     MAP, which output is NEWMAP. This transformation is the same as
     explained above, just using a map instead of an image.  LOW_IN,
     HIGH_IN, LOW_OUT, HIGH_OUT and GAMMA can be scalars, in which case
     the same values are applied for all three color components of a
     map; or it can be 1-by-3 vectors, to define unique mappings for
     each component.

    `RGB_out=imadjust(RGB,...)' adjust RGB image RGB (a M-by-N-by-3
     array) the same way as specified in images and colormaps.  Here
     too LOW_IN, HIGH_IN, LOW_OUT, HIGH_OUT and GAMMA can be scalars or
     1-by-3 matrices, to specify the same mapping for all planes, or
     unique mappings for each.

     The formula used to realize the mapping (if we omit saturation) is:

     `J = low_out + (high_out - low_out) .* ((I - low_in) / (high_in -
     low_in)) .^ gamma;'

     *Compatibility notes:*

        * Prior versions of imadjust allowed `[low_in; high_in]' and
          `[low_out; high_out]' to be row vectors. Compatibility with
          this behaviour has been keeped, although preferred form is
          vertical vector (since it extends nicely to 2-by-3 matrices
          for RGB images and colormaps).

       * Previous version of imadjust, if `low_in>high_in' it
          "negated" output.  Now it is negated if `low_out>high_out',
          for compatibility with MATLAB.

        * Class of I is not considered, so limit values are not
          modified depending on class of the image, just treated "as
          is". When Octave 2.1.58 is out, limits will be multiplied by
          255 for uint8 images and by 65535 for uint16 as in MATLAB.

   See also: stretchlim, brighten.



Regards,

-- 
Josep Monés i Teixidor
Clau GnuPG: gpg --recv-keys 80E85CC4

[OctDev] Problem with the wiki

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

I figured out why we haven't had any spam on the wiki recently. Because
editing of the pages is broken :-)...

I get the message

Software error:

>< Could not get main lock "/home/etienne/public_html/octave-wiki/temp/lock" at
+/home/etienne/public_html/cgi-bin-etienne/wiki.pl line 3311.

For help, please send mail to the webmaster (sys...@is...), giving
+this error message and the time and date of the error.

when I try to save an edited page...

Cheers
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