octave-nkf: PROJECTS comparison

comparison PROJECTS @ 12342:83a37dc986f8

Change PROJECTS to point to list on Wiki.

author	Rik <octave@nomad.inbox5.com>
date	Sat, 05 Feb 2011 12:01:50 -0800
parents	b4d2080b6df7
children	7b153b1af227

comparison

equal deleted inserted replaced

-:402456ba3f61
+:83a37dc986f8
-<html>
+Octave PROJECTS
-<pre>
-Octave PROJECTS                                          -*- text -*-
 ===============
-Look in the Octave source archive on Savannah for a possibly more
+A list of proposed projects is maintained at:
-current copy.  Also, if you start working steadily on a project,
-please let maintainers@octave.org know.  We might have information
+http://wiki.octave.org/wiki.pl?Projects
-that could help you.  You should also read the Contributing Guidelines
+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.
-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...
-* 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>

Mercurial > octave-nkf

comparison PROJECTS @ 12342:83a37dc986f8