Re: Octave/Matlab compatibility

[John W. Eaton]

On 20-Nov-1997, Richard J. Shaw <address@hidden> wrote:

| Under Octave the behaviour is as follows :-
| 
| octave:1> fred = [[], "hello"]
| fred =
| 
|   104  101  108  108  111
| 
| whereas under Matlab, fred becomes the string "hello".
| 
| It should be possible to fix this problem (on a one-off basis) by
| replacing use of [] with '' :-
| 
| octave:2> fred = ['', "hello"]
| fred = hello
| 
| which would be compatible with Matlab usage (single not double quotes!).

(I don't think it should matter to Octave whether you use single or
double quotes.)

I have known about this `problem' for quite some time.  I'll consider
trying to fix it now, even at the risk of adding another preference
variable.  In this case, I don't think another `mode' will hurt too
much, because it shouldn't be too hard to write code that will work
correctly no matter what the setting of the new variable is -- no one
should be writing new code for Octave that creates strings from a
combination of numbers and strings as in the expression above unless
they also use setstr() or some equivalent.

Currently, we have implicit_str_to_num_ok to handle things like

  [u,s,v] = svd ('foo')

in a way that is compatible with Matlab.

Back when Octave didn't support character matrices/string vectors, I
also used implicit_str_to_num_ok to decide whether

   [102, 111, 111, 'bar']

would result in an error or the vector [102, 111, 111, 98, 97, 114].
Now that Octave can handle character matrices/string vectors, I
suppose I could add implicit_num_to_str_ok to handle this case in a
Matlab-compatible way.  Setting the variable to 1 would cause the above
expression to return 'foobar', and for things like [[], "hello"] to
return "hello" (with or without a warning, depending on the value of
empty_list_elements_ok).  Is that a reasonable solution?  It will mean
that the above expression will not produce a numeric result, but I
think that's unlikely to break much (if any) existing code.

Comments?

Thanks,

jwe