RE: daspk in CVS

[Lippert, Ross A.]

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:address@hidden
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 <address@hidden> 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