From help-octave-request at bevo dot che dot wisc dot edu Thu Nov 20 13:50:26 1997 Subject: Re: Octave/Matlab compatibility From: "John W. Eaton" To: "Richard J. Shaw" Cc: Gopalakrishnan Harikumar , help-octave@bevo.che.wisc.edu Date: Thu, 20 Nov 1997 13:51:15 -0600 On 20-Nov-1997, Richard J. Shaw 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