From: <pki...@co...> - 2004-08-24 21:33:06
|
It doesn't matter what field you use. Off hand I would suggest overriding Octave's 'class' function so that if it is given a struct as the first argument, it checks for a secret field name (e.g., __class) and prints that, or prints 'struct' if no secret field exists. If given two arguments, then set s.__class to the second argument, which should be the class name. That will make the interface similar, even if the underlying implementation does not yet support automatic dispatching into the @class directory. You could implement that too if you were so inclined using find_in_loadpath([class,'.m']) to find the directory, then creating a dispatch off struct for every m-file and oct-file in that directory. Octave supports structure arrays, at laeast in recent versions. What syntax are you using to index and assign them? - Paul > On dj, 2004-08-19 at 04:13, pki...@co... wrote: > > I don't think there is any point in naming them strel_xxx. I don't think > these functions exist elsewhere in octave/octave-forge. > > > > - Paul > > > > Ok! > > I'm just naming them as they should. BTW, I'm using a @strel directory > to have everything in place already. > > To simulate classes I just use structs which have a field "type" set to > "strel", which helps identifying it. Do you thing this is ok? > > I also have the problem that I can't use structs as elements in an > array; so I've replaced all arrays of strel objects to cell arrays of > strel objects, which is ugly. > > BTW, in addition of decomposition of structuring elements, I'm finding > articles of specific dilate or erode algorithms for line structuring > elements or other types of structuring elements, which are supposed to > be much faster that using a general-neighbourhood algorithm (even if > decomposed smartly). So I plan to store the shape in the strel object so > we can use these algorithms in a future and speed up things. > > Regards, > -- > Josep Monés i Teixidor > Clau GnuPG: gpg --recv-keys 80E85CC4 > |