octave-dev — GNU Octave developers' list

Re: [OctDev] convhulln options.

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

> 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

Re: [OctDev] convhulln options.

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

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

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

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

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

Re: [OctDev] convhulln options.

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

* 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

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

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

* 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

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

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

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

Re: [OctDev] convhulln options.

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

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

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

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

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

Re: [OctDev] convhulln options.

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

* 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

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

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

* 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

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

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

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

Re: [OctDev] convhulln options.

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

* 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

Re: [OctDev] convhulln options.

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

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.

Re: [OctDev] test scripts

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

On Dec 16, 2003, at 10:28 PM, Paul Kienzle wrote:
>
>>   Looks like a huge task. It may be easier psychologically to add a
>> test to a function when a bug has been fixed on it.
>
> Although huge, the project is very distributable.   Just add a
> couple of lines to an existing script file and you have a test.
> That's why I think we should ask the community for help.  You
> never know --- some of them may decide to contribute more!

Just to make the project bigger, all doc strings should be texinfo-ized,
particularly those for functions which belong in the octave-core.

Paul Kienzle
pki...@us...

Re: [OctDev] test scripts

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

On Dec 16, 2003, at 7:23 PM, Etienne Grossmann wrote:

>
>   Hi all,
>
> that's a good idea. However, that would be a huge table until most
> tests scripts are written: There are 26 dirs in main, w/ >400 m-files
> very few of which have a test.

Maybe a separate page for each directory.  It is up to the
directory coordinator to decide how they want to organize it.

>
>   Also, how should we name test files? I use test_XYZ.m or
> test_XYZ_1.m, test_XYZ_2.m ... to test XYZ_m. Would using test
> subdirectories in each dir reduce clutter?

Embed the tests in the script files.  See 'help test' for the
method.

>
>   How should tests behave? I set a 'ok' variable to 1 if success, 0 if
> failure. Test produces terminal output if a variable 'verbose' is
> set.

I capture the test results to a log file and keep track of how many
passed and how many failed.

>
>   Running the tests automatically? Should probably be a non-octave
> script, as some tests may crash octave.

I thought about this a bit.  Currently if octave crashes, you will need
to comment out the crashing test and restart from scratch.  Admittedly
not the best, but then octave doesn't crash much :-)

Another approach would be to run octave from each directory rather
than from the start.  At least that way, you will only have to rerun the
directory, not the whole tree.

A more sophisticated approach would be to write a line number
before each test script.  Then if octave crashes, we can simply
skip the tests that have already been completed and continue.
That's a project for another day.

>   Looks like a huge task. It may be easier psychologically to add a
> test to a function when a bug has been fixed on it.

Although huge, the project is very distributable.   Just add a
couple of lines to an existing script file and you have a test.
That's why I think we should ask the community for help.  You
never know --- some of them may decide to contribute more!

Paul Kienzle
pki...@us...

Re: [OctDev] test scripts

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

  Hi all,

that's a good idea. However, that would be a huge table until most
tests scripts are written: There are 26 dirs in main, w/ >400 m-files
very few of which have a test.

  Also, how should we name test files? I use test_XYZ.m or
test_XYZ_1.m, test_XYZ_2.m ... to test XYZ_m. Would using test
subdirectories in each dir reduce clutter?

  How should tests behave? I set a 'ok' variable to 1 if success, 0 if
failure. Test produces terminal output if a variable 'verbose' is
set.

  Running the tests automatically? Should probably be a non-octave
script, as some tests may crash octave.

  Looks like a huge task. It may be easier psychologically to add a
test to a function when a bug has been fixed on it.

  Just my 2c,

  Etienne

On Tue, Dec 16, 2003 at 05:29:02PM -0500, Paul Kienzle wrote:
# Hi,
# 
# I've been working on exercising the test scripts that already
# exist in octave-forge.  I would like for someone to volunteer
# to organize the gathering of more tests.  
# 
# The simplist solution would be to set up a wiki page with 
# three columns:
# 
# 	directory coordinator missing
# 
# where directory is the name of the directory, coordinator is
# the sflogin name of someone with octave-forge write privileges
# and status is a list of functions which don't have adequate
# test coverage.  Once every directory has a coordinator, send
# a message to help-octave requesting that users should check 
# the wiki, put a star by the function(s) they can write tests 
# for, write the tests, then submit patches to
# coo...@us.... 
# 
# Thanks in advance,
# 
# Paul Kienzle
# pki...@us...
# 
# BTW, tests just got easier, since they are now installed 
# with mark_as_command.
# 
# 
# -------------------------------------------------------
# This SF.net email is sponsored by: IBM Linux Tutorials.
# Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
# Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
# Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

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

[OctDev] test scripts

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

Hi,

I've been working on exercising the test scripts that already
exist in octave-forge.  I would like for someone to volunteer
to organize the gathering of more tests.  

The simplist solution would be to set up a wiki page with 
three columns:

	directory coordinator missing

where directory is the name of the directory, coordinator is
the sflogin name of someone with octave-forge write privileges
and status is a list of functions which don't have adequate
test coverage.  Once every directory has a coordinator, send
a message to help-octave requesting that users should check 
the wiki, put a star by the function(s) they can write tests 
for, write the tests, then submit patches to
coo...@us.... 

Thanks in advance,

Paul Kienzle
pki...@us...

BTW, tests just got easier, since they are now installed 
with mark_as_command.

Re: [OctDev] Re: sparse tests

[Andy A. <ad...@si...>]

On Sat, 13 Dec 2003, Paul Kienzle wrote:

> On Dec 13, 2003, at 1:48 PM, Andy Adler wrote:
>
> > For sin, sinh, tan, erf, abs, conj, floor, round, ceil, fix,
> >     tanh, sign, asin, asinh, atan, sqrt (any more?)
> > in which func(0)= 0, I could write a template that does
> > the function on each non-sparse element. Then we could define
> > sp_func for each, which could dispatch for sparse operands.
>
> These are easy enough to add as scripts:
>
> function x = spfn(fn,y)
>     [i,j,v,m,n]=spfind(y);
>     x = sparse(i,j,feval(fn,v),m,n);
> end
>
> Or if they want ease of use:
>
> ## PKG_ADD: dispatch('sin','spsin','sparse');
> ## PKG_ADD: dispatch('sin','spsin','complex_sparse');
> function x=spsin(y), x=spfn('sin',y); end

This is a great idea.
Any objection to my adding this to sparse
for these functions?

Andy

Re: [OctDev] Re: sparse tests

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

On Dec 13, 2003, at 1:48 PM, Andy Adler wrote:

> On Sat, 13 Dec 2003, Paul Kienzle wrote:
>
>> It would be a little more convincing if other operators didn't
>> convert to full as necessary, like + and /.  I haven't checked
>> functions like cos/sin though.
>
> I didn't think + converted to full. "/" will, though. I didn't
> think it was used enough to bother implementing.
>
> All the advanced functions (sin/cos etc.) will convert to full.
>
> For cos it doesn't make sense to have a sparse implementation
> since cos(0)=1. ie. the matrix will become filled with ones.
>
> For sin, sinh, tan, erf, abs, conj, floor, round, ceil, fix,
>     tanh, sign, asin, asinh, atan, sqrt (any more?)
> in which func(0)= 0, I could write a template that does
> the function on each non-sparse element. Then we could define
> sp_func for each, which could dispatch for sparse operands.
>
> Is this worth the work?

These are easy enough to add as scripts:

function x = spfn(fn,y)
    [i,j,v,m,n]=spfind(y);
    x = sparse(i,j,feval(fn,v),m,n);
end

Or if they want ease of use:

## PKG_ADD: dispatch('sin','spsin','sparse');
## PKG_ADD: dispatch('sin','spsin','complex_sparse');
function x=spsin(y), x=spfn('sin',y); end

Re: [OctDev] Re: sparse tests

[Andy A. <ad...@si...>]

On Sat, 13 Dec 2003, Paul Kienzle wrote:

> It would be a little more convincing if other operators didn't
> convert to full as necessary, like + and /.  I haven't checked
> functions like cos/sin though.

I didn't think + converted to full. "/" will, though. I didn't
think it was used enough to bother implementing.

All the advanced functions (sin/cos etc.) will convert to full.

For cos it doesn't make sense to have a sparse implementation
since cos(0)=1. ie. the matrix will become filled with ones.

For sin, sinh, tan, erf, abs, conj, floor, round, ceil, fix,
    tanh, sign, asin, asinh, atan, sqrt (any more?)
in which func(0)= 0, I could write a template that does
the function on each non-sparse element. Then we could define
sp_func for each, which could dispatch for sparse operands.

Is this worth the work?

Andy

Re: [OctDev] Re: sparse tests

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

On Dec 12, 2003, at 10:56 PM, Andy Adler wrote:

> On Thu, 11 Dec 2003, Paul Kienzle wrote:
>
>> The sparse tests at line 240 is failing since sparse(eye(3)).^x does 
>> not
>> fill in the zeros with 1 for x==0 or inf for x<0.  This is 
>> bug-compatible
>> with matlab.  Shall we correct it?
>
> This is bug compatible with Matlab. I remember asking on this list
> about this (mis) feature when I was developing it.
>
> Advantages of the matlab way:
>  - faster (ignore everything corresponding to a zero)
>  - compatible
>
> Advantages of the correct way:
>  - correct ;-)
>
> I agree with John that introducing "feature" variables is a bad
> idea. I say we leave it and put a _big_bad_warning_ somewhere.

It would be a little more convincing if other operators didn't
convert to full as necessary, like + and /.  I haven't checked
functions like cos/sin though.

BTW, this came up in the context of minimizing the warnings
produced by the sparse tests.  I've got it down to almost
nothing now.

- Paul

Re: [OctDev] convhulln options.

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

* 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

[OctDev] Re: sparse tests

[Andy A. <ad...@si...>]

On Thu, 11 Dec 2003, Paul Kienzle wrote:

> The sparse tests at line 240 is failing since sparse(eye(3)).^x does not
> fill in the zeros with 1 for x==0 or inf for x<0.  This is bug-compatible
> with matlab.  Shall we correct it?

This is bug compatible with Matlab. I remember asking on this list
about this (mis) feature when I was developing it.

Advantages of the matlab way:
 - faster (ignore everything corresponding to a zero)
 - compatible

Advantages of the correct way:
 - correct ;-)

I agree with John that introducing "feature" variables is a bad
idea. I say we leave it and put a _big_bad_warning_ somewhere.

Andy

[OctDev] BUG: imshow gamma problems [Was imread feature request]

[Mike P. <mik...@fs...>]

Thus spake Mike Perry (mik...@fs...):

> > It saves us work if convert is there.  Is it much slower than
> > using readjpg or readpng directly?
> 
> Using convert is hella slow.. The vast majority of time spent in
> training my face recognition program is spent reading in images..
> 
> Can't say if the other options would be any better though.

This reminds me.. when you use imshow on black and white images, the
gamma gets screwed up. Attached is a gif you can see this happen
with. Simply 'imshow(imread('subject01.gif'))' and what you get is
really washed out. I believe this is a bug in imshow not imread though,
as imwrite will not write a washed out image. 

Furthermore, calling imagemagick's 'display' directly produces a normal
image as well.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

[OctDev] Re: Feature request: imread matlab compatibility

[Mike P. <mik...@fs...>]

Thus spake Paul Kienzle (pki...@us...):

> On Dec 11, 2003, at 9:55 PM, Andy Adler wrote:
> 
> >1. Is the current imread implementation OK?
> >   ie. are we satisfied with piping stuff through the
> >       imagemagick 'convert'?
> 
> It saves us work if convert is there.  Is it much slower than
> using readjpg or readpng directly?

Using convert is hella slow.. The vast majority of time spent in
training my face recognition program is spent reading in images..

Can't say if the other options would be any better though.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs