[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
more compatibility changes
From: |
John W. Eaton |
Subject: |
more compatibility changes |
Date: |
Fri, 11 Jul 2003 17:17:13 -0500 |
In addition the recent changes I've made to replace variables like
do_fortran_indexing, prefer_column_vectors, implicit_num_to_str_ok,
implicit_str_to_num_ok, ok_to_lose_imaginary_part with other variables
that only control whether warnings are printed, I've just checked in
some more similar changes for
empty_list_elements_ok --> warn_empty_list_elements
resize_on_range_error --> warn_resize_on_range_error
treat_neg_dim_as_zero --> warn_neg_dim_as_zero
I'm also considering the following changes:
* Remove the built-in variables initialize_global_variables and
default_global_variable_value and only implement the Matlab-like
thing of always initializing global variables to [], or make the
default values Matlab compatible.
* Remove the built-in variable default_eval_print_flag and only
implement Matlab-compatible behavior, or make the default value
Matlab compatible.
* Remove the built-in variable whitespace_in_literal_matrix and only
implement Matlab-compatible behavior, or make the default value
"traditional" for Matlab compatibility.
I don't think that eliminating whitespace_in_literal_matrix would
cause trouble for code distributed with Octave since it should
already work with any setting of this variable. Also, we already
have a warn_separator_insert to allow warnings to be printed in
cases like [eye (n)], but it should probably be improved to only
warn about cases that are potenially troublesome (like the example
above) and not things like [1 2].
My current preference would be to remove these variables entirely
rather thanjust changing the default values so that we no longer have
to worry about trying to make code work for different settings.
Comments?
jwe
- more compatibility changes,
John W. Eaton <=