From: Pedro T. <pt...@te...> - 2003-11-21 15:37:20
|
This is a post to start discussing the convhulln implementation in octave. convhulln() is a function that returns the convex hull of a set of points. = It=20 is based on qhull (http://www.thesa.com/software/qhull/). Lets start with an example to center the discussion. I did prepare the following script: convhulltest.m ************************************ #! /usr/bin/octave -qf % This is an example of what happens with different versions of convhulln() % We will first define an easy to visualize polyhedron and after that we wi= ll=20 % check what happens with the output % prisma will hold the coordinates of a prisma with pentagonal base. There's % also one point inside the prisma (just to verify it doesn' appear in the % hull) prisma =3D [0,0,0;0,1,0;1,3,0;2,0,0;2,1,0;0,0,1;0,1,1;1,3,1;2,0,1;2,1,1;1,1= ,0.5] % I have the following commands % convhulln() , computes the convex hull with QJ option (this is my default) % convhullnold(), is the old version of convhulln() % convhullnnew(), is the recently modified (1.5) version of convhulln ch1 =3D convhulln(prisma) ch2 =3D convhullnnew(prisma) ch3 =3D convhullnold(prisma) % I will run this script and comment the results. I will also comment the=20 % results using command line qhull. ***************************************** The prisma described in the script has clearly 7 faces, two of which are=20 penthagons and the other five are rectangles. Point #11 is interior to the= =20 prisma so it should never appear on the hull. Here are the results... first, what I see on the console (warnings): ****************************************** pedro@linux:~> ./convhulltest.m > result Output completed. Verifying that all points are below 1.2e-14 of all facets. Will make 176 distance computations. Output completed. Verifying that all points are below outer planes of all facets. Will make 77 distance computations. warning: extra vertex 3 of facet 0 =3D 4 warning: extra vertex 4 of facet 0 =3D 1 warning: extra vertex 3 of facet 1 =3D 1 warning: extra vertex 3 of facet 2 =3D 4 warning: extra vertex 3 of facet 3 =3D 3 warning: extra vertex 3 of facet 4 =3D 10 warning: extra vertex 4 of facet 4 =3D 6 warning: extra vertex 3 of facet 5 =3D 1 warning: extra vertex 3 of facet 6 =3D 3 Output completed. Verifying that all points are below outer planes of all facets. Will make 77 distance computations. panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Violaci=F3n de segmento ***************************************************** As you can see, something terrible happened at the end of the last computat= ion=20 (with the older version of convhulln). We will come back later on this. Now the results, I will coment them using { } ****************************************************** prisma =3D 0.00000 0.00000 0.00000 0.00000 1.00000 0.00000 1.00000 3.00000 0.00000 2.00000 0.00000 0.00000 2.00000 1.00000 0.00000 0.00000 0.00000 1.00000 0.00000 1.00000 1.00000 1.00000 3.00000 1.00000 2.00000 0.00000 1.00000 2.00000 1.00000 1.00000 1.00000 1.00000 0.50000 {ok... this looks pretty obvious... just to have a visual reference on what= =20 the index of the points mean} ch1 =3D {this is what I get with joggled input. I get the prisma constructe= d=20 with 16 triangles: 3 on the bottom, 3 on top, and 2 for each side. Every=20 point that is a vertex is listed here somehow} 10 9 7 10 8 7 6 9 7 3 8 7 3 2 7 3 5 2 3 10 8 3 10 5 1 2 7 1 6 7 4 5 2 4 1 2 4 10 9 4 10 5 4 6 9 4 1 6 ch2 =3D {this is what I get with the new convhulln(). Notice that I only ha= ve a=20 triangle on each face. I can not reconstruct the prisma with this=20 information. Vertex #1 which is part of the hull does not list. It is=20 possible to find it in the warnings we listed before. Notice that the=20 warnings use C enumeration for facets and vertex info; 0 is what we would=20 call 1, etc. Then what comes after the =3D sign is "in our language"} 5 2 3 9 6 4 9 5 10 8 5 10 7 8 9 7 2 6 7 8 2 ****************************************************** Here the results break... the old convhulln couldn't handle something.... If we run qhull (without options) from the command line against a similar=20 prisma, this is what we get: 0 3 4 2 1 5 8 3 0 8 9 4 3 9 7 2 4 6 7 9 8 5 6 5 0 1 7 6 1 2=20 To speak in the same language we should add 1 to every index listed here. A= s=20 we can see it's not easy for octave to handle this ouput. Not all the rows= =20 have the same number of elements. Maybe this is the reason for the=20 seg-fault?. If we run it with QJ or Qt options we get triangulated output, although the= =20 triangulation is different. So... after writing this long, long brick.... Should we give some more=20 functionality to the convhulln function? (maybe giving it some other name f= or=20 compatibility reasons). I don't understand why the new convhulln doesn't gi= ve=20 also triangulated output (not trimmed rows...). I hope this can be an starting point for discussion. Regards, Pedro |
From: Rafael L. <rla...@us...> - 2003-11-22 10:26:41
|
* Pedro Tarrafeta <pt...@te...> [2003-11-21 16:36]: > This is a post to start discussing the convhulln implementation in octave. > > convhulln() is a function that returns the convex hull of a set of points. It > is based on qhull (http://www.thesa.com/software/qhull/). > > Lets start with an example to center the discussion. > I did prepare the following script: > > [...] Thanks for this thorough example. > If we run it with QJ or Qt options we get triangulated output, although the > triangulation is different. > > So... after writing this long, long brick.... Should we give some more > functionality to the convhulln function? (maybe giving it some other name > for compatibility reasons). I don't understand why the new convhulln > doesn't give also triangulated output (not trimmed rows...). My understanding is that Paul Kienzle fixed this problem in his last commit to convhulln.cc, namely by adding a Qt option to the qhull command call. More than one year ago I changed the delaunay3.m, delaunay.m, and delaunayn.cc files such that the associated functions would accept an extra (optional) argument containing additional options to the qhull command. This extra argument is just a string that is concatenated to the qhull command string. I think that a similar change to convhulln.cc would fit your needs. Also, similar changes could be done to the voronoy functions. Should I implement them? -- Rafael |
From: Pedro T. <pt...@te...> - 2003-11-24 10:02:08
|
> Thanks for this thorough example. Just copy and paste when I was trying to understand what was going on. Anyway... your're welcome ;) > > My understanding is that Paul Kienzle fixed this problem in his last commit > to convhulln.cc, namely by adding a Qt option to the qhull command call. It doesn't seem to work though. Please test it with my example and if it works I will have to look further on the qhull libraries (I think I have the latest). > More than one year ago I changed the delaunay3.m, delaunay.m, and > delaunayn.cc files such that the associated functions would accept an extra > (optional) argument containing additional options to the qhull command. > This extra argument is just a string that is concatenated to the qhull > command string. > I think that a similar change to convhulln.cc would fit your needs. Also, > similar changes could be done to the voronoy functions. Should I implement > them? This would be perfect. However I still don't understand how the non-simplex facets with non triangulated output will be imported to octave. We would need a matrix with as many columns as the largest number of vertices in this facet and define vertex 0 as non-existant, or something like... Waiting to test the new convhulln.... Regards, Pedro |
From: Simon C. <si...@li...> - 2003-11-25 12:48:29
|
Greetings, Having recently worked with convhulln() and qhull I'd definitely like to have access to qhull's options from within Octave. The default option set isn't appropriate for all applications and I've had to recompile convhulln() so that it calls qhull with the options I need. I think convhulln() should remain compatible with the Matlab version but it would be nice to have another function (called qhull?) which allows one to pass options through to the qhull library. Another route would be to have some way of setting the options which convhulln() passes to the qhull library. Perhaps it would be best to implement both these options. Then one could easily modify the behaviour of convhulln() for a particular program. The function convhulln() could then be implemented as a call to qhull(). Schiavo Simon -- 4979 486 380 (llec) :leT 9383 056 120 (krow) ten.az.noulg@nomis :liam-E |
From: Rafael L. <rla...@us...> - 2003-12-09 13:21:48
|
* Simon Cross <si...@li...> [2003-11-25 14:48]: > I think convhulln() should remain compatible with the Matlab version but > it would be nice to have another function (called qhull?) which allows > one to pass options through to the qhull library. How is convhulln defined in Matlab? > Another route would be to have some way of setting the options which > convhulln() passes to the qhull library. > > Perhaps it would be best to implement both these options. Then one > could easily modify the behaviour of convhulln() for a particular > program. The function convhulln() could then be implemented as a call to > qhull(). Currently, the delaunay* functions of octave-forge have definitions similar to this: T = delaunayn (P[, OPT]) where OPT is a string of options to be passed to the underlying qhull command. I was thinking about extending the above to the voronoi* and convhull* functions. Would it be okay? -- Rafael |
From: Paul K. <pki...@us...> - 2003-12-09 13:39:43
|
On Dec 9, 2003, at 8:21 AM, Rafael Laboissiere wrote: > * Simon Cross <si...@li...> [2003-11-25 14:48]: > >> I think convhulln() should remain compatible with the Matlab version >> but >> it would be nice to have another function (called qhull?) which allows >> one to pass options through to the qhull library. > > How is convhulln defined in Matlab? K = convhulln(X) > >> Another route would be to have some way of setting the options which >> convhulln() passes to the qhull library. >> >> Perhaps it would be best to implement both these options. Then one >> could easily modify the behaviour of convhulln() for a particular >> program. The function convhulln() could then be implemented as a call >> to >> qhull(). > > Currently, the delaunay* functions of octave-forge have definitions > similar > to this: > > T = delaunayn (P[, OPT]) > > where OPT is a string of options to be passed to the underlying qhull > command. I was thinking about extending the above to the voronoi* and > convhull* functions. Would it be okay? Okay, but I would prefer 'standard' option handling. Problem is, I don't like the matlab standard: f(...,'option',val). Passing a structure x with fields option=value would be okay if octave had a syntax for structure constants. Paul Kienzle pki...@us... |
From: Rafael L. <lab...@ps...> - 2003-12-09 16:38:59
|
* Paul Kienzle <pki...@us...> [2003-12-09 08:39]: > On Dec 9, 2003, at 8:21 AM, Rafael Laboissiere wrote: > > >Currently, the delaunay* functions of octave-forge have definitions > >similar > >to this: > > > > T = delaunayn (P[, OPT]) > > > >where OPT is a string of options to be passed to the underlying qhull > >command. I was thinking about extending the above to the voronoi* and > >convhull* functions. Would it be okay? > > Okay, but I would prefer 'standard' option handling. Problem is, I > don't like the matlab standard: f(...,'option',val). Passing a > structure > x with fields option=value would be okay if octave had a syntax for > structure constants. I do not follow you. The OPT argument of the delaunay* function is a simple string containing options to be passed to the qhull command. for instance, one may call: T = delaunayn (P, "Qt") What does this have to do with the pairs <'option', val> that you mentioned? -- Rafael |
From: Simon C. <si...@li...> - 2003-12-10 07:38:13
|
Hi, > Okay, but I would prefer 'standard' option handling. Problem is, I > don't like the matlab standard: f(...,'option',val). Passing a > structure x with fields option=value would be okay if octave had a > syntax for structure constants. If I'm reading this correctly, Paul is saying we should have a standard way of passing options across all of octave-forge. I think that that is a good idea. Somebody pick a standard. :) >Currently, the delaunay* functions of octave-forge have definitions >similar to this: > > T = delaunayn (P[, OPT]) > >where OPT is a string of options to be passed to the underlying qhull >command. I was thinking about extending the above to the voronoi* and >convhull* functions. Would it be okay? I think that would be excellent for voronoi, convhull and friends. If some sort of standard option passing method is decided on, it might be good to follow it though. If we decide to go with some kind of struct which holds options, it would probably be best to just have a struct with a single member "qhull_options" (or something) for the particular case of the qhull based functions. These options are so tightly coupled to qhull that specifying them individually in octave-forge would just leave the developers with the annoying problem of tracking qhull releases. Schiavo Simon -- Closed mouths gather no feet. -- 4979 486 380 (llec) :leT 9383 056 120 (krow) ten.az.noulg@nomis :liam-E |
From: Paul K. <pki...@us...> - 2003-12-10 12:20:10
|
On Dec 10, 2003, at 2:37 AM, Simon Cross wrote: > Hi, > >> Okay, but I would prefer 'standard' option handling. Problem is, I >> don't like the matlab standard: f(...,'option',val). Passing a >> structure x with fields option=value would be okay if octave had a >> syntax for structure constants. > > If I'm reading this correctly, Paul is saying we should have a standard > way of passing options across all of octave-forge. I think that that > is > a good idea. Somebody pick a standard. :) That's the idea. Except you are missing the phrase "... and implement it" :-) >> Currently, the delaunay* functions of octave-forge have definitions >> similar to this: >> >> T = delaunayn (P[, OPT]) >> >> where OPT is a string of options to be passed to the underlying qhull >> command. I was thinking about extending the above to the voronoi* and >> convhull* functions. Would it be okay? > > I think that would be excellent for voronoi, convhull and friends. If > some sort of standard option passing method is decided on, it might be > good to follow it though. > > If we decide to go with some kind of struct which holds options, it > would probably be best to just have a struct with a single member > "qhull_options" (or something) for the particular case of the qhull > based functions. These options are so tightly coupled to qhull that > specifying them individually in octave-forge would just leave the > developers with the annoying problem of tracking qhull releases. The best solution from the user's perspective is for us to keep a consistent interface independent of the underlying QHull version (as much as possible). That way people can for example share scripts which use QHull without having to worry about which version is installed. However, I don't know that QHull is changing enough for this to be a concern, so for now I would go with Rafael's solution. Paul Kienzle pki...@us... |
From: Rafael L. <rla...@us...> - 2003-12-10 12:47:33
|
* Paul Kienzle <pki...@us...> [2003-12-10 07:20]: > The best solution from the user's perspective is for us to keep a > consistent interface independent of the underlying QHull version > (as much as possible). That way people can for example share > scripts which use QHull without having to worry about which version > is installed. However, I don't know that QHull is changing enough for > this to be a concern, That's absolutely true. > so for now I would go with Rafael's solution. Okay, I feel we are reaching consensus here. As soon as my time budget will permit, I will implement the changes to the voronoi* and convhull* functions in octave-forge. -- Rafael |
From: Rafael L. <rla...@us...> - 2003-12-13 09:43:41
|
* Rafael Laboissiere <rla...@us...> [2003-12-10 13:46]: > Okay, I feel we are reaching consensus here. As soon as my time budget will > permit, I will implement the changes to the voronoi* and convhull* functions > in octave-forge. I just cvs committed the changes for the convhull and convhulln functions. They accept now an extra (string) argument containing extra options to be passed to the underlying qhull command. I did some minimal tests, but additional checks are welcomed. The next step will be changing the voronoi* functions. -- Rafael |
From: Pedro T. <pt...@te...> - 2003-12-17 13:53:08
|
Rafael, > I just cvs committed the changes for the convhull and convhulln functions. > They accept now an extra (string) argument containing extra options to be > passed to the underlying qhull command. Sorry for the delay but I've been away a few days. Let me point a few thing= s=20 about the new convhulln: - It accepts a string but it is added to the default "s Qt Tcv".I=20 would rather use these options only in the case in which a string hasn't be= en=20 parsed, so that I can use QJ. I don't know the reason but Qt is not returni= ng=20 the same output from octave than outside octave (if you test qhull with a 3= D=20 cube you will get 12 triangulated facets from qhull and 6 facets and extra= =20 vertices from within octave). - Output. The only output the command gives right now is limited an= d=20 biased: - Biased: Since the output matrix is limited to dimension=20 "dim", extra=20 vertices for non simplicial facets get discarded. My knowledge of C is very= =20 little, but.. =BFis it possible to increase the dimension of the returning= =20 matrix (maybe filling it with zeros) in the case of finding a non-simplicia= l=20 facet?. It would be something in line 97 like that: if (j > dim) { dim =3D dim + 1 redim idx(n, dim) for k =3D 1 to i-1{ idx (k, dim) =3D 0 } idx(i,j++) =3D 1 + qh_pointid(vertex->point) } (As you can see my knowledge of C is scarce and I've=20 reinvented the syntax=20 ;) ). - Limited: Parsing a string to qhull allows to obtain some= =20 other info on the hull. Some info that is specially interesting for me is t= he=20 normals to each facet (option n). Since qhull can return various output set= s=20 =BFis it possible that it returns an octave struct with the different resul= ts?.=20 (I have tried to parse to qhull the "TO file" string so that I could get th= e=20 normals from the file created but it does not work. This could also be a=20 solution, in fact THE solution in the case of OFF output to feed Geomview). Regards, Pedro =20 > > I did some minimal tests, but additional checks are welcomed. The next > step will be changing the voronoi* functions. |
From: Rafael L. <rla...@us...> - 2003-12-17 16:45:40
|
* Pedro Tarrafeta <pt...@te...> [2003-12-17 14:52]: > It accepts a string but it is added to the default "s Qt Tcv". I would > rather use these options only in the case in which a string hasn't been > parsed, so that I can use QJ. The options "s" and "Tcv" were originally in Kai Habel's code. (BTW, I cannot find Tcv in the Qhull documentation). The option "Qt" was added later by Paul Kienzle. I agree with you that these options should not be imposed to the user. Should they be the default, as you suggested, or should we only add options given by the user? -- Rafael |
From: Kai H. <ka...@gm...> - 2003-12-17 19:01:11
|
Rafael Laboissiere wrote: > * Pedro Tarrafeta <pt...@te...> [2003-12-17 14:52]: > > >>It accepts a string but it is added to the default "s Qt Tcv". I would >>rather use these options only in the case in which a string hasn't been >>parsed, so that I can use QJ. > > > The options "s" and "Tcv" were originally in Kai Habel's code. (BTW, I > cannot find Tcv in the Qhull documentation). ... The "Tcv" option was copied from an example in "user_eg2.c". It probably means: Tc - check frequently during execution Tv - verify result: structure, convexity, and point inclusion As I read the docs now, the Tc option should be avoided, so maybe it is a good time to remove it. for more information see: http://www.thesa.com/software/qhull/html/qh-optt.htm#Tc Bye Kai |
From: Rafael L. <rla...@us...> - 2003-12-17 23:46:52
|
* Kai Habel <ka...@gm...> [2003-12-17 20:58]: > The "Tcv" option was copied from an example in "user_eg2.c". It probably > means: > > Tc - check frequently during execution > Tv - verify result: structure, convexity, and point inclusion > > As I read the docs now, the Tc option should be avoided, so maybe it is > a good time to remove it. I am leaning toward removing everything, passing only those specified by the user. What do you think? -- Rafael |
From: Paul K. <pki...@us...> - 2003-12-18 00:45:41
|
On Dec 17, 2003, at 6:43 PM, Rafael Laboissiere wrote: > * Kai Habel <ka...@gm...> [2003-12-17 20:58]: > >> The "Tcv" option was copied from an example in "user_eg2.c". It >> probably >> means: >> >> Tc - check frequently during execution >> Tv - verify result: structure, convexity, and point inclusion >> >> As I read the docs now, the Tc option should be avoided, so maybe it >> is >> a good time to remove it. > > I am leaning toward removing everything, passing only those specified > by the > user. What do you think? My preference is for the default to 'do the right thing', and for the sophisticated users to have complete control. To me, that means using the defaults recommended by the QHull author, and tracking them as QHull changes. Paul Kienzle pki...@us... |
From: Kai H. <ka...@gm...> - 2003-12-18 07:36:16
|
Rafael Laboissiere wrote: > * Kai Habel <ka...@gm...> [2003-12-17 20:58]: > > >>The "Tcv" option was copied from an example in "user_eg2.c". It probably >>means: >> >>Tc - check frequently during execution >>Tv - verify result: structure, convexity, and point inclusion >> >>As I read the docs now, the Tc option should be avoided, so maybe it is >>a good time to remove it. > > > I am leaning toward removing everything, passing only those specified by the > user. What do you think? > I would side with Paul to use the 'right' options by default. We could remove the default options 's Qt Tcv' if the user provides the options string. In this case the normal user gets the right options, and the experienced user can use arbitrary options with qhull. Bye Kai |
From: Rafael L. <rla...@us...> - 2003-12-18 08:41:42
|
* Kai Habel <ka...@gm...> [2003-12-18 09:33]: > I would side with Paul to use the 'right' options by default. We could > remove the default options 's Qt Tcv' if the user provides the options > string. In this case the normal user gets the right options, and the > experienced user can use arbitrary options with qhull. Okay, I will implement this. Shouldn't the "Tc" option be removed as you suggested? Besides, what is the "s" option for? -- Rafael |
From: Pedro T. <pt...@te...> - 2003-12-18 08:58:05
|
El Jueves, 18 de Diciembre de 2003 09:39, a Rafael Laboissiere se le ocurr= i=F3=20 decir lo siguiente: > * Kai Habel <ka...@gm...> [2003-12-18 09:33]: > > I would side with Paul to use the 'right' options by default. We could > > remove the default options 's Qt Tcv' if the user provides the options > > string. In this case the normal user gets the right options, and the > > experienced user can use arbitrary options with qhull. > > Okay, I will implement this. Shouldn't the "Tc" option be removed as you > suggested? Besides, what is the "s" option for? It is useless under octave. With qhull command line programm it prints a=20 summary of the hull and calculations made. Since we don't return this to=20 octave I don't think it's necessary. Regards, Pedro |
From: Kai H. <ka...@gm...> - 2003-12-18 19:13:40
|
... > 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 |
From: Rafael L. <rla...@us...> - 2003-12-18 00:04:23
|
* Pedro Tarrafeta <pt...@te...> [2003-12-17 14:52]: > - Output. The only output the command gives right now is limited and > biased: > > - Biased: Since the output matrix is limited to dimension "dim", extra > vertices for non simplicial facets get discarded. My knowledge of C is > very little, but.. ¿is it possible to increase the dimension of the > returning matrix (maybe filling it with zeros) in the case of finding a > non-simplicial facet?. It would be something in line 97 like that: > > if (j > dim) { > dim = dim + 1 > redim idx(n, dim) > for k = 1 to i-1 { > idx (k, dim) = 0 > } > idx(i,j++) = 1 + qh_pointid(vertex->point) > } Instead of doing that, we might return a cell array instead of a matrix when non simplicial facets are found. For instance, the following result: $ cat cube 3 7 0 0 0 0 0 1 0 1 0 0 1 1 1 0 0 1 0 1 1 1 0 $ cat cube | qhull o 3 7 7 12 0 0 0 0 0 1 0 1 0 0 1 1 1 0 0 1 0 1 1 1 0 4 2 3 1 0 3 6 3 2 4 4 6 2 0 3 3 5 1 3 5 6 4 3 6 5 3 4 5 4 0 1 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. > - Limited: Parsing a string to qhull allows to obtain some other info on > the hull. Some info that is specially interesting for me is the normals > to each facet (option n). Since qhull can return various output sets is > it possible that it returns an octave struct with the different results?. > (I have tried to parse to qhull the "TO file" string so that I could get > the normals from the file created but it does not work. This could also > be a solution, in fact THE solution in the case of OFF output to feed > Geomview). To avoid backward incompatible changes, what about having extra output arguments, one for the facet normals, other for the OFF string result, and so on? -- Rafael |
From: Paul K. <pki...@us...> - 2003-12-18 01:07:49
|
On Dec 17, 2003, at 7:00 PM, Rafael Laboissiere wrote: > * Pedro Tarrafeta <pt...@te...> [2003-12-17 14:52]: > >> - Output. The only output the command gives right now is limited and >> biased: >> >> - Biased: Since the output matrix is limited to dimension "dim",=20 >> extra >> vertices for non simplicial facets get discarded. My knowledge of=20= >> C is >> very little, but.. =BFis it possible to increase the dimension of=20= >> the >> returning matrix (maybe filling it with zeros) in the case of=20 >> finding a >> non-simplicial facet?. It would be something in line 97 like = that: >> >> if (j > dim) { >> dim =3D dim + 1 >> redim idx(n, dim) >> for k =3D 1 to i-1 { >> idx (k, dim) =3D 0 >> } >> idx(i,j++) =3D 1 + qh_pointid(vertex->point) >> } > > Instead of doing that, we might return a cell array instead of a=20 > matrix when > non simplicial facets are found. For instance, the following result: > > $ cat cube > 3 > 7 > 0 0 0 > 0 0 1 > 0 1 0 > 0 1 1 > 1 0 0 > 1 0 1 > 1 1 0 > $ cat cube | qhull o > 3 > 7 7 12 > 0 0 0 > 0 0 1 > 0 1 0 > 0 1 1 > 1 0 0 > 1 0 1 > 1 1 0 > 4 2 3 1 0 > 3 6 3 2 > 4 4 6 2 0 > 3 3 5 1 > 3 5 6 4 > 3 6 5 3 > 4 5 4 0 1 > > would be represented in Octave like this: > > A =3D {[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=20 matrices, one for each dimension of returned facet. I think it would also be convenient if the default were to arbitrarily=20= split those facets that are non-simplicial so that those who just want=20 triangles don't have to deal with the occasional square. I'm guessing that this=20= is what matlab does --- convhulln returns this for the cube: >> convhulln(cube) ans =3D 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 So long as the default all-simplicial case is returned as a matrix,=20 backward compatibility doesn't matter. The user will need special code to=20 handle the non-simplicial facets anyway. Are these two cases different enough that we need different functions? > >> - Limited: Parsing a string to qhull allows to obtain some other info=20= >> on >> the hull. Some info that is specially interesting for me is the=20 >> normals >> to each facet (option n). Since qhull can return various output=20 >> sets is >> it possible that it returns an octave struct with the different=20 >> results?. >> (I have tried to parse to qhull the "TO file" string so that I=20 >> could get >> the normals from the file created but it does not work. This could=20= >> also >> be a solution, in fact THE solution in the case of OFF output to=20 >> feed >> Geomview). > > To avoid backward incompatible changes, what about having extra output > arguments, one for the facet normals, other for the OFF string result,=20= > and > so on? 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] =3D 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=20 algorithm, such as 'qhull','QJ' to feed a raw option string, or if you are feeling creative, meaningful names for all the options. Paul Kienzle pki...@us... |
From: Rafael L. <rla...@us...> - 2003-12-18 08:55:41
|
* 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? > 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 > 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? > 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? * 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)? -- Rafael |
From: Pedro T. <pt...@te...> - 2003-12-18 10:26:14
|
> 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. But Qt works on command line qhull. Maybe there's some option about merging or unmerging facets that we are missing? > > 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. Sure in the case of just simplicial or non simplicial. As far as I understand the need for two functions is to have one (convhulln) to keep matlab compatibility which should always return a matrix (maybe always simplicial facets too) and another one to allow for more specific output with user control on the options. The first funcion (convhulln) could just be a wrap around the second. > 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? If it's possible to do so I would certainly appreciate it, and believe me, I'm just anxious about testing it ;). Regards, Pedro |
From: Pedro T. <pt...@te...> - 2003-12-18 10:06:15
|
El Jueves, 18 de Diciembre de 2003 02:07, a Paul Kienzle se le ocurri=F3 d= ecir=20 lo siguiente: > > Instead of doing that, we might return a cell array instead of a > > matrix when > > non simplicial facets are found. For instance, the following result: > >. . . . . . . . . . . . > > would be represented in Octave like this: > > > > A =3D {[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. I don't understand this. Each of these matrices would contain an unique num= ber=20 referecing a vertex?. > > 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 =3D > > 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 what Qt is supposed to do. QJ also does it although using some othe= r=20 method (joggling vertices until only simplicial facets are found). Anyway Q= t=20 option is not working under octave. Is it just my case? > > 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. Ok on that. > 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] =3D 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.=20 In fact. Maybe we should use convhulln for matlab compatibility if this is = an=20 issue. Some of the important info that I think should be accesible from=20 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=20 =46ORALLfacets{} loop the above can be retrieved and written to octave. Regards, Pedro |