Hello,
I am running octave 2.0.9 on Linux 2.0.30. I have read the faq on minimizing the differences between octave and matlab, and put the following in my .octaverc file: ^^^^^^^^^^^^^^^ PS1 = '>> '; PS2 = ''; default_save_format = 'mat-binary'; define_all_return_values = 1; do_fortran_indexing = 1; empty_list_elements_ok = 1; implicit_str_to_num_ok = 1; ok_to_lose_imaginary_part = 1; page_screen_output = 0; prefer_column_vectors = 0; prefer_zero_one_indexing = 1; print_empty_dimensions = 0; treat_neg_dim_as_zero = 1; warn_function_name_clash = 0; gnuplot_has_frames = 1; gnuplot_has_multiplot = 1; whitespace_in_literal_matrix = 'traditional'; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My problem is that some matlab files still do not work properly under octave. For example, the function psd in Matlab's signal processing toolbox. For example, the following two lines which work okay in Matlab 4.x ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6 a = randn(100,1) pa = psd(a,16,1,16) gives the following errors: error: octave_base_value::string_value(): wrong type argument `matrix' error: eval: expecting string argument error: evaluating index expression near line 42, column 43 error: evaluating assignment expression near line 42, column 42 error: called from `psd' in file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Are there any more variables that I have to set? Thanks. Hari. |
On 19-Nov-1997, Gopalakrishnan Harikumar <[hidden email]> wrote:
| I am running octave 2.0.9 on Linux 2.0.30. | I have read the faq on minimizing the differences | between octave and matlab, and put the following in | my .octaverc file: Unfortunately, the FAQ is horribly out of date (would anyone be interested in updating and maintaining it?). Running Octave with th --traditional option provides the most compatible settings. | My problem is that some matlab files still do | not work properly under octave. For example, the function | psd in Matlab's signal processing toolbox. | | For example, the following two lines which work okay in Matlab 4.x | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6 | | a = randn(100,1) | pa = psd(a,16,1,16) | | gives the following errors: | | error: octave_base_value::string_value(): wrong type argument `matrix' | error: eval: expecting string argument | error: evaluating index expression near line 42, column 43 | error: evaluating assignment expression near line 42, column 42 | error: called from `psd' in file | | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | Are there any more variables that I have to set? I can't tell if this is a bug, because I don't know what psd is supposed to do. If you think there is a bug, please send a complete bug report to to [hidden email]. Please DO NOT send portions of functions from a Matlab toolbox as a way of explaining what is going wrong, as I suspect your license agreement doesn't permit redistribution of the Matlab toolboxes. Thanks, jwe |
> On 19-Nov-1997, Gopalakrishnan Harikumar <[hidden email]> wrote: > > | My problem is that some matlab files still do > | not work properly under octave. For example, the function > | psd in Matlab's signal processing toolbox. > | > | For example, the following two lines which work okay in Matlab 4.x > | > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6 > | > | a = randn(100,1) > | pa = psd(a,16,1,16) > | > | gives the following errors: > | > | error: octave_base_value::string_value(): wrong type argument `matrix' > | error: eval: expecting string argument > | error: evaluating index expression near line 42, column 43 > | error: evaluating assignment expression near line 42, column 42 > | error: called from `psd' in file This is a problem I've encountered as well. The cause is a Matlab script called "optargs" which is supposed to return a string for use by "eval". The "optargs" script is used by a number of scripts other than "psd". Under Octave, "optargs" can return a vector of character codes rather than a string. I believe this is due to a statement in which a string may be concatenated with a variable equal to the empty vector ([]). 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 know what the aesthetics or practicalities are of changing Octave's behaviour in this respect (setstr_empty_vector=1 ?). Hope this helps. Richard. P.S. Let me take this opportunity to say I'm a big fan of Octave and to congratulate John on his responsiveness to user feedback. ------------------------------------------------------------------------------- Richard Shaw Robat Project RA (Bat Lab (School of Biol. Sci.), CCR (Dept. of Engineering)) Web page : http://www.bio.bris.ac.uk/research/bats/richard/Personal.html phone : (+44)(0) 117 9289000 ext 3796 or 3868 fax : (+44)(0) 117 9257374 |
On 20-Nov-1997, Richard J. Shaw <[hidden email]> 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 |
In reply to this post by Gopalakrishnan Harikumar
On 24-Nov-1997, Heber Farnsworth <[hidden email]> wrote:
| I agree. Returning a numeric result is the exception. It is much | more common (in my work) that I want to be able to enter a string | and concatenate strings and get another string. I believe that concatenating two strings works fine. It's just a question of what happens when someone mixes strings and numbers (apparently most often by growing a string starting with an empty matrix). In any case, this is fixed for the next release. * The new built-in variable `implicit_num_to_str_ok' controls whether Octave converts expressions like `[97, 98, 99, "123"]' to strings. The default value is 0 unless you use --traditional. octave:1> implicit_str_to_num_ok = 0;, implicit_num_to_str_ok = 0; octave:2> [97, 98, 99, '123'] error: invalid conversion from string to real matrix error: invalid conversion from string to real matrix octave:2> implicit_str_to_num_ok = 0; implicit_num_to_str_ok = 1; octave:3> [97, 98, 99, '123'] ans = abc123 octave:4> implicit_str_to_num_ok = 1; implicit_num_to_str_ok = 0; octave:5> [97, 98, 99, '123'] ans = 97 98 99 49 50 51 octave:6> implicit_str_to_num_ok = 1; implicit_num_to_str_ok = 1; octave:7> [97, 98, 99, '123'] ans = abc123 The defaults for these variables are both 0 unless you use --traditional. Then the defaults are both 1. jwe |
Free forum by Nabble | Edit this page |