From octave-maintainers-request at bevo dot che dot wisc dot edu Wed May 15 12:00:35 2002 Subject: RE: daspk in CVS From: "Lippert, Ross A." To: octave-maintainers mailing list Date: Wed, 15 May 2002 13:00:27 -0400 I do not think that the daspk directory has been added to the CVS main branch. It does not show up either on the web-cvs or when I cvs update my octave directory. However, the makefile and some stuff in liboctave appear to be assuming it. -r -----Original Message----- From: John W. Eaton [mailto:jwe at bevo dot che dot wisc dot edu] Sent: Wednesday, May 15, 2002 12:37 PM To: Paul Kienzle Cc: octave-maintainers mailing list Subject: Re: cell arrays and structure arrays On 15-May-2002, Paul Kienzle wrote: | Instead you need some way to | precalculate the resulting type and dimension, build a new matrix | of that type, and insert appropriate octave values into the indices | of that matrix. Then you could write tree_matrix as follows: | | [...] I think this is close to the way it works now, but it is limited to specific built-in types and the knowledge about what types are compatible is all embedded in the classes in pt-mat.cc. | With automatic type conversion, my code will do something different than a | series of horzcat/vertcat calls. Consider the following: | | [ 1, 2, { 3, 4} ] | | With horzcat, this is | | horzcat(horzcat(1,2), { 3, 4 } ) | | which would be | | { [1, 2], 3, 4 } | | But as I've written it, this will be | | { 1, 2, 3, 4 } | | Maybe that's why matlab says: | | >> [ 1, 2, { 3, 4} ] | ??? Error using ==> horzcat | Conversion to cell from double is not possible. But Matlab does allow conversions when the concatenation contains numeric and string types: >> [ 'f', 111, 111 ] ans = foo and >> [ 111, 111, 'f' ] ans = oof Perhaps they decided that automatic type conversions were not such a good idea, but kept the numeric to string conversion for backward compatibility? jwe