[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
more compatibility changes
From: |
John W. Eaton |
Subject: |
more compatibility changes |
Date: |
Wed, 30 Jul 2003 12:54:54 -0500 |
On 11-Jul-2003, I wrote:
| 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 [], [...]
|
| * Remove the built-in variable default_eval_print_flag and only
| implement Matlab-compatible behavior, [...]
|
|
| * Remove the built-in variable whitespace_in_literal_matrix and only
| implement Matlab-compatible behavior, [...]
Changes for all of these are now checked in to the CVS archive. At
this point, I think there are only a few built-in variables left that
affect the way a program is interpreted. These are
automatic_replot
propagate_empty_matrices
and then there is also
default_save_format
which could cause some compatibility problems. But do we really want
Octave's default save format to be the current Matlab binary format?
I think I will look at removing propagate_empty_matrices. Does anyone
have a strong opinion about the other two?
jwe