octave-dev — GNU Octave developers' list

[OctDev] Re: spliting DOCSTRINGS octave-lang

[Jorge B. de A. <fic...@so...>]

Excuse me

Is "octave -q" and not "octave-d"

[]=B4s


Em Fri 09 Dec 2005 17:41, Jorge Barros de Abreu escreveu:
> Hi for All.
>
> At this week i update octave o my computer from 2.1.64 to 2.9.4 and
> discovery that the script split_docstrings do not work under 2.9.4 then no
> not update octave-lang-cvs
> (
> http://cvs.sourceforge.net/viewcvs.py/octave/octave-lang/admin/split_docs=
tr
>ings?rev=3D1.1.1.1&view=3Dlog ) with the latest version of some help file =
que
> was changed in octave.org.cvs.
>
> Can anyone help me about this???
>
> The "octave -d" command behavior was changed????
>
> Thanks

=2D-=20
Data Estelar 2453714.354363
http://www.solar.com.br/~ficmatin
Desejo-lhe Paz, Vida Longa e Prosperidade.
S=E3o Bem Vindas Mensagens no Formato Texto Gen=E9rico com Acentos.

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

[William P. Y. H. <wil...@gm...>]

On a second thought, let's not modify the license text ;)

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

[William P. Y. H. <wil...@gm...>]

On 12/9/05, David Bateman <Dav...@mo...> wrote:

> >Yes, I also think the above should work (logical -> numeric). Also, I
> >think char arrays should be allowed (using ascii). What do you think?
> >
> >
> >
> Promotion of type is implicit in the concatenation operation. If cat
> allows it so should cell2mat in my opinion. Therefore just letting cat
> generate the error messages for an illegal concatenation of types makes
> sense to me, as it will report the two offending types in the
> concatenation operation. I believe this means that cell2mat needs no
> changes...
>

OK, so I wouldn't have to change the inner workings of cell2mat.m. But
I've modified the license string ("This program" -> "Octave") and
coding style to better match Octave's coding style, so I would need
Laurent to approve it (is his email correct?).

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

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

William Poetra Yoga Hadisoeseno wrote:

>On 12/8/05, David Bateman <Dav...@mo...> wrote:
>  
>
>>It just does a cat along the last dimension of the cell array so that
>>for example
>>
>>c = {[1], [2 3 4]; [5; 9], [6 7 8; 10 11 12]};
>>
>>becomes
>>
>>c1 = {[1, 2, 3, 4] ; [5 6 7 8; 9 10 11 12]}
>>
>>after the first interation. For 2-D there is only one iteration of the
>>loop and the last cat operation is handled by "m = cat (1, c1{:})".
>>
>>    
>>
>
>OK, thanks :)
>
>  
>
>>The fact is I'm not sure what you are trying to achieve with your
>>changes. What was wrong with the previous implementation? cell2mat.m
>>itself needs no argument dimension checking, as if the arguments are
>>wrong, the dimension checking in the "cat" operation will cause an error
>>and exit from cell2mat. For example with the current version of cell2mat
>>I get the following, when passing it matrices that can't be concatenated.
>>
>>octave:2> C = {[1], [2 3 4]; [5; 9; 13], [6 7 8; 10 11 12]};
>>octave:3> cell2mat(C)
>>error: cat: dimension mismatch
>>error: evaluating assignment expression near line 65, column 14
>>error: evaluating for command near line 64, column 5
>>error: evaluating for command near line 60, column 3
>>error: called from `cell2mat' in file
>>`/opt/octave-2.9/share/octave/2.9.4/site/m/octave-forge/cell/cell2mat.m'
>>
>>    
>>
>
>Yes, but I wanted to make sure cell2mat.m checks for every restriction
>specified in the Matlab documentation (same data type, can concatenate
>into a hyperrectangle, matching dimensions for neighbouring cells).
>Instead of letting cat print out the error, I think we should let
>cell2mat do it. For example:
>
>octave:21> C = {[1], [2 3 4]; [5; 9; 13], [6 7 8; 10 11 12]};
>octave:22> cell2mat(C)
>error: cell2mat: the contents of c must be able to concatenate into a
>hyperrectangle
>error: evaluating if command near line 75, column 13
>error: evaluating if command near line 72, column 11
>error: evaluating for command near line 69, column 9
>error: evaluating if command near line 67, column 7
>error: evaluating for command near line 66, column 5
>error: evaluating if command near line 54, column 3
>error: called from `cell2mat' in file `/home/william/cell2mat.m'
>
>Admittedly the checking part is inefficient and ugly, so I'm asking
>for some help here ;)
>
>  
>
Again, why? Here is matlab's output

 >> C = {[1], [2, 3, 4; 6 7 8]; [5; 9],[10 11 12]}
 >> cell2mat(C)
??? Error using ==> cat
CAT arguments dimensions are not consistent.

Error in ==> cell2mat at 92
        m{n} = cat(2,c{n,:});

The error message seems to indicate that matlab just lets cat generate 
the error as well.

>>Note that although
>>
>>C = {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
>>cell2mat(C)
>>
>>    
>>
>
>This one works in the old cell2mat, but not in the new cell2mat. Do
>you think it should (work)? I mean, by the Matlab documentation, [1,
>2] and [5; 9] are neighbours, but they differ in size (1x2 and 2x1,
>while the neighbouring dimension is 1, thus while we ignore the first
>dimension, we are comparing 2 to 1). How does Matlab behave?
>
>  
>
Matlab doesn't respect their own documentation either

 >> C = {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
 >> cell2mat(C)

ans =

     1     2     3     4
     5     6     7     8
     9    10    11    12

This is with R14sp2..

>>works, the generalization
>>
>>C = {[1], [2, 3, 4; 6 7 8]; [5; 9],[10 11 12]}
>>cell2mat(C)
>>
>>doesn't, even though conceptually the meaning is clear in terms of the
>>hyper-rectangle. In general there must be a grid in the
>>hyper-rectangular along which all matrices fill the elements of this
>>grid. Matlab has the same behaviour.
>>
>>    
>>
>
>I didn't realize the importance of the sentence "for each pair of
>neighboring cells, the dimensions of the cells' contents must match,
>excluding the dimension in which the cells are neighbors" until I read
>your mail. I've added this item in the documentation (new file is
>attached). Yes, your view of a "grid" is consistent with the Matlab
>documentation.
>
>By the way, I haven't implemented the "same data type" restriction.
>Should cell2mat work that way? I mean, intuitively, concatenating
>logical arrays with double arrays should at least work. How does
>Matlab behave? Matlab's documentation itself says that c must have
>contents of the same data type.
>
>  
>
 >> C = {[1;2],ones(2,2)==1}

C =

    [2x1 double]    [2x2 logical]

 >> cell2mat(C)
??? Error using ==> cell2mat
All contents of the input cell array must be of the same data type.

However, this seems stupid to me, as logical arrays are supposed to be 
promoted to double in normal usage... I'd prefer that the above remained 
legal..

Regards
David

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +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] Proposed changes to cell2mat and inclusion in Octave

[William P. Y. H. <wil...@gm...>]

On 12/8/05, David Bateman <Dav...@mo...> wrote:
> It just does a cat along the last dimension of the cell array so that
> for example
>
> c =3D {[1], [2 3 4]; [5; 9], [6 7 8; 10 11 12]};
>
> becomes
>
> c1 =3D {[1, 2, 3, 4] ; [5 6 7 8; 9 10 11 12]}
>
> after the first interation. For 2-D there is only one iteration of the
> loop and the last cat operation is handled by "m =3D cat (1, c1{:})".
>

OK, thanks :)

> The fact is I'm not sure what you are trying to achieve with your
> changes. What was wrong with the previous implementation? cell2mat.m
> itself needs no argument dimension checking, as if the arguments are
> wrong, the dimension checking in the "cat" operation will cause an error
> and exit from cell2mat. For example with the current version of cell2mat
> I get the following, when passing it matrices that can't be concatenated.
>
> octave:2> C =3D {[1], [2 3 4]; [5; 9; 13], [6 7 8; 10 11 12]};
> octave:3> cell2mat(C)
> error: cat: dimension mismatch
> error: evaluating assignment expression near line 65, column 14
> error: evaluating for command near line 64, column 5
> error: evaluating for command near line 60, column 3
> error: called from `cell2mat' in file
> `/opt/octave-2.9/share/octave/2.9.4/site/m/octave-forge/cell/cell2mat.m'
>

Yes, but I wanted to make sure cell2mat.m checks for every restriction
specified in the Matlab documentation (same data type, can concatenate
into a hyperrectangle, matching dimensions for neighbouring cells).
Instead of letting cat print out the error, I think we should let
cell2mat do it. For example:

octave:21> C =3D {[1], [2 3 4]; [5; 9; 13], [6 7 8; 10 11 12]};
octave:22> cell2mat(C)
error: cell2mat: the contents of c must be able to concatenate into a
hyperrectangle
error: evaluating if command near line 75, column 13
error: evaluating if command near line 72, column 11
error: evaluating for command near line 69, column 9
error: evaluating if command near line 67, column 7
error: evaluating for command near line 66, column 5
error: evaluating if command near line 54, column 3
error: called from `cell2mat' in file `/home/william/cell2mat.m'

Admittedly the checking part is inefficient and ugly, so I'm asking
for some help here ;)

> Note that although
>
> C =3D {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
> cell2mat(C)
>

This one works in the old cell2mat, but not in the new cell2mat. Do
you think it should (work)? I mean, by the Matlab documentation, [1,
2] and [5; 9] are neighbours, but they differ in size (1x2 and 2x1,
while the neighbouring dimension is 1, thus while we ignore the first
dimension, we are comparing 2 to 1). How does Matlab behave?

> works, the generalization
>
> C =3D {[1], [2, 3, 4; 6 7 8]; [5; 9],[10 11 12]}
> cell2mat(C)
>
> doesn't, even though conceptually the meaning is clear in terms of the
> hyper-rectangle. In general there must be a grid in the
> hyper-rectangular along which all matrices fill the elements of this
> grid. Matlab has the same behaviour.
>

I didn't realize the importance of the sentence "for each pair of
neighboring cells, the dimensions of the cells' contents must match,
excluding the dimension in which the cells are neighbors" until I read
your mail. I've added this item in the documentation (new file is
attached). Yes, your view of a "grid" is consistent with the Matlab
documentation.

By the way, I haven't implemented the "same data type" restriction.
Should cell2mat work that way? I mean, intuitively, concatenating
logical arrays with double arrays should at least work. How does
Matlab behave? Matlab's documentation itself says that c must have
contents of the same data type.

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

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

William Poetra Yoga Hadisoeseno wrote:

>The blkdiag.m file I imported into Octave is dependent on cell2mat,
>but I think it's not quite ready for inclusion into Octave yet. So I
>modified the file (attached). Maybe the original author (Laurent
>Mazet) and others would like to comment on it before I post it on
>bu...@oc...?
>
>Due to my lack of intelligence, I've so far failed to completely
>understand the following code by Laurent (hey, but it works!) (it's
>been reformatted):
>
>for p = (ndims (c)):-1:2,
>  sz = size (c);
>  sz(end) = 1;
>  c1 = cell (sz);
>  for q = 1:(prod (sz))
>    c1{q} = cat (p, c{q:(prod (sz)):end});
>  endfor
>  c = c1;
>endfor
>m = cat (1, c1{:});
>
>Can anyone explain it to me?
>
>Note: I changed the wording of the license from "this program" to
>"Octave". Is it OK?
>
>--
>William Poetra Yoga Hadisoeseno
>
>  
>
It just does a cat along the last dimension of the cell array so that 
for example

c = {[1], [2 3 4]; [5; 9], [6 7 8; 10 11 12]};

becomes

c1 = {[1, 2, 3, 4] ; [5 6 7 8; 9 10 11 12]}

after the first interation. For 2-D there is only one iteration of the 
loop and the last cat operation is handled by "m = cat (1, c1{:})".

The fact is I'm not sure what you are trying to achieve with your 
changes. What was wrong with the previous implementation? cell2mat.m 
itself needs no argument dimension checking, as if the arguments are 
wrong, the dimension checking in the "cat" operation will cause an error 
and exit from cell2mat. For example with the current version of cell2mat 
I get the following, when passing it matrices that can't be concatenated.

octave:2> C = {[1], [2 3 4]; [5; 9; 13], [6 7 8; 10 11 12]};
octave:3> cell2mat(C)
error: cat: dimension mismatch
error: evaluating assignment expression near line 65, column 14
error: evaluating for command near line 64, column 5
error: evaluating for command near line 60, column 3
error: called from `cell2mat' in file 
`/opt/octave-2.9/share/octave/2.9.4/site/m/octave-forge/cell/cell2mat.m'

Note that although

C = {[1, 2], [3, 4]; [5; 9],[6 7 8; 10 11 12]};
cell2mat(C)

works, the generalization

C = {[1], [2, 3, 4; 6 7 8]; [5; 9],[10 11 12]}
cell2mat(C)

doesn't, even though conceptually the meaning is clear in terms of the 
hyper-rectangle. In general there must be a grid in the 
hyper-rectangular along which all matrices fill the elements of this 
grid. Matlab has the same behaviour.

Regards
David

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +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] Proposed changes to cell2mat and inclusion in Octave

[William P. Y. H. <wil...@gm...>]

The blkdiag.m file I imported into Octave is dependent on cell2mat,
but I think it's not quite ready for inclusion into Octave yet. So I
modified the file (attached). Maybe the original author (Laurent
Mazet) and others would like to comment on it before I post it on
bu...@oc...?

Due to my lack of intelligence, I've so far failed to completely
understand the following code by Laurent (hey, but it works!) (it's
been reformatted):

for p =3D (ndims (c)):-1:2,
  sz =3D size (c);
  sz(end) =3D 1;
  c1 =3D cell (sz);
  for q =3D 1:(prod (sz))
    c1{q} =3D cat (p, c{q:(prod (sz)):end});
  endfor
  c =3D c1;
endfor
m =3D cat (1, c1{:});

Can anyone explain it to me?

Note: I changed the wording of the license from "this program" to
"Octave". Is it OK?

--
William Poetra Yoga Hadisoeseno

[OctDev] gget.m update

[Carl O. <cos...@ya...>]

Hello,

I have updated the 2003-03-13 gget.m function in a few significant
ways:
1. Instead of constantly opening and seeking the EOF tag at the end of
the gnuplot optfile, the new function just looks for a second "end
signal" file to be created.
2. Parsing of the gnuplot optfile is simplified.
3. Added the ability for multiple argument processing (varargin,
varargout) so that multiple values may be read at the same time.
4. For portability, uses the built-in unlink function to delete files

Sorry, the patch would be twice as big as the m file so I'll just send
the file.




		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: [OctDev] license.m

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

On Nov 28, 2005, at 10:49 AM, William Poetra Yoga Hadisoeseno wrote:

> On 11/28/05, Paul Kienzle <pki...@us...> wrote:
>>
>> The alternative is to build infrastructure so that octave-forge
>> doesn't shadow any octave functions unless we tell it to
>> in the build/install scripts.  If anyone wants to tackle
>> this, keep in mind that we want to support testing before
>> installation, which means installing all the files we want
>> to keep into a temporary build directory.  I think
>> converting each subdirectory to support S=F8ren's packaging
>> system (extended as necessary) is the best way to go.
>>
>
> Yes, I think this is good, because we wouldn't need to worry about old
> octave-forge functions shadowing new octave functions. I think a
> script can do this, and it can also help us when we want to check for
> (and remove) obsolete functions in octave-forge.
>
> I've heard about this packaging system before, but I haven't checked
> it out yet. Maybe you can put a temporary "freeze" on the cvs
> repository, checkout the latest version, make the changes, empty the
> repository, then upload the new files?

No freeze required, just create a branch for for 2.1.x support.

Also, no need to delete and reinsert since it will just be
adding packaging info. I don't want to lose the file change history.

- Paul

Re: [OctDev] license.m

[William P. Y. H. <wil...@gm...>]

On 11/28/05, Paul Kienzle <pki...@us...> wrote:
> William,
>
> Can you please post functions which implement base matlab
> function to bu...@oc....  John expressed an interest
> in having more complete coverage in time for the Octave 3.0
> release.
>
> If he does not want them or does not act on them in a
> reasonable time (e.g., six weeks) then I'm happy to
> include them in octave-forge, but I would prefer to
> give John first right of refusal (I will need reminding).
>

OK, I've posted them on bu...@oc....

> The alternative is to build infrastructure so that octave-forge
> doesn't shadow any octave functions unless we tell it to
> in the build/install scripts.  If anyone wants to tackle
> this, keep in mind that we want to support testing before
> installation, which means installing all the files we want
> to keep into a temporary build directory.  I think
> converting each subdirectory to support S=F8ren's packaging
> system (extended as necessary) is the best way to go.
>

Yes, I think this is good, because we wouldn't need to worry about old
octave-forge functions shadowing new octave functions. I think a
script can do this, and it can also help us when we want to check for
(and remove) obsolete functions in octave-forge.

I've heard about this packaging system before, but I haven't checked
it out yet. Maybe you can put a temporary "freeze" on the cvs
repository, checkout the latest version, make the changes, empty the
repository, then upload the new files?

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] license.m

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

William,

Can you please post functions which implement base matlab
function to bu...@oc....  John expressed an interest
in having more complete coverage in time for the Octave 3.0
release.

If he does not want them or does not act on them in a
reasonable time (e.g., six weeks) then I'm happy to
include them in octave-forge, but I would prefer to
give John first right of refusal (I will need reminding).

The alternative is to build infrastructure so that octave-forge
doesn't shadow any octave functions unless we tell it to
in the build/install scripts.  If anyone wants to tackle
this, keep in mind that we want to support testing before
installation, which means installing all the files we want
to keep into a temporary build directory.  I think
converting each subdirectory to support S=F8ren's packaging
system (extended as necessary) is the best way to go.

- Paul

On Nov 27, 2005, at 2:12 AM, William Poetra Yoga Hadisoeseno wrote:

> I wrote license.m from the documentation of Matlab 7 (but it's not
> entirely compatible) and I'm attaching it along with this mail. I
> think we can put it in octave-forge ;)
>
> Please discuss and test it :)
>
> --
> William Poetra Yoga Hadisoeseno
> <license.m>=

[OctDev] ver.m

[William P. Y. H. <wil...@gm...>]

The useless functions continue! ;)

Here I've written ver.m, which only supports the basic usage of ver in
Matlab. Please test and comment on it :)

For example, on my machine it displays:

-------------------------------------------------------------------
GNU Octave Version 2.9.4
GNU Octave License: GNU General Public License, Version 2
Operating System: Linux 2.4.30 #1 Sat Jun 18 17:12:41 CST 2005 i686
-------------------------------------------------------------------
octave-forge                           20050613

--
William Poetra Yoga Hadisoeseno

[OctDev] license.m

[William P. Y. H. <wil...@gm...>]

I wrote license.m from the documentation of Matlab 7 (but it's not
entirely compatible) and I'm attaching it along with this mail. I
think we can put it in octave-forge ;)

Please discuss and test it :)

--
William Poetra Yoga Hadisoeseno

[OctDev] Re: tukeywin.m

[Thomas W. <we...@nu...>]

Hi, 

> ## tukeywin Tukey window.
> ##   w =tukeywin(n) returns an n-point Tukey window in a column vector.
> ##
> ##   w = tukeywin(n,r) returns an N-point Tukey window in a column vector.
> ##   A Tukey window is also known as the cosine-tapered window.  The r
> ##   parameter specifies the ratio of taper to constant sections. This ratio
> ##   is normalized to 1 (i.e., 0 < r < 1). If omitted, r is set to 1/2.
> ##
> ##   NOTE: At extreme values of r, the Tukey window degenerates into other
> ##   common windows.
> ##       R = 1 -> Hanning window.
> ##       R = 0 -> boxcar window.
> ##
> ##
> ##
> ##   Reference:
> ##    [1] fredric j. harris [sic], On the Use of Windows for Harmonic Analysis
> ##         with the Discrete Fourier Transform, Proceedings of the IEEE,
> ##         Vol. 66, No. 1, January 1978, Page 67, Equation 38.
This is one to one the comment from "tukeywin.m" as shipped with Matlab
(Release 14, Service Pack 3). Did you copy it?

Regards
	Thomas

[OctDev] tukeywin.m

[Clemens N. <e00...@st...>]

this is the window function tukeywin (gives the same results as matlab)

clemens

Re: [OctDev] octave contribution

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

I believe a partial implementation that can be improved is better than 
nothing at all.

If the function has the same name as a matlab function, then the same 
parameters should return the same results as matlab (unless there is a 
very good reason not to).  You do not need to implement all of matlab 
functionality, and you can include extensions beyond matlab 
functionality. 100% compatibility is not required.

Functions not in matlab are also acceptable if they are broadly useful 
and sometimes even if they are not.

Post the function to the list, and someone will probably add it to the 
archive.  A clear license statement is required (public domain, BSD or 
GPL) as is minimal documentation.  Good documentation helps.  Test 
cases and demos make it easier for me to check that it works on my 
system, and makes it more likely that I will include it.

- Paul

On Nov 24, 2005, at 1:39 PM, Clemens Novak wrote:

> Hi,
>
> my name is Clemens and I'd like to help a bit with octave...  I'm new 
> to this list so please forgive my (possibly) stupid questions.
> How close does octave-forge try to imitate matlab ? i am quite 
> familiar with matlab & recognized quite a lot of functions, but some 
> (and rather simple ones like upsample, downsample,...) seem to be 
> missing ?
>
> I've written a short function which imitates upsample from matlab but 
> only for vectors  (I'm not sure but think in matlab upsample works 
> with matrices as well) Would you accept it as it is or is it more a 
> '100% like matlab or nothing' approach ?
>
> How does the contribution of scripts / functions work ? do i have to 
> commit the stuff via cvs or is it ok to send them to this list ?
>
> Thanks for your help - regards,
>
> Clemens
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

[OctDev] octave contribution

[Clemens N. <e00...@st...>]

Hi,

my name is Clemens and I'd like to help a bit with octave...  I'm new to 
this list so please forgive my (possibly) stupid questions.
How close does octave-forge try to imitate matlab ? i am quite familiar 
with matlab & recognized quite a lot of functions, but some (and rather 
simple ones like upsample, downsample,...) seem to be missing ?

I've written a short function which imitates upsample from matlab but 
only for vectors  (I'm not sure but think in matlab upsample works with 
matrices as well) Would you accept it as it is or is it more a '100% 
like matlab or nothing' approach ?

How does the contribution of scripts / functions work ? do i have to 
commit the stuff via cvs or is it ok to send them to this list ?

Thanks for your help - regards,

Clemens

[OctDev] compiling o-f against 2.1.72

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

Hello,
I have had some trouble getting o-f CVS to compile against Octave 
2.1.72. Has anyone else had problems? Michael

Re: [OctDev] blkdiag.m

[William P. Y. H <wil...@ya...>]

--- Paul Kienzle <pki...@us...> wrote:

> 
> Try it.  If he doesn't want it there, I'm sure he will let us know.
> 
> I guess the bug would be 'missing core function blkdiag'.
> 

OK, I'll do that.

> Sorry.  I didn't understand why you used @size and @isnumeric but not 
> @ndims.  I've read the help for cellfun a little more closely now.
> 

Oh, and I think the version of blkdiag I previously posted had a bug which only
appears when we give it an empty matrix (with a non-empty dimension) and a
non-empty matrix as input. For example, if we do

  blkdiag(ones(1,0),5)

we get

  0 0
  0 5

but it should actually return

  5

right? I've fixed this and added some comments. But I _might_ have introduced
some bugs (I hope not), so please take a look in bu...@oc... :)


William Poetra Yoga Hadisoeseno


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: [OctDev] blkdiag.m

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

On Nov 21, 2005, at 9:03 AM, William Poetra Yoga H wrote:

> --- Paul Kienzle <pki...@us...> wrote:
>
>> Please send the new version of blkdiag to John Eaton for inclusion in 
>> Octave.
>>
>
> As in, posting to bu...@oc...?

Try it.  If he doesn't want it there, I'm sure he will let us know.

I guess the bug would be 'missing core function blkdiag'.

>
>> You should use @ndims rather than 'ndims'.
>>
>
> Why? I think "ndims" is better because it's faster, and it does the 
> same thing, so why not use it?

Sorry.  I didn't understand why you used @size and @isnumeric but not 
@ndims.  I've read the help for cellfun a little more closely now.

> - Paul

Re: [OctDev] blkdiag.m

[William P. Y. H <wil...@ya...>]

--- Paul Kienzle <pki...@us...> wrote:

> Please send the new version of blkdiag to John Eaton for inclusion in 
> Octave.
> 

As in, posting to bu...@oc...?

> You should use @ndims rather than 'ndims'.
> 

Why? I think "ndims" is better because it's faster, and it does the same thing,
so why not use it?

> Please add some test cases to the end, such as
> 
> 	%!assert(blkdiag(1,ones(2),1),[1,0,0,0;0,1,1,0;0,1,1,0;0,0,0,1])
> 

OK. I'll add some tests :)


William Poetra Yoga Hadisoeseno


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: [OctDev] blkdiag.m

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

On Nov 18, 2005, at 10:31 PM, William Poetra Yoga H wrote:

> --- Paul Kienzle <pki...@us...> wrote:
>
>> I'm not sure that use of cell2mat and cellfun improves either speed or
>> readability.
>>
>
> While speed may suffer a bit, I think it's more readable (no need to 
> loop by
> ourselves).
>
>> Regardless, the following test looks incorrect:
>>
>> +  if (! all (cellfun ("ndims", varargin)))
>> +    error ("All of the arguments to blkdiag must be two dimensional
>> matrices");
>> +  endif
>>
>
> Sorry, my fault. I didn't check for n-dimensional arrays (which should 
> return
> an error). Btw, thanks, (I think) I found a few bugs in cellfun.
>
> The new diff to blkdiag.m is attached.

Please send the new version of blkdiag to John Eaton for inclusion in 
Octave.

You should use @ndims rather than 'ndims'.

Please add some test cases to the end, such as

	%!assert(blkdiag(1,ones(2),1),[1,0,0,0;0,1,1,0;0,1,1,0;0,0,0,1])

Thanks,

	- Paul

Re: [OctDev] blkdiag.m

[William P. Y. H <wil...@ya...>]

--- Paul Kienzle <pki...@us...> wrote:

> I'm not sure that use of cell2mat and cellfun improves either speed or 
> readability.
> 

While speed may suffer a bit, I think it's more readable (no need to loop by
ourselves).

> Regardless, the following test looks incorrect:
> 
> +  if (! all (cellfun ("ndims", varargin)))
> +    error ("All of the arguments to blkdiag must be two dimensional 
> matrices");
> +  endif
> 

Sorry, my fault. I didn't check for n-dimensional arrays (which should return
an error). Btw, thanks, (I think) I found a few bugs in cellfun.

The new diff to blkdiag.m is attached.


William Poetra Yoga Hadisoeseno


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: [OctDev] blkdiag.m

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

On Nov 17, 2005, at 2:39 PM, William Poetra Yoga H wrote:

> I've modified the description and the error checking part, but the 
> construction
> procedure remains the same.

I'm not sure that use of cell2mat and cellfun improves either speed or 
readability.

Regardless, the following test looks incorrect:

+  if (! all (cellfun ("ndims", varargin)))
+    error ("All of the arguments to blkdiag must be two dimensional 
matrices");
+  endif

[OctDev] blkdiag.m

[William P. Y. H <wil...@ya...>]

I've modified the description and the error checking part, but the construction
procedure remains the same.


William Poetra Yoga Hadisoeseno


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com