Mercurial > octave-nkf
changeset 12375:929cd1a6754b release-3-4-x
Change PROJECTS to point to list on Wiki.
| author | Rik <octave@nomad.inbox5.com> |
|---|---|
| date | Sat, 05 Feb 2011 12:01:50 -0800 |
| parents | 2186c54528c4 |
| children | 3e34ad1d31df |
| files | ChangeLog PROJECTS |
| diffstat | 2 files changed, 12 insertions(+), 440 deletions(-) [+] |
line wrap: on
line diff
--- a/ChangeLog Sat Feb 05 11:51:18 2011 -0800 +++ b/ChangeLog Sat Feb 05 12:01:50 2011 -0800 @@ -10,6 +10,10 @@ 2010-02-05 Rik <octave@nomad.inbox5.com> + * PROJECTS: Point to maintained list on Octave Wiki. + +2010-02-05 Rik <octave@nomad.inbox5.com> + * mkoctfile.in, octave-config.in: Update usage strings. 2010-02-04 Rik <octave@nomad.inbox5.com>
--- a/PROJECTS Sat Feb 05 11:51:18 2011 -0800 +++ b/PROJECTS Sat Feb 05 12:01:50 2011 -0800 @@ -1,443 +1,11 @@ -<html> -<pre> -Octave PROJECTS -*- text -*- +Octave PROJECTS =============== -Look in the Octave source archive on Savannah for a possibly more -current copy. Also, if you start working steadily on a project, -please let maintainers@octave.org know. We might have information -that could help you. You should also read the Contributing Guidelines -chapter in the Octave manual. - -This list is not exclusive -- there are many other things that might -be good projects, but it might instead be something we already have. -Also, some of the following items may not actually be considered good -ideas now. So please check with maintainers@octave.org before you -start working on some large project. - - ---------- -Numerical: ---------- - - * Improve logm, and sqrtm. - - * Improve complex mapper functions. See W. Kahan, ``Branch Cuts for - Complex Elementary Functions, or Much Ado About Nothing's Sign - Bit'' (in The State of the Art in Numerical Analysis, eds. Iserles - and Powell, Clarendon Press, Oxford, 1987) for explicit - trigonometric formulae. - - * Make functions like gamma() return the right IEEE Inf or NaN - values for extreme args or other undefined cases. - - * Improve sqp. - - * Fix CollocWt to handle Laguerre polynomials. Make it easy to - extend it to other polynomial types. - - * Add optional arguments to colloc so that it's not restricted to - Legendre polynomials. - - * Fix eig to also be able to solve the generalized eigenvalue - problem, and to solve for eigenvalues and eigenvectors without - performing a balancing step first. - - * Move rand, eye, xpow, xdiv, etc., functions to the matrix classes. - - * Use octave_allocator for memory management in Array classes once - g++ supports static member templates. - - * Improve design of ODE, DAE, classes. - - * Make QR more memory efficient for large matrices when not all the - columns of Q are required (apparently this is not handled by the - lapack code yet). - ---------------- -Sparse Matrices: ---------------- - - * Improve QR factorization functions, using idea based on CSPARSE - cs_dmsol.m - - * Improve QR fqctorization by replace CXSPARSE code with SPQR code, and make - the linear solve return 2-norm solutions for ill-conditioned matrices - based on this new code - - * Implement fourth argument to the sprand and sprandn, and addition - arguments to sprandsym that the leading brand implements. - - * Sparse logical indexing in idx_vector class so that something like - 'a=sprandn(1e6,1e6,1e-6); a(a<1) = 0' won't cause a memory overflow. - - * Other missing Functions - - symmmd Superseded by symamd - - colmmd Superseded by colamd - - cholinc - - bicg Can this be taken from octave-forge? - - gmres - - lsqr - - minres - - qmr - - symmlq - -------- -Strings: -------- - - * Improve performance of string functions, particularly for - searching and replacing. - - * Make find work for strings. - - * Consider making octave_print_internal() print some sort of text - representation for unprintable characters instead of sending them - directly to the terminal. (But don't do this for fprintf!) - - * Consider changing the default value of `string_fill_char' from SPC - to NUL. - ----------------- -Other Data Types: ----------------- - - * Template functions for mixed-type ops. - - * Convert other functions for use with the floating point type - including quad, dasrt, daspk, etc. - ------------- -Input/Output: ------------- - - * Make fread and fwrite work for complex data. Iostreams based - versions of these functions would also be nice, and if you are - working on them, it would be good to support other size - specifications (integer*2, etc.). - - * Move some pr-output stuff to liboctave. - - * Make the cutoff point for changing to packed storage a - user-preference variable with default value 8192. - - * Complain if there is not enough disk space available (I think - there is simply not enough error checking in the code that handles - writing data). - - * Make it possible to tie arbitrary input and output streams - together, similar to the way iostreams can be tied together. - ------------ -Interpreter: ------------ - - * Allow customization of the debug prompt. - - * Fix the parser so that - - if (expr) 'this is a string' end - - is parsed as IF expr STRING END. - - * Clean up functions in input.cc that handle user input (there - currently seems to be some unnecessary duplication of code and it - seems overly complex). - - * Consider allowing an arbitrary property list to be attached to any - variable. This could be a more general way to handle the help - string that can currently be added with `document'. - - * Allow more command line options to be accessible as built-in - variables (--echo-commands, etc.). - - * Make the interpreter run faster. - - * Allow arbitrary lower bounds for array indexing. - - * Improve performance of recursive function calls. - - * Improve the way ignore_function_time_stamp works to allow - selecting by individual directories or functions. - - * Add a command-line option to tell Octave to just do syntax - checking and not execute statements. - - * Clean up symtab and variable stuff. - - * Input stream class for parser files -- must manage buffers for - flex and context for global variable settings. - - * make parser do more semantic checking, continue after errors when - compiling functions, etc. - - * Make LEXICAL_ERROR have a value that is the error message for - parse_error() to print? - - * Add a run-time alias mechanism that would allow things like - - alias fun function_with_a_very_long_name - - so that `function_with_a_very_long_name' could be invoked as - `fun'. - - * Allow local changes to variables to be written more compactly than - is currently possible with unwind_protect. For example, - - function f () - local prefer_column_vectors = something; - ... - endfunction - - would be equivalent to - - function f () - save_prefer_column_vectors = prefer_column_vectors; - unwind_protect - prefer_column_vectors = something; - ... - unwind_protect_cleanup - prefer_column_vectors = save_prefer_column_vectors; - end_unwind_protect - endfunction - - * Fix all function files to check for bogus inputs (wrong number or - types of input arguments, wrong number of output arguments). - - * Handle options for built-in functions more consistently. - - * Too much time is spent allocating and freeing memory. What can be - done to improve performance? - - * Error output from Fortran code is ugly. Something should be done to - make it look better. - - * It would be nice if output from the Fortran routines could be - passed through the pager. - - * Attempt to recognize common subexpressions in the parser. - - * Consider making it possible to specify an empty matrix with a - syntax like [](e1, e2). Of course at least one of the expressions - must be zero... +A list of proposed projects is maintained at: + + http://wiki.octave.org/wiki.pl?Projects - * Is Matrix::fortran_vec() really necessary? - - * Rewrite whos and the symbol_record_info class. Write a built-in - function that gives all the basic information, then write who and - whos as M-files. - - * On systems that support matherr(), make it possible for users to - enable the printing of warning messages. - - * Make it possible to mark variables and functions as read-only. - - * Make it possible to write a function that gets a reference to a - matrix in memory and change one or more elements without - generating a second copy of the data. - - * Use nanosleep instead of usleep if it is available? Apparently - nanosleep is to be preferred over usleep on Solaris systems. - --------- -Graphics: --------- - - * Correctly handle case where DISPLAY is unset. Provide - --no-window-system or --nodisplay (?) option. Provide - --display=DISPLAY option? How will this work with gnuplot (i.e., - how do we know whether gnuplot requires an X display to display - graphics)? - -------- -History: -------- - - * Add an option to allow saving input from script files in the - history list. - - * The history command should accept two numeric arguments to - indicate a range of history entries to display, save or read. - - * Avoid writing the history file if the history list has not - changed. - - * Avoid permission errors if the history file cannot be opened for - writing. - - * Fix history problems -- core dump if multiple processes are - writing to the same history file? - ------------------------------- -Configuration and Installation: ------------------------------- - - * Split config.h into a part for Octave-specific configuration - things (this part can be installed) and the generic HAVE_X type of - configure information that should not be installed. - - * Makefile changes: - -- eliminate for loops - -- define shell commands or eliminate them - -- consolidate targets - - * Make it possible to configure so that installed binaries and - shared libraries are stripped. - - * Create a docs-only distribution? - ------------------------------- -Documentation and On-Line Help: ------------------------------- - - * Document new features. - - * Improve the Texinfo Documentation for the interpreter. It would - be useful to have lots more examples, to not have so many forward - references, and to not have very many simple lists of functions. - - * The docs should mention something about efficiency and that using - array operations is almost always a good idea for speed. - - * Texinfo documentation for the C++ classes. - - * Make index entries more consistent to improve behavior of `help -i'. - - * Make `help -i' try to find a whole word match first. - - * Clean up help stuff. - - * Demo files. - ------ -Tests: ------ - - * Improved set of tests: - - -- Tests for various functions. Would be nice to have a test file - corresponding to every function. - - -- Tests for element by element operators: - + - .* ./ .\ .^ | & < <= == >= > != ! - - -- Tests for boolean operators: && || - - -- Tests for other operators: * / \ ' .' - - -- Tests from bug reports. - - -- Tests for indexed assignment. Need to consider the following: - o fortran-style indexing - o zero-one indexing - o assignment of empty matrix as well as values - o resizing - - * Tests for all internal functions. - ------------ -Programming: ------------ - - * C++ namespace for Octave library functions. - - * Better error messages for missing operators? - - * Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc. - - * Handle octave_print_internal() stuff at the liboctave level. Then - the octave_value classes could just call on the print() methods - for the underlying classes. - - * As much as possible, eliminate explicit checks for the types of - octave_value objects so that user-defined types will automatically - do the right thing in more cases. - - * Only include config.h in files that actually need it, instead of - including it in every .cc file. Unfortunately, this might not be - so easy to figure out. - - * GNU coding standards: - - -- Add a `Makefile' target to the Makefiles. - -- Comments on #else and #endif preprocessor commands. - -- Change error message format to match standards everywhere. - - * Eliminate more global variables. - - * Move procstream to liboctave. - - * Use references and classes in more places. - - * Share more code among the various *_options functions. - -------------- -Miscellaneous: -------------- - - * Implement some functions for interprocess communication: bind, - accept, connect, gethostbyname, etc. - - * The installation process should also install octave.el. This - needs to detect the appropriate Emacs binary to use to - byte-compile the .el file. Following GNU Emacs philosophy, - installation would be into $(prefix)/share/emacs/site-lisp by - default, but it should be selectable. - - * The ability to transparently handle very large files: - - Juhana K Kouhia <kouhia@nic.funet.fi> wrote: - - If I have a one-dimensional signal data with the size 400 - Mbytes, then what are my choices to operate with it: - - * I have to split the data - * Octave has a virtual memory on its own and I don't have to - worry about the splitting. - - If I split the data, then my easily programmed processing - programs will become hard to program. - - If possible, I would like to have the virtual memory system in - Octave i.e., the all big files, the user see as one big array or - such. There could be several user selectable models to do the - virtual memory depending on what kind of data the user have (1d, - 2d) and in what order they are processed (stream or random - access). - - Perhaps this can be done entirely with a library of M-files. - - * An interface to gdb. - - Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote: - - I was thinking about a tool, which could be very useful for me - in my numerical simulation work. It is an interconnection - between gdb and octave. We are often managing very large arrays - of data in our fortran or c codes, which might be studied with - the help of octave at the algorithm development stages. Assume - you're coding, say, wave equation. And want to debug the - code. It would be great to pick some array from the memory of - the code you're developing, fft it and see the image as a - log-log plot of the spectral density. I'm facing similar - problems now. To avoid high c-development cost, I develop in - matlab/octave, and then rewrite into c. It might be so much - easier, if I could off-load a c array right from the debugger - into octave, study it, and, perhaps, change some [many] values - with a convenient matlab/octave syntax, similar to - a(:,50:250)=zeros(100,200), and then store it back into the - memory of my c code. - - * Add a definition to lgrind so that it supports Octave. - (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more - information about lgrind.) - ------- -Always: ------- - - * Squash bugs. - - --30-- -</pre> -</html> +If you start working steadily on a project, please let +octave-maintainers@octave.org know. We might have information that +could help you. You should also read the Contributing Guidelines +chapter in the Octave manual.