octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]