octave-dev — GNU Octave developers' list

Re: [OctDev] Patches for octave-forge to compile against octave-2.1.53

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

I think Paul has just fixed these in the CVS. In any case your fix for
listen.cc will break compatiability with versions early than
2.1.52 as the buffer_error_messages is boolean in these cases....

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

[OctDev] Patches for octave-forge to compile against octave-2.1.53

[Ole J. H. <wat...@ya...>]

Hi. 

Here is a patch for listen.cc in main/miscellaneous/listen.cc, and extra/mex/mex.cc using cvs diff. 

It compiled to me using these fixes. ;-)

Cheers 

Ole J.  

Index: mex.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/extra/mex/mex.cc,v
retrieving revision 1.13
diff -r1.13 mex.cc
376a377
> #if HAVE_MAP_IDX_OP
377a379,381
> #else
>     return __mex->make_value((*pmap).contents(key)(index));
> #endif
383c387,393
<     if (pmap) (*pmap)[key](index) = value->as_octave_value();
---
>     if (pmap)
> #if HAVE_MAP_IDX_OP
>       (*pmap)[key](index) = value->as_octave_value();
> #else
>        (*pmap).contents(key)(index) = value->as_octave_value();
> #endif
>
551c561
<   for (int i=1; i < keys.length(); i++) pmap->assign(keys[i],empty);
---
>   for (int i=1; i < keys.length(); i++) pmap->assign(keys[i],octave_value(empty));


Index: listen.cc

===================================================================
RCS file: /cvsroot/octave/octave-forge/main/miscellaneous/listen.cc,v
retrieving revision 1.14
diff -r1.14 listen.cc
331c331
<           bind_global_error_variable();
---
>           //bind_global_error_variable();
347c347
<           clear_global_error_variable(NULL);
---
>           //clear_global_error_variable(NULL);
564,565c564,565
<   unwind_protect_bool (buffer_error_messages);
<   buffer_error_messages = true;
---
>   unwind_protect::save_int(&buffer_error_messages, true);
>   //  buffer_error_messages = true;

Re: [OctDev] Build problems for octave-forge with 2.1.53

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

The mex problem should be fixed now in CVS.
My fix for listen compiles, but I haven't yet tested it or uploaded it.

There are still numerous tests failing, but that's because I'm testing
things that haven't been implemented yet.

Paul Kienzle
pki...@us...

On Jan 26, 2004, at 8:16 AM, David Bateman wrote:

> Here are the list of build problems I have with octave-forge CVS at the
> moment.
>
> extra/mex/mex.cc
>
> main/miscellaneous/listen.cc

[OctDev] nargin changes

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

Since nargin is now a function, I've removed all usage that
treats it like a variable.

The following directories have changes:

	extra/{graceplot,tk_octave}
	main/{vrml,struct,plot,path,miscellaneous}

I have not done any testing of the changes since they were
semi-mechanical and since I checked them over twice.
I'll probably regret that soon ...

Paul Kienzle
pki...@us...

Re: [OctDev] Build problems for octave-forge with 2.1.53

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

Yes, two of my functions are breaking.  I'll certainly fix listen() 
before the
next release.  I may choose to comment out structure support for mex
files, though, since it never worked properly anyway (I was getting 
segfaults
when returning structures, but receiving structures seemed to work
okay).

Paul Kienzle
pki...@us...

On Jan 26, 2004, at 8:16 AM, David Bateman wrote:

> Here are the list of build problems I have with octave-forge CVS at the
> moment.
>
> extra/mex/mex.cc
> ----------------
>
> mex.cc: In member function `mxArray* mxArray::field(const 
> std::string&, int) const':
> mex.cc:377: error: no match for 'operator[]' in 
> '*this->mxArray::pmap[key]'
> mex.cc: In member function `void mxArray::field(const std::string&, 
> int, mxArray*)':
> mex.cc:383: error: no match for 'operator[]' in 
> '*this->mxArray::pmap[key]'
> mex.cc: In member function `mxArray* mex::make_value(int, int, const 
> string_vector&)':
> mex.cc:551: error: call of overloaded `assign(std::string, 
> octave_value_list&)' is ambiguous
> /opt/octave-2.1.53/include/octave-2.1.53/octave/oct-map.h:123: error: 
> candidates are: Octave_map& Octave_map::assign(const std::string&, 
> const octave_value&)
> /opt/octave-2.1.53/include/octave-2.1.53/octave/oct-map.h:125: error:  
>                Octave_map& Octave_map::assign(const std::string&, 
> const Cell&)
> make: *** [mex.o] Error 1
>
> This appears is not that clear to me how to fix this, especially the 
> last
> error, the first two will need a change like
>
> #if HAVE_MAP_IDX_OP
>       return __mex->make_value((*pmap)[key](index));
> #else
>       return __mex->make_value((*pmap).contents(key)(index));
> #endif
>
> with the appropriate logic to select the right version in 
> configure.add.
> This is ugly as it introduces cruft for backwards compatiability.
>
> However, the last error is a pain as this function appears to have
> been deleted and replaced with different versions. Its not clear to
> me how to fix this for 2.1.53.
>
>
> main/miscellaneous/listen.cc
> ----------------------------
>
> listen.cc: In function `void process_commands(int)':
> listen.cc:331: error: `bind_global_error_variable' undeclared (first 
> use this function)
> listen.cc:331: error: (Each undeclared identifier is reported only 
> once for each function it appears in.)
> listen.cc:347: error: `clear_global_error_variable' undeclared (first 
> use this function)
> listen.cc: In function `octave_value_list Flisten(const 
> octave_value_list&, int)':
> listen.cc:564: error: no matching function for call to 
> `unwind_protect::save_bool(int*, int&)'
> /opt/octave-2.1.53/include/octave-2.1.53/octave/unwind-prot.h:103: 
> error: candidates are: static void unwind_protect::save_bool(bool*, 
> bool)
> make: *** [listen.o] Error 1
>
> The functions bind_global_error_variable and 
> clear_global_error_variable
> have been deleted, and __error_text__ must be manipulated directly. 
> The last
> error is due to the fact that buffer_error_messages is now type int, 
> and
> so the incorrect unwind_protect function was called. This seems that 
> it will
> also require a configuration variabkle to select between versions.
>
> Again, I'm not quite sure of the fix as I don't use this code. 
> However, as
> these two functions don't build with 2.1.53, they should be fixed 
> prior to
> an octave-forge release....
>
> 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
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Re: [OctDev] new material in main/optim

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

  Hi Michael,

if the new BFGSMin does a better job, maybe it can replace the old one
altogether. It would be nice to have the same calling arguments, which
seems to be the case at a first glance.

  Cheers,

  Etienne

PS : Maybe there's a prob w/ my tabs, but some lines appear w/ over
     100 columns in emacs.

On Mon, Jan 26, 2004 at 11:55:14AM +0100, Michael Creel wrote:
# Hello all,
# I have added some files for optimization into main/optim, in the subdirectory 
# "Optimize". I created a new subdirectory, since the files have some 
# interdependencies between themselves, and the set of necessary files wouldn't 
# be clear if they were put directly into optim.
# 
# The BFGSMin.m routine, the file of central interest, is much like bfgs.m in 
# optim, but, in my experiece, it is more efficient and robust, since the line 
# search for the stepsize has been re-worked quite a bit. It has been tested 
# quite extensively. It also has a somewhat different interface that makes use 
# of cell arrays. Thus, it doesn't require "leval" and will not generate 
# warnings with Octave > 2.1.50. The Optimize package has no dependencies on 
# octave-forge - it will work with plain Octave 2.1.x.
# 
# Any comments appreciated. Please leave the flamethrowers on low if I've make 
# any errors with CVS - it's the first time I attempt a commit. Michael
# 
# 
# 
# -------------------------------------------------------
# The SF.Net email is sponsored by EclipseCon 2004
# Premiere Conference on Open Tools Development and Integration
# See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
# http://www.eclipsecon.org/osdn
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

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

[OctDev] Build problems for octave-forge with 2.1.53

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

Here are the list of build problems I have with octave-forge CVS at the
moment.

extra/mex/mex.cc
----------------

mex.cc: In member function `mxArray* mxArray::field(const std::string&, int) const':
mex.cc:377: error: no match for 'operator[]' in '*this->mxArray::pmap[key]'
mex.cc: In member function `void mxArray::field(const std::string&, int, mxArray*)':
mex.cc:383: error: no match for 'operator[]' in '*this->mxArray::pmap[key]'
mex.cc: In member function `mxArray* mex::make_value(int, int, const string_vector&)':
mex.cc:551: error: call of overloaded `assign(std::string, octave_value_list&)' is ambiguous
/opt/octave-2.1.53/include/octave-2.1.53/octave/oct-map.h:123: error: candidates are: Octave_map& Octave_map::assign(const std::string&, const octave_value&)
/opt/octave-2.1.53/include/octave-2.1.53/octave/oct-map.h:125: error:                 Octave_map& Octave_map::assign(const std::string&, const Cell&)
make: *** [mex.o] Error 1

This appears is not that clear to me how to fix this, especially the last
error, the first two will need a change like

#if HAVE_MAP_IDX_OP
      return __mex->make_value((*pmap)[key](index));
#else
      return __mex->make_value((*pmap).contents(key)(index));
#endif

with the appropriate logic to select the right version in configure.add.
This is ugly as it introduces cruft for backwards compatiability.

However, the last error is a pain as this function appears to have
been deleted and replaced with different versions. Its not clear to
me how to fix this for 2.1.53.


main/miscellaneous/listen.cc
----------------------------

listen.cc: In function `void process_commands(int)':
listen.cc:331: error: `bind_global_error_variable' undeclared (first use this function)
listen.cc:331: error: (Each undeclared identifier is reported only once for each function it appears in.)
listen.cc:347: error: `clear_global_error_variable' undeclared (first use this function)
listen.cc: In function `octave_value_list Flisten(const octave_value_list&, int)':
listen.cc:564: error: no matching function for call to `unwind_protect::save_bool(int*, int&)'
/opt/octave-2.1.53/include/octave-2.1.53/octave/unwind-prot.h:103: error: candidates are: static void unwind_protect::save_bool(bool*, bool)
make: *** [listen.o] Error 1

The functions bind_global_error_variable and clear_global_error_variable 
have been deleted, and __error_text__ must be manipulated directly. The last
error is due to the fact that buffer_error_messages is now type int, and
so the incorrect unwind_protect function was called. This seems that it will
also require a configuration variabkle to select between versions.

Again, I'm not quite sure of the fix as I don't use this code. However, as
these two functions don't build with 2.1.53, they should be fixed prior to
an octave-forge release....

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

[OctDev] new material in main/optim

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

Hello all,
I have added some files for optimization into main/optim, in the subdirectory 
"Optimize". I created a new subdirectory, since the files have some 
interdependencies between themselves, and the set of necessary files wouldn't 
be clear if they were put directly into optim.

The BFGSMin.m routine, the file of central interest, is much like bfgs.m in 
optim, but, in my experiece, it is more efficient and robust, since the line 
search for the stepsize has been re-worked quite a bit. It has been tested 
quite extensively. It also has a somewhat different interface that makes use 
of cell arrays. Thus, it doesn't require "leval" and will not generate 
warnings with Octave > 2.1.50. The Optimize package has no dependencies on 
octave-forge - it will work with plain Octave 2.1.x.

Any comments appreciated. Please leave the flamethrowers on low if I've make 
any errors with CVS - it's the first time I attempt a commit. Michael

Re: [OctDev] Release this weekend

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

According to Paul Kienzle <pki...@us...> (on 01/23/04):
> Yeah I noticed.  Let me know when everything is updated.

Ok, my stuff is in....

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

Re: [OctDev] Automatic CVS activity notification

[Rafael L. <rla...@us...>]

* Rafael Laboissiere <rla...@us...> [2004-01-24 16:12]:

> I noticed that since the last changes in the CVS server at SourceForge the
> automatic cvs commit messages are not being sent to the octave-cvsupdate
> mailing list.  I suspect that this problem is related to the change of the
> mailhost in the CVS server, as documented in:
> 
>     http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1
> 
> As soon as the CVS server will be working again, I will change
> CVSROOT/loginfo to use the SF-recommended script syncmail instead of our
> home-made CVSROOT/dncvspipe.  For details, see:
> 
>     http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#top
> 

Done!

-- 
Rafael

[OctDev] Automatic CVS activity notification

[Rafael L. <rla...@us...>]

I noticed that since the last changes in the CVS server at SourceForge the
automatic cvs commit messages are not being sent to the octave-cvsupdate
mailing list.  I suspect that this problem is related to the change of the
mailhost in the CVS server, as documented in:

    http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1

As soon as the CVS server will be working again, I will change
CVSROOT/loginfo to use the SF-recommended script syncmail instead of our
home-made CVSROOT/dncvspipe.  For details, see:

    http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#top

-- 
Rafael

Re: [OctDev] Release this weekend

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

Yeah I noticed.  Let me know when everything is updated.

Thanks,

- Paul

On Jan 23, 2004, at 8:20 AM, David Bateman wrote:

> Paul,
>
> Can you delay this release a few days. The problem is that the source
> forge CVS is a nightmare in the past few days, making it impossible to
> commit stuff.
>
> Cheers
> David
>
> According to Paul Kienzle <pki...@us...> (on 
> 01/19/04):
>> We are well overdue for an octave-forge release.
>>
>> Please post outstanding changes so we can do
>> a release this weekend.
>>
>> Thanks,
>>
>> Paul Kienzle
>> pki...@us...
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by EclipseCon 2004
>> Premiere Conference on Open Tools Development and Integration
>> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>> http://www.eclipsecon.org/osdn
>> _______________________________________________
>> 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] Release this weekend

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

Paul,

Can you delay this release a few days. The problem is that the source
forge CVS is a nightmare in the past few days, making it impossible to
commit stuff.

Cheers
David

According to Paul Kienzle <pki...@us...> (on 01/19/04):
> We are well overdue for an octave-forge release.
> 
> Please post outstanding changes so we can do
> a release this weekend.
> 
> Thanks,
> 
> Paul Kienzle
> pki...@us...
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> 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

[OctDev] Re: benchmarks - sort

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

Dapr=E8s Paul Thomas <pau...@wa...> (le 22/01/2004):
> In conclusion, I will use your sort algorithm but found mine to be an=20
> interesting exercise.

Except that the version I previously sent, I introduced a bug when fixing
a seg-fault. The result was that it didn't always do the last merge. The
fix unfortunately slows things up a bit, though at worst case "b=3Dsort(a=
)"
is only 1.5 times as long as matlab, and still much better for partially
ordered lists....

I attach the patch, in case you want to test it, but will try and commit
the code...

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] Re: benchmarks - sort

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

Thomas,

I've written my sorting code as a patch against octave-forge with the idea
that it might be included in this weekends release. There are still some 
possible improvements, but frankly it performs pretty well, is compatiable
with the behaviour of the default Octave sort code (include complex), and 
has been tested for correctness (see testsort.m).

The problem is the sourceforge CVS seems to be down at the moment, and so
I can't commit this patch. For interest I attach it here and if I can't commit
by this weekend I hope Paul will include this code for me before he does a
code release.

In any case, having this function in octave-forge is a pretty good test of
its functionality, when many users get to see it. After a bit of testing
perhaps JWE might accept the code into Octave itself...

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

[OctDev] Release this weekend

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

We are well overdue for an octave-forge release.

Please post outstanding changes so we can do
a release this weekend.

Thanks,

Paul Kienzle
pki...@us...

[OctDev] load/save support for user types

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

Dear All,

I've committed load/save support for the Galois field type that is useable
with the current octave CVS. This might be the basis for similar support
for the symbolic, sparse, etc user types.

You'll need to include the $(CLASS_HAS_LOAD_SAVE) Makeconf 
variable in your defines for mkoctfile and place the new code 
in "#ifdef CLASS_HAS_LOAD_SAVE ... #endif" to keep backwards 
compatibility. Files to check to the example code are in 
main/comm/ov_galois.h and main/comm/ov_galois.cc and in 
particular the functions save_{ascii,binary,hdf5} and 
load_{ascii,binary,hdf5}. Other examples of these functions
can be found in the octave CVS itself.

One important point to remember with user defined types, is that
the type must be registered prior to the re-loading of the saved
file within octave. That is "octave_foo::register_type ()" must
be called before the load. This can usually be done by using the
type one prior to the load. For the Galois field type an example
would be

octave:1> dummy = gf(1);
octave:2> load test.mat

Now the only thing keeping user types as second class citizens is
the concatenation operators..... :-)

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] convhulln options: qhull options

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

QHull provides a very complete set of options. This options come in different 
families:
	- Format options 
	- Print options
	- Geomview options
	- Trace options
	- precision options
	- Q control options.

I think the most important issue to decide is what output will be handled back 
to octave and what won't. For example we've been running qhull with the s 
option (for a summary on stderr) and we didn't make use of it. 

As it was said in another post I think the struct array proposed by Paul is 
correct. (We'll need to see the format of the ridges element, probably a 
matrix containing the vertices of each ridge, always with the same dimension 
and varying length depending on the facet been simplicial or not).

        x(id).normal = <normal>
        x(id).offset = <offset>
        x(id).area = <area>
        x(id).vertices = [v1,...,vn]
        x(id).neighbors = [id1,...,idn]
        x(id).ridges = <?>

Some other kind of output like OFF file for Geomview or summary can be sent to 
a file. For this second purpose it is important to get the "TO file" option 
working. Right know it does nothing. 

I gues the most used options for qhull could be the subset presented by qhull 
on the command line:
	d : 'delaunay', Delaunay triangulation lifting the points to a paraboloid
	d Qu : 'furthest delaunay'. Furthest site Delaunay triangulation.
	v : 'voronoi'. Voronoi diagram
	v Qu: 'furthest voronoi'. Furthest site Voronoi diagram
	H1,1: 'halfspace intersection' about [1,1,0,0...]
	Qt: 'triangulated output'
	QJ: 'joggled input'
	Tv: 'verify results'
	s: 'output summary'
	i: 'vertices in facets' (This is what we actually get returned to octave)
	n:'normals'. Normals with offset for each facet (This is what I also want to 
have ;).)
	p: 'vertex coordinates'. We already have that since we parse a matrix with 
this to the function.
	Fp: 'halfspace intersections'
	Fx: 'extreme points'
	FA: 'total area and volume'
	o: 'OFF format'
	G: 'Geomview output'
	m: 'Mathematica output'
	QVn: 'print facets that include point n'
	TO file: 'output file'

As you see QVn is an "option with options" so I would eliminate it from the 
list and pass it as a string like it is done now.  The same for Hn,n and all 
the other options not listed here.

Regards,
Pedro

Re: [OctDev] convhulln options.

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

El Jueves, 18 de Diciembre de 2003 11:43, a Rafael Laboissiere  se le ocurr=
i=F3=20
decir lo siguiente:

> I also noticed that Qt is not working and I have no clue about where the
> problem is.  I will try to investigate further when I will have some time.

It works adding the Q0 option. According to QHull manual Q0: "do not pre-me=
rge=20
facets with 'C-0' and Qx". C-0 and Qx options are by default used by qhull =
to=20
avoid precission errors. This errors can be avoided pre-merging coplanar=20
facets (C-0 & Qx) or using QJ option.=20
Again reading qhull manual: "Use option 'Qt' to triangulate all non-simplic=
ial=20
facets before generating results". So... Qt uses C-0 and Qx and only later =
it=20
"breaks" non-simplicial facets. Maybe this is why, since we read the qh=20
struct on memory rather than the final result of qhull this isn't working..=
=2E=20
It looks like there's a missing step.
This is as far as I've got...

Regards,
Pedro

Re: [OctDev] convhulln options.

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

El Viernes, 19 de Diciembre de 2003 06:24, a Paul Kienzle  se le ocurri=F3 =
decir=20
lo siguiente:

> >> I think the most convenient would be to return a cell-array of
> >> matrices,
> >> one for each dimension of returned facet.
> >
> > Sorry, I did not understand the above statement.  Could you give an
> > example,
> > please?
>
> A =3D { [7 4 3; 4 6 2; 6 7 5; 7 6 4], [5 7 3 1; 6 5 1 2] }
>
> This is the same information as above but you can process it with
> "for i=3D1:2" rather than "for i=3D1:6".

Be carefull... if we are returning more things from qhull the order is=20
important, unless you also return the facet ID.


> Okay.  But aren't we supposed to be avoiding QJ?  Is there a way to
> break up a non-simplicial facet which doesn't introduce errors?

That's what Qt is supposed to do, but as Rafael also noticed, this option i=
s=20
not working under octave properly.

> I can't propose a final design because I don't know how to use
> QHull effectively.  You tell me what options you want to control
> and what they mean, and I can suggest an interface.

QHull has many, many options. In fact delaunay* and voronoi* are just QHull=
=20
with parameters. I can prepare a list of the options I think are most=20
important. I'll mail them to the list as soon as I prepare it.

Regards,
Pedro

Re: [OctDev] convhulln options.

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

El Viernes, 19 de Diciembre de 2003 06:31, a Paul Kienzle  se le ocurri=F3 =
decir=20
lo siguiente:
> > 	- A polyhedron is just an ordered list of facets.
> > 	- A facet should contain:
> > 		- id number
> > 		- normals and offset (hyperplane supporting the facet)
> > 		- area
> > 		- set of vertices (n if simplicial, >n if non-simplicial)
> > 		- set of neighbours (again n  if simplicial...). Here's the need for
> > the id.
> > 		- set of ridges. (?)
>
> Maybe you want a structure array?
>
> 	x(id).normal =3D <normal>
> 	x(id).offset =3D <offset>
> 	x(id).area =3D <area>
> 	x(id).vertices =3D [v1,...,vn]
> 	x(id).neighbors =3D [id1,...,idn]
> 	x(id).ridges =3D <?>
>
> My only question is, are there relevant vector operations you want to
> do on the returned information?  Or do you need a for loop to process
> each id?  Since the octave interpreter is slow, I prefer to avoid for
> loops
> as much as possible.

Let me give you some ideas of what I'm doing. My hull belongs to an economi=
c=20
simulation model. Each facet has an economic interpretation in terms of=20
prices of different inputs. I do perform computations on every facet to get=
 a=20
set of points that will give me the shape of a demand function. So... I do=
=20
loop around all facets. I also have to study the equilibrium conditions=20
around the "optimal" facet and that's where the neighbors set becomes=20
specially important (neighbours for those of us who learnt english with a B=
BC=20
method ;) ).

Regards,
Pedro

Re: [OctDev] convhulln options.

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

On Dec 18, 2003, at 3:53 AM, Rafael Laboissiere wrote:

> * Paul Kienzle <pki...@us...> [2003-12-17 20:07]:
>
>>
>> On Dec 17, 2003, at 7:00 PM, Rafael Laboissiere wrote:
>>
>> [...]
>>> would be represented in Octave like this:
>>>
>>>    A = {[3 4 2 1],
>>>         [7 4 3],
>>>         [5 7 3 1],
>>>         [4 6 2],
>>>         [6 7 5],
>>>         [7 6 4],
>>>         [6 5 1 2]}
>>>
>>>
>>> (Notice that vertex indices in Octave start at 1 instead of zero.)
>>>
>>> I do not know how backward incompatible would be such a change.
>>
>> I think the most convenient would be to return a cell-array of 
>> matrices,
>> one for each dimension of returned facet.
>
> Sorry, I did not understand the above statement.  Could you give an 
> example,
> please?

A = { [7 4 3; 4 6 2; 6 7 5; 7 6 4], [5 7 3 1; 6 5 1 2] }

This is the same information as above but you can process it with
"for i=1:2" rather than "for i=1:6".

>> I think it would also be convenient if the default were to arbitrarily
>> split those facets that are non-simplicial so that those who just want
>> triangles don't have to deal with the occasional square.  I'm 
>> guessing that
>> this is what matlab does --- convhulln returns this for the cube:
>>
>>>> convhulln(cube)
>>
>> ans =
>>
>>      3     4     1
>>      4     2     1
>>      2     4     6
>>      2     5     1
>>      5     2     6
>>      7     5     6
>>      4     7     6
>>      7     4     3
>>      7     3     1
>>      5     7     1
>
> This is the case in Octave with the "QJ" option:
>
>     octave:3> convhulln(cube,"QJ")
>     qhull warning: joggle ('QJ') always produces simplicial output.
>     Triangulated output ('Qt') does nothing.
>     ans =
>
>       7  8  6
>       4  8  6
>       5  7  1
>       5  7  6
>       2  4  1
>       2  4  6
>       2  5  1
>       2  5  6
>       3  7  8
>       3  4  8
>       3  7  1
>       3  4  1

Okay.  But aren't we supposed to be avoiding QJ?  Is there a way to
break up a non-simplicial facet which doesn't introduce errors?

>
>> So long as the default all-simplicial case is returned as a matrix,
>> backward compatibility doesn't matter.  The user will need special 
>> code to
>> handle the non-simplicial facets anyway.
>>
>> Are these two cases different enough that we need different functions?
>
> I do not think so, since the output format will be dependent on the 
> data
> and, in general, cannot be determined beforehand by the user.
>
> I have already an idea on how to implement this change (i.e., 
> returning a
> cell array instead of a matrix in the non-simplicial case.  Should I go
> ahead?

The output needs to be predictable so that users can code for it.  
Also, the
default output must be simplicial only for compatibility --- same named
functions should give the same results for the same input.

>
>> I think you are going to need an interface layer above the QHull 
>> options so
>> that users can ask for them nicely:
>>
>> [X,Y,Z] = convhulln(cube,'output',{'simplicial','ideal','geomview'})
>>
>> This says that X will contain the simplicial output (as a full 
>> matrix),
>> Y will contain a cell array of facet sizes, and Z will contain a 
>> string
>> used to control geomview.  The default for output must be 'simplicial'
>> for compatibility.
>>
>> That means you will need other options for controlling the QHull
>> algorithm, such as 'qhull','QJ' to feed a raw option string, or if 
>> you are
>> feeling creative, meaningful names for all the options.
>
> That looks like a quite nice idea.  Two questions:
>
>     * Is the option passing format you described above standard in
>       Matlab/Octave/octave-forge?

Matlab uses 'option',value pairs frequently (e.g., for all of their 
handle
graphics functions and for their optimization functions).  Many 
functions
also accept structures where x.option=value.  I wrote some code a
couple of years ago to sort out options --- I'll update it and send it
along.

Matlab also uses fn(...,'option','option','option') and  fn(...,parms), 
where
parms is an array of integers, but these are less common.

>
>     * Can I consider your suggestion as a final design or is it just a
>       sketch?  If it is the later, could you please propose a complete
>       design (so that implementation can follows easily)?

I can't propose a final design because I don't know how to use
QHull effectively.  You tell me what options you want to control
and what they mean, and I can suggest an interface.

- Paul

Re: [OctDev] convhulln options.

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

On Dec 18, 2003, at 5:05 AM, Pedro Tarrafeta wrote:
>
>> Are these two cases different enough that we need different functions?
>>
>> I think you are going to need an interface layer above the QHull 
>> options
>> so that users can ask for them nicely:
>>
>> [X,Y,Z] = convhulln(cube,'output',{'simplicial','ideal','geomview'})
>>
>> This says that X will contain the simplicial output (as a full 
>> matrix),
>> Y will contain a cell array of facet sizes, and Z will contain a 
>> string
>> used to control geomview.  The default for output must be 'simplicial'
>> for compatibility.
>>
>> That means you will need other options for controlling the QHull
>> algorithm,
>> such as 'qhull','QJ' to feed a raw option string, or if you are 
>> feeling
>> creative, meaningful names for all the options.
>
> I think so.
> In fact. Maybe we should use convhulln for matlab compatibility if 
> this is an
> issue. Some of the important info that I think should be accesible from
> octave is stored in qh struct in qhull. What I mean is:
> 	- A polyhedron is just an ordered list of facets.
> 	- A facet should contain:
> 		- id number
> 		- normals and offset (hyperplane supporting the facet)
> 		- area
> 		- set of vertices (n if simplicial, >n if non-simplicial)
> 		- set of neighbours (again n  if simplicial...). Here's the need for 
> the id.
> 		- set of ridges. (?)

Maybe you want a structure array?

	x(id).normal = <normal>
	x(id).offset = <offset>
	x(id).area = <area>
	x(id).vertices = [v1,...,vn]
	x(id).neighbors = [id1,...,idn]
	x(id).ridges = <?>

My only question is, are there relevant vector operations you want to
do on the returned information?  Or do you need a for loop to process
each id?  Since the octave interpreter is slow, I prefer to avoid for 
loops
as much as possible.

Paul Kienzle
pki...@us...

Re: [octave] Re: [OctDev] convhulln options.

[Kai H. <ka...@gm...>]

...
> Okay, I will implement this. Shouldn't the "Tc" option be removed as you
> suggested?  Besides, what is the "s" option for?
> 

I think both can be removed. A detailed description of the 's' option 
can be found at [1]

Bye, Kai

[1] http://www.thesa.com/software/qhull/html/qh-opto.htm#s

Re: [OctDev] convhulln options.

[Rafael L. <rla...@us...>]

* Pedro Tarrafeta <pt...@te...> [2003-12-18 11:05]:

> This is what Qt is supposed to do. QJ also does it although using some other 
> method (joggling vertices until only simplicial facets are found). Anyway Qt 
> option is not working under octave. Is it just my case?

I also noticed that Qt is not working and I have no clue about where the
problem is.  I will try to investigate further when I will have some time.

> I think so. 
> In fact. Maybe we should use convhulln for matlab compatibility if this is an 
> issue. Some of the important info that I think should be accesible from 
> octave is stored in qh struct in qhull. What I mean is:
> 	- A polyhedron is just an ordered list of facets.
> 	- A facet should contain:
> 		- id number
> 		- normals and offset (hyperplane supporting the facet)
> 		- area
> 		- set of vertices (n if simplicial, >n if non-simplicial)
> 		- set of neighbours (again n  if simplicial...). Here's the need for the id.
> 		- set of ridges. (?)
> 
> I don't know how difficult this is but it looks like in the same 
> FORALLfacets{} loop  the above can be retrieved and written to octave.

This means a total redesign of the qhull functions and facilities for
Octave, with the old API (delaunay, convhull, and voronoi) being wrappers to
them.  I would like to see this happening.  Could someone make a complete
design proposal?

-- 
Rafael