Mercurial > hg > octave-lyh
annotate PROJECTS @ 7835:ca8b97bb952c
added the function available_backends
author | Shai Ayal <shaiay@sourceforge.net> |
---|---|
date | Wed, 20 Feb 2008 21:58:22 +0200 |
parents | 82be108cc558 |
children | b672260d14e7 |
rev | line source |
---|---|
3162 | 1 <html> |
2 <pre> | |
2330 | 3 Octave PROJECTS -*- text -*- |
4 =============== | |
5 | |
5041 | 6 Check with maintainers@octave.org for a possibly more current copy. |
7 Also, if you start working steadily on a project, please let | |
8 maintainers@octave.org know. We might have information that could | |
9 help you; we'd also like to send you the GNU coding standards. | |
2330 | 10 |
11 This list is not exclusive -- there are many other things that might | |
12 be good projects, but it might instead be something we already have, | |
5041 | 13 so check with maintainers@octave.org before you start. |
2330 | 14 |
15 --------- | |
16 Numerical: | |
17 --------- | |
18 | |
19 * Improve logm, and sqrtm. | |
20 | |
3713 | 21 * Improve complex mapper functions. See W. Kahan, ``Branch Cuts for |
22 Complex Elementary Functions, or Much Ado About Nothing's Sign | |
23 Bit'' (in The State of the Art in Numerical Analysis, eds. Iserles | |
24 and Powell, Clarendon Press, Oxford, 1987) for explicit | |
25 trigonometric formulae. | |
2330 | 26 |
27 * Make functions like gamma() return the right IEEE Inf or NaN | |
28 values for extreme args or other undefined cases. | |
29 | |
30 * Handle complex values in fread and fwrite. | |
31 | |
32 * Support for lp_solve for linear programming problems. | |
33 | |
6628 | 34 * Improve sqp. |
2330 | 35 |
36 * Fix CollocWt to handle Laguerre polynomials. Make it easy to | |
37 extend it to other polynomial types. | |
38 | |
39 * Add optional arguments to colloc so that it's not restricted to | |
40 Legendre polynomials. | |
41 | |
42 * Fix eig to also be able to solve the generalized eigenvalue | |
43 problem, and to solve for eigenvalues and eigenvectors without | |
44 performing a balancing step first. | |
45 | |
46 * Move rand, eye, xpow, xdiv, etc., functions to the matrix classes. | |
47 | |
2477 | 48 * Use octave_allocator for memory management in Array classes once |
49 g++ supports static member templates. | |
50 | |
2789 | 51 * When constructing NLConst (and other) objects, make sure that |
52 there are sufficient checks to ensure that the dimensions all | |
53 conform. | |
54 | |
2330 | 55 * Improve design of ODE, DAE, classes. |
56 | |
57 * Extend meaning of .* to include v .* M or M .* v (where v is a | |
58 column vector with the same number of rows as M) to scale rows of | |
59 M by elements of v. Similarly, if w is a row vector with as many | |
60 columns as M, then either w .* M or M .* w scales the columns of | |
61 M. | |
62 | |
3141 | 63 * Make QR more memory efficient for large matrices when not all the |
64 columns of Q are required (apparently this is not handled by the | |
65 lapack code yet). | |
66 | |
2799 | 67 * Consider making the behavior of the / and \ operators for |
3758 | 68 non-square systems compatible with Matlab. Currently, they return |
7072 | 69 the minimum norm solution from DGELSD, which behaves differently. |
2799 | 70 |
5164 | 71 --------------- |
72 Sparse Matrices: | |
73 --------------- | |
74 | |
5610 | 75 * Improve QR factorization functions, using idea based on CSPARSE |
76 cs_dmsol.m | |
5164 | 77 |
5610 | 78 * Implement fourth argument to the sprand and sprandn, and addition |
79 arguments to sprandsym that the leading brand implements. | |
5164 | 80 |
5282 | 81 * Sparse logical indexing in idx_vector class so that something like |
82 "a=sprandn(1e6,1e6,1e-6); a(a<1) = 0" won't cause a memory overflow. | |
5164 | 83 |
84 * Make spalloc(r,c,n) actually create an empty sparse with n non-zero | |
85 elements? This allows something like | |
86 | |
87 sm = spalloc (r,c,n) | |
88 for j=1:c | |
89 for i=1:r | |
90 tmp = foo (i,j); | |
91 if (tmp != 0.) | |
92 sm (i,j) = tmp; | |
93 endif | |
94 endfor | |
95 endfor | |
96 | |
97 actually make sense. Otherwise the above will cause massive amounts | |
98 of memory reallocation. | |
99 | |
100 The fact is that this doesn't make sense in any case as the assign | |
101 function makes another copy of the sparse matrix. So although spalloc | |
102 might easily be made to have the correct behaviour, the first assign | |
103 will cause the matrix to be resized !!! There seems to be no simple | |
104 way to treat this but a complete rewrite of the sparse assignment | |
105 functions... | |
106 | |
107 * Other missing Functions | |
108 - symmmd Superseded by symamd | |
109 - colmmd Superseded by colamd | |
110 - treelayout | |
111 - cholinc | |
6627 | 112 - bicg Can this be taken from octave-forge? |
5164 | 113 - bicgstab |
114 - cgs | |
115 - gmres | |
116 - lsqr | |
117 - minres | |
118 - qmr | |
119 - symmlq | |
120 | |
2330 | 121 ------- |
122 Strings: | |
123 ------- | |
124 | |
2789 | 125 * Improve performance of string functions, particularly for |
126 searching and replacing. | |
127 | |
2330 | 128 * Convert string functions to work on string arrays. |
129 | |
130 * Make find work for strings. | |
131 | |
2378 | 132 * Consider making octave_print_internal() print some sort of text |
133 representation for unprintable characters instead of sending them | |
134 directly to the terminal. (But don't do this for fprintf!) | |
135 | |
136 * Consider changing the default value of `string_fill_char' from SPC | |
137 to NUL. | |
138 | |
2330 | 139 ---------------- |
140 Other Data Types: | |
141 ---------------- | |
142 | |
143 * Template functions for mixed-type ops. | |
144 | |
7789
82be108cc558
First attempt at single precision tyeps
David Bateman <dbateman@free.fr>
parents:
7787
diff
changeset
|
145 * Convert other functions for use with the floating point type |
82be108cc558
First attempt at single precision tyeps
David Bateman <dbateman@free.fr>
parents:
7787
diff
changeset
|
146 including quad, dasrt, daspk, etc. |
82be108cc558
First attempt at single precision tyeps
David Bateman <dbateman@free.fr>
parents:
7787
diff
changeset
|
147 |
2330 | 148 ------------ |
149 Input/Output: | |
150 ------------ | |
151 | |
152 * Make fread and fwrite work for complex data. Iostreams based | |
153 versions of these functions would also be nice, and if you are | |
154 working on them, it would be good to support other size | |
155 specifications (integer*2, etc.). | |
156 | |
157 * Move some pr-output stuff to liboctave. | |
158 | |
159 * Make the cutoff point for changing to packed storage a | |
160 user-preference variable with default value 8192. | |
161 | |
2378 | 162 * Make it possible to load other image formats (ppm, pbm, etc. would |
163 probably be best since there are already filters to convert to | |
164 these formats from others.) | |
165 | |
2330 | 166 * Complain if there is not enough disk space available (I think |
167 there is simply not enough error checking in the code that handles | |
168 writing data). | |
169 | |
170 * Make it possible to tie arbitrary input and output streams | |
171 together, similar to the way iostreams can be tied together. | |
172 | |
173 ----------- | |
174 Interpreter: | |
175 ----------- | |
176 | |
3162 | 177 * Allow customization of the debug prompt. |
178 | |
2601 | 179 * Fix the parser so that |
180 | |
3081 | 181 if (expr) 'this is a string' end |
182 | |
183 is parsed as IF expr STRING END. | |
184 | |
6628 | 185 * Clean up functions in input.cc that handle user input (there |
186 currently seems to be some unnecessary duplication of code and it | |
187 seems overly complex). | |
2330 | 188 |
189 * Consider allowing an arbitrary property list to be attached to any | |
190 variable. This could be a more general way to handle the help | |
191 string that can currently be added with `document'. | |
192 | |
193 * Allow more command line options to be accessible as built-in | |
194 variables (--echo-commands, etc.). | |
195 | |
196 * Make the interpreter run faster. | |
197 | |
4325 | 198 * Allow arbitrary lower bounds for array indexing. |
2330 | 199 |
4325 | 200 * Improve performance of recursive function calls. |
2330 | 201 |
202 * Improve the way ignore_function_time_stamp works to allow | |
3167 | 203 selecting by individual directories or functions. |
2330 | 204 |
205 * Add a command-line option to tell Octave to just do syntax | |
206 checking and not execute statements. | |
207 | |
208 * Clean up symtab and variable stuff. | |
209 | |
210 * Input stream class for parser files -- must manage buffers for | |
211 flex and context for global variable settings. | |
212 | |
3162 | 213 * make parser do more semantic checking, continue after errors when |
214 compiling functions, etc. | |
215 | |
2330 | 216 * Make LEXICAL_ERROR have a value that is the error message for |
217 parse_error() to print? | |
218 | |
219 * Add a run-time alias mechanism that would allow things like | |
220 | |
221 alias fun function_with_a_very_long_name | |
222 | |
223 so that `function_with_a_very_long_name' could be invoked as | |
224 `fun'. | |
225 | |
226 * Allow local changes to variables to be written more compactly than | |
227 is currently possible with unwind_protect. For example, | |
228 | |
229 function f () | |
230 local prefer_column_vectors = something; | |
231 ... | |
232 endfunction | |
233 | |
234 would be equivalent to | |
235 | |
236 function f () | |
3758 | 237 save_prefer_column_vectors = prefer_column_vectors; |
2330 | 238 unwind_protect |
239 prefer_column_vectors = something; | |
240 ... | |
241 unwind_protect_cleanup | |
242 prefer_column_vectors = save_prefer_column_vectors; | |
243 end_unwind_protect | |
244 endfunction | |
245 | |
246 * Fix all function files to check for bogus inputs (wrong number or | |
247 types of input arguments, wrong number of output arguments). | |
248 | |
249 * Handle options for built-in functions more consistently. | |
250 | |
251 * Too much time is spent allocating and freeing memory. What can be | |
252 done to improve performance? | |
253 | |
254 * Error output from Fortran code is ugly. Something should be done to | |
255 make it look better. | |
256 | |
257 * It would be nice if output from the Fortran routines could be | |
258 passed through the pager. | |
259 | |
260 * Attempt to recognize common subexpressions in the parser. | |
261 | |
262 * Consider making it possible to specify an empty matrix with a | |
263 syntax like [](e1, e2). Of course at least one of the expressions | |
264 must be zero... | |
265 | |
266 * Is Matrix::fortran_vec() really necessary? | |
2862 | 267 |
2330 | 268 * Add a command that works like bash's `builtin' command. |
269 | |
270 * It would be nice to have an interactive debugger. | |
271 | |
2746 | 272 * Rewrite whos and the symbol_record_info class. Write a built-in |
273 function that gives all the basic information, then write who and | |
274 whos as M-files. | |
2439 | 275 |
2799 | 276 * On systems that support matherr(), make it possible for users to |
277 enable the printing of warning messages. | |
278 | |
2862 | 279 * Make it possible to mark variables and functions as read-only. |
280 | |
3092 | 281 * Make it possible to write a function that gets a reference to a |
282 matrix in memory and change one or more elements without | |
283 generating a second copy of the data. | |
284 | |
5228 | 285 * Use nanosleep instead of usleep if it is available? Apparently |
286 nanosleep is to be preferred over usleep on Solaris systems. | |
287 | |
2330 | 288 ------- |
289 History: | |
290 ------- | |
291 | |
292 * Add an option to allow saving input from script files in the | |
293 history list. | |
294 | |
3092 | 295 * The history command should accept two numeric arguments to |
296 indicate a range of history entries to display, save or read. | |
297 | |
5026 | 298 * Avoid writing the history file if the history list has not |
299 changed. | |
300 | |
301 * Avoid permission errors if the history file cannot be opened for | |
302 writing. | |
303 | |
2330 | 304 * Fix history problems -- core dump if multiple processes are |
305 writing to the same history file? | |
306 | |
307 ------------------------------ | |
308 Configuration and Installation: | |
309 ------------------------------ | |
310 | |
2473 | 311 * Add an --enable-pathsearch option to configure to make it possible |
312 to configure and run without kpathsea. | |
313 | |
2330 | 314 * Makefile changes: |
315 -- eliminate for loops | |
316 -- define shell commands or eliminate them | |
317 -- verify distclean | |
318 -- consolidate targets | |
319 | |
320 * Make it possible to configure so that installed binaries and | |
321 shared libraries are stripped. | |
322 | |
3069 | 323 * Create a docs-only distribution? |
324 | |
2330 | 325 ------------------------------ |
326 Documentation and On-Line Help: | |
327 ------------------------------ | |
328 | |
329 * Document new features. | |
330 -- history-search-{back,for}ward. | |
331 -- Other stuff mentioned in the NEWS file. | |
332 | |
333 * Improve the Texinfo Documentation for the interpreter. It would | |
334 be useful to have lots more examples, to not have so many forward | |
335 references, and to not have very many simple lists of functions. | |
336 | |
337 * The docs should mention something about efficiency and that using | |
338 array operations is almost always a good idea for speed. | |
339 | |
340 * Texinfo documentation for the C++ classes. | |
341 | |
342 * Make index entries more consistent to improve behavior of `help -i'. | |
343 | |
344 * Make `help -i' try to find a whole word match first. | |
345 | |
3130 | 346 * Clean up help stuff. |
347 | |
2330 | 348 * Demo files. |
349 | |
350 * As the number of m-files with octave grows perhaps a 'Contents.m' | |
351 file for each toolbox (directory) would be appropriate so one | |
352 knows exactly what functions are in a toolbox with a quick look. | |
353 It would be best to generate information for each function directly | |
354 from the M-files, so that the information doesn't have to be | |
355 duplicated, and will remain current if the M-files change. It | |
356 would also be best to do as much of this as possible in an M-file, | |
357 though I wouldn't mind adding some basic support for listing the | |
6627 | 358 names of all the directories in the load path, and the names of all |
2330 | 359 the M-files in a given directory if that is needed. |
360 | |
2787 | 361 Also make it possible to recursively search for Contents files: |
362 | |
363 help dir -- Contents from dir | |
364 help dir// -- Contents from dir and all its subdirectories | |
365 help dir1/dir2 -- Contents from dir2 which is under dir1 | |
366 | |
2330 | 367 ----- |
368 Tests: | |
369 ----- | |
370 | |
371 * Improved set of tests: | |
372 | |
373 -- Tests for various functions. Would be nice to have a test file | |
374 corresponding to every function. | |
375 | |
376 -- Tests for element by element operators: | |
377 + - .* ./ .\ .^ | & < <= == >= > != ! | |
378 | |
379 -- Tests for boolean operators: && || | |
380 | |
381 -- Tests for other operators: * / \ ' .' | |
382 | |
383 -- Tests from bug reports. | |
384 | |
385 -- Tests for indexed assignment. Need to consider the following: | |
386 o fortran-style indexing | |
387 o zero-one indexing | |
388 o assignment of empty matrix as well as values | |
389 o resizing | |
390 | |
391 * Tests for all internal functions. | |
392 | |
393 ----------- | |
394 Programming: | |
395 ----------- | |
396 | |
2475 | 397 * Better error messages for missing operators? |
398 | |
399 * Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc. | |
400 | |
401 * Handle octave_print_internal() stuff at the liboctave level. Then | |
402 the octave_value classes could just call on the print() methods | |
403 for the underlying classes. | |
404 | |
405 * As much as possible, eliminate explicit checks for the types of | |
406 octave_value objects so that user-defined types will automatically | |
407 do the right thing in more cases. | |
408 | |
2330 | 409 * Only include config.h in files that actually need it, instead of |
410 including it in every .cc file. Unfortunately, this might not be | |
411 so easy to figure out. | |
412 | |
413 * GNU coding standards: | |
414 | |
415 -- Add a `Makefile' target to the Makefiles. | |
416 -- Comments on #else and #endif preprocessor commands. | |
417 -- Change error message format to match standards everywhere. | |
418 | |
419 * Eliminate more global variables. | |
420 | |
421 * Move procstream to liboctave. | |
422 | |
423 * Use references and classes in more places. | |
424 | |
425 * Share more code among the various *_options functions. | |
426 | |
427 ------------- | |
428 Miscellaneous: | |
429 ------------- | |
430 | |
431 * Implement some functions for interprocess communication: bind, | |
432 accept, connect, gethostbyname, etc. | |
433 | |
2454 | 434 * The installation process should also install octave.el. This |
435 needs to detect the appropriate Emacs binary to use to | |
436 byte-compile the .el file. Following GNU Emacs philosophy, | |
437 installation would be into $(prefix)/share/emacs/site-lisp by | |
438 default, but it should be selectable. | |
439 | |
2330 | 440 * The ability to transparently handle very large files: |
441 | |
442 Juhana K Kouhia <kouhia@nic.funet.fi> wrote: | |
443 | |
444 If I have a one-dimensional signal data with the size 400 | |
445 Mbytes, then what are my choices to operate with it: | |
446 | |
447 * I have to split the data | |
448 * Octave has a virtual memory on its own and I don't have to | |
449 worry about the splitting. | |
450 | |
451 If I split the data, then my easily programmed processing | |
452 programs will become hard to program. | |
453 | |
454 If possible, I would like to have the virtual memory system in | |
455 Octave i.e. the all big files, the user see as one big array or | |
456 such. There could be several user selectable models to do the | |
457 virtual memory depending on what kind of data the user have (1d, | |
458 2d) and in what order they are processed (stream or random | |
459 access). | |
460 | |
461 Perhaps this can be done entirely with a library of M-files. | |
462 | |
3136 | 463 * An interface to gdb. |
464 | |
465 Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote: | |
466 | |
467 I was thinking about a tool, which could be very useful for me | |
468 in my numerical simulation work. It is an interconnection | |
469 between gdb and octave. We are often managing very large arrays | |
470 of data in our fortran or c codes, which might be studied with | |
471 the help of octave at the algorithm development stages. Assume | |
472 you're coding, say, wave equation. And want to debug the | |
473 code. It would be great to pick some array from the memory of | |
474 the code you're develloping, fft it and see the image as a | |
475 log-log plot of the spectral density. I'm facing similar | |
476 problems now. To avoid high c-development cost, I develop in | |
477 matlab/octave, and then rewrite into c. It might be so much | |
478 easier, if I could off-load a c array right from the debugger | |
479 into octave, study it, and, perhaps, change some [many] values | |
480 with a convenient matlab/octave syntax, similar to | |
481 a(:,50:250)=zeros(100,200), and then store it back into the | |
482 memory of my c code. | |
483 | |
2789 | 484 * Add a definition to lgrind so that it supports Octave. |
485 (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more | |
486 information about lgrind.) | |
487 | |
2330 | 488 ------ |
489 Always: | |
490 ------ | |
491 | |
492 * Squash bugs. | |
493 | |
494 --30-- | |
3162 | 495 </pre> |
496 </html> |