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 |
|
34 * Free NLP solver. |
|
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 |
|
69 the minimum norm solution from DGELSS, 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 |
|
112 - condest |
6627
|
113 - bicg Can this be taken from octave-forge? |
5164
|
114 - bicgstab |
|
115 - cgs |
|
116 - gmres |
|
117 - lsqr |
|
118 - minres |
|
119 - qmr |
|
120 - symmlq |
|
121 - spaugment |
|
122 |
2330
|
123 -------- |
|
124 Graphics: |
|
125 -------- |
|
126 |
|
127 * Make plotting with plplot work. |
|
128 |
|
129 * Make it possible to check the current graphics terminal type. |
|
130 |
2799
|
131 * If using gnuplot, consider setting a smaller default for the |
|
132 `zero' value (e.g., set zero sqrt (realmin) or something). |
|
133 |
2330
|
134 ------- |
|
135 Strings: |
|
136 ------- |
|
137 |
2789
|
138 * Improve performance of string functions, particularly for |
|
139 searching and replacing. |
|
140 |
2330
|
141 * Convert string functions to work on string arrays. |
|
142 |
|
143 * Make find work for strings. |
|
144 |
2378
|
145 * Consider making octave_print_internal() print some sort of text |
|
146 representation for unprintable characters instead of sending them |
|
147 directly to the terminal. (But don't do this for fprintf!) |
|
148 |
|
149 * Consider changing the default value of `string_fill_char' from SPC |
|
150 to NUL. |
|
151 |
2330
|
152 ---------------- |
|
153 Other Data Types: |
|
154 ---------------- |
|
155 |
|
156 * Template functions for mixed-type ops. |
|
157 |
|
158 ------------------------ |
|
159 Graphical User Interface: |
|
160 ------------------------ |
|
161 |
|
162 * In an X11 or other windowing environment, allow the user to pop up |
|
163 windows for menus and other purposes. A good place to start might |
|
164 be Tk, as long as Tcl is avoided. |
|
165 |
|
166 * Add a way to handle events, like alarms, mouse clicks, etc. |
|
167 |
|
168 ------------ |
|
169 Input/Output: |
|
170 ------------ |
|
171 |
|
172 * Make fread and fwrite work for complex data. Iostreams based |
|
173 versions of these functions would also be nice, and if you are |
|
174 working on them, it would be good to support other size |
|
175 specifications (integer*2, etc.). |
|
176 |
6627
|
177 * Make fread and fopen look in the load path for files. |
2799
|
178 |
2330
|
179 * Move some pr-output stuff to liboctave. |
|
180 |
|
181 * Make the cutoff point for changing to packed storage a |
|
182 user-preference variable with default value 8192. |
|
183 |
2378
|
184 * Make it possible to load other image formats (ppm, pbm, etc. would |
|
185 probably be best since there are already filters to convert to |
|
186 these formats from others.) |
|
187 |
2330
|
188 * Complain if there is not enough disk space available (I think |
|
189 there is simply not enough error checking in the code that handles |
|
190 writing data). |
|
191 |
|
192 * Make it possible to tie arbitrary input and output streams |
|
193 together, similar to the way iostreams can be tied together. |
|
194 |
|
195 ----------- |
|
196 Interpreter: |
|
197 ----------- |
|
198 |
3162
|
199 * Allow customization of the debug prompt. |
|
200 |
|
201 * For the keyboard function, parse return (or quit) more |
|
202 intelligently so that something like |
|
203 |
|
204 debug> x = 1; return |
|
205 |
|
206 will work as expected. |
|
207 |
5008
|
208 * Handle multi-line input at the keyboard/debug prompt correctly. |
|
209 |
2601
|
210 * Fix the parser so that |
|
211 |
3081
|
212 if (expr) 'this is a string' end |
|
213 |
|
214 is parsed as IF expr STRING END. |
|
215 |
2330
|
216 * Consider grouping all preference variables in a structure instead |
|
217 of further polluting the namespace. Maybe `Octave_options.xxx'? |
|
218 |
|
219 * Consider allowing an arbitrary property list to be attached to any |
|
220 variable. This could be a more general way to handle the help |
|
221 string that can currently be added with `document'. |
|
222 |
|
223 * Allow more command line options to be accessible as built-in |
|
224 variables (--echo-commands, etc.). |
|
225 |
|
226 * Make the interpreter run faster. |
|
227 |
4325
|
228 * Allow arbitrary lower bounds for array indexing. |
2330
|
229 |
4325
|
230 * Improve performance of recursive function calls. |
2330
|
231 |
|
232 * Improve the way ignore_function_time_stamp works to allow |
3167
|
233 selecting by individual directories or functions. |
2330
|
234 |
|
235 * Add a command-line option to tell Octave to just do syntax |
|
236 checking and not execute statements. |
|
237 |
|
238 * Clean up symtab and variable stuff. |
|
239 |
|
240 * Input stream class for parser files -- must manage buffers for |
|
241 flex and context for global variable settings. |
|
242 |
3162
|
243 * make parser do more semantic checking, continue after errors when |
|
244 compiling functions, etc. |
|
245 |
2330
|
246 * Make LEXICAL_ERROR have a value that is the error message for |
|
247 parse_error() to print? |
|
248 |
|
249 * Add a run-time alias mechanism that would allow things like |
|
250 |
|
251 alias fun function_with_a_very_long_name |
|
252 |
|
253 so that `function_with_a_very_long_name' could be invoked as |
|
254 `fun'. |
|
255 |
|
256 * Allow local changes to variables to be written more compactly than |
|
257 is currently possible with unwind_protect. For example, |
|
258 |
|
259 function f () |
|
260 local prefer_column_vectors = something; |
|
261 ... |
|
262 endfunction |
|
263 |
|
264 would be equivalent to |
|
265 |
|
266 function f () |
3758
|
267 save_prefer_column_vectors = prefer_column_vectors; |
2330
|
268 unwind_protect |
|
269 prefer_column_vectors = something; |
|
270 ... |
|
271 unwind_protect_cleanup |
|
272 prefer_column_vectors = save_prefer_column_vectors; |
|
273 end_unwind_protect |
|
274 endfunction |
|
275 |
|
276 * Fix all function files to check for bogus inputs (wrong number or |
|
277 types of input arguments, wrong number of output arguments). |
|
278 |
|
279 * Handle options for built-in functions more consistently. |
|
280 |
|
281 * Too much time is spent allocating and freeing memory. What can be |
|
282 done to improve performance? |
|
283 |
|
284 * Error output from Fortran code is ugly. Something should be done to |
|
285 make it look better. |
|
286 |
|
287 * It would be nice if output from the Fortran routines could be |
|
288 passed through the pager. |
|
289 |
|
290 * Attempt to recognize common subexpressions in the parser. |
|
291 |
|
292 * Consider making it possible to specify an empty matrix with a |
|
293 syntax like [](e1, e2). Of course at least one of the expressions |
|
294 must be zero... |
|
295 |
|
296 * Is Matrix::fortran_vec() really necessary? |
2862
|
297 |
2330
|
298 * Add a command that works like bash's `builtin' command. |
|
299 |
|
300 * It would be nice to have an interactive debugger. |
|
301 |
2746
|
302 * Rewrite whos and the symbol_record_info class. Write a built-in |
|
303 function that gives all the basic information, then write who and |
|
304 whos as M-files. |
2439
|
305 |
2799
|
306 * On systems that support matherr(), make it possible for users to |
|
307 enable the printing of warning messages. |
|
308 |
2862
|
309 * Make it possible to mark variables and functions as read-only. |
|
310 |
3092
|
311 * Make it possible to write a function that gets a reference to a |
|
312 matrix in memory and change one or more elements without |
|
313 generating a second copy of the data. |
|
314 |
5228
|
315 * Use nanosleep instead of usleep if it is available? Apparently |
|
316 nanosleep is to be preferred over usleep on Solaris systems. |
|
317 |
2330
|
318 ------- |
|
319 History: |
|
320 ------- |
|
321 |
|
322 * Add an option to allow saving input from script files in the |
|
323 history list. |
|
324 |
3092
|
325 * The history command should accept two numeric arguments to |
|
326 indicate a range of history entries to display, save or read. |
|
327 |
5026
|
328 * Avoid writing the history file if the history list has not |
|
329 changed. |
|
330 |
|
331 * Avoid permission errors if the history file cannot be opened for |
|
332 writing. |
|
333 |
2330
|
334 * Fix history problems -- core dump if multiple processes are |
|
335 writing to the same history file? |
|
336 |
|
337 ------------------------------ |
|
338 Configuration and Installation: |
|
339 ------------------------------ |
|
340 |
2473
|
341 * Add an --enable-pathsearch option to configure to make it possible |
|
342 to configure and run without kpathsea. |
|
343 |
2330
|
344 * Makefile changes: |
|
345 -- eliminate for loops |
|
346 -- define shell commands or eliminate them |
|
347 -- verify distclean |
|
348 -- consolidate targets |
|
349 |
|
350 * Make it possible to configure so that installed binaries and |
|
351 shared libraries are stripped. |
|
352 |
3069
|
353 * Create a docs-only distribution? |
|
354 |
2330
|
355 ------------------------------ |
|
356 Documentation and On-Line Help: |
|
357 ------------------------------ |
|
358 |
|
359 * Document new features. |
|
360 -- history-search-{back,for}ward. |
|
361 -- Other stuff mentioned in the NEWS file. |
|
362 |
|
363 * Improve the Texinfo Documentation for the interpreter. It would |
|
364 be useful to have lots more examples, to not have so many forward |
|
365 references, and to not have very many simple lists of functions. |
|
366 |
|
367 * The docs should mention something about efficiency and that using |
|
368 array operations is almost always a good idea for speed. |
|
369 |
|
370 * Texinfo documentation for the C++ classes. |
|
371 |
|
372 * Make index entries more consistent to improve behavior of `help -i'. |
|
373 |
|
374 * Make `help -i' try to find a whole word match first. |
|
375 |
3130
|
376 * Clean up help stuff. |
|
377 |
2330
|
378 * Demo files. |
|
379 |
|
380 * As the number of m-files with octave grows perhaps a 'Contents.m' |
|
381 file for each toolbox (directory) would be appropriate so one |
|
382 knows exactly what functions are in a toolbox with a quick look. |
|
383 It would be best to generate information for each function directly |
|
384 from the M-files, so that the information doesn't have to be |
|
385 duplicated, and will remain current if the M-files change. It |
|
386 would also be best to do as much of this as possible in an M-file, |
|
387 though I wouldn't mind adding some basic support for listing the |
6627
|
388 names of all the directories in the load path, and the names of all |
2330
|
389 the M-files in a given directory if that is needed. |
|
390 |
2787
|
391 Also make it possible to recursively search for Contents files: |
|
392 |
|
393 help dir -- Contents from dir |
|
394 help dir// -- Contents from dir and all its subdirectories |
|
395 help dir1/dir2 -- Contents from dir2 which is under dir1 |
|
396 |
2330
|
397 ----- |
|
398 Tests: |
|
399 ----- |
|
400 |
|
401 * Improved set of tests: |
|
402 |
|
403 -- Tests for various functions. Would be nice to have a test file |
|
404 corresponding to every function. |
|
405 |
|
406 -- Tests for element by element operators: |
|
407 + - .* ./ .\ .^ | & < <= == >= > != ! |
|
408 |
|
409 -- Tests for boolean operators: && || |
|
410 |
|
411 -- Tests for other operators: * / \ ' .' |
|
412 |
|
413 -- Tests from bug reports. |
|
414 |
|
415 -- Tests for indexed assignment. Need to consider the following: |
|
416 o fortran-style indexing |
|
417 o zero-one indexing |
|
418 o assignment of empty matrix as well as values |
|
419 o resizing |
|
420 |
|
421 * Tests for all internal functions. |
|
422 |
|
423 ----------- |
|
424 Programming: |
|
425 ----------- |
|
426 |
2475
|
427 * Better error messages for missing operators? |
|
428 |
|
429 * Eliminate duplicate enums in pt-exp.cc, pt-const.cc, and ov.cc. |
|
430 |
|
431 * Handle octave_print_internal() stuff at the liboctave level. Then |
|
432 the octave_value classes could just call on the print() methods |
|
433 for the underlying classes. |
|
434 |
|
435 * As much as possible, eliminate explicit checks for the types of |
|
436 octave_value objects so that user-defined types will automatically |
|
437 do the right thing in more cases. |
|
438 |
2330
|
439 * Only include config.h in files that actually need it, instead of |
|
440 including it in every .cc file. Unfortunately, this might not be |
|
441 so easy to figure out. |
|
442 |
|
443 * GNU coding standards: |
|
444 |
|
445 -- Add a `Makefile' target to the Makefiles. |
|
446 -- Comments on #else and #endif preprocessor commands. |
|
447 -- Change error message format to match standards everywhere. |
|
448 |
|
449 * Eliminate more global variables. |
|
450 |
|
451 * Move procstream to liboctave. |
|
452 |
|
453 * Use references and classes in more places. |
|
454 |
|
455 * Share more code among the various *_options functions. |
|
456 |
|
457 ------------- |
|
458 Miscellaneous: |
|
459 ------------- |
|
460 |
|
461 * Implement some functions for interprocess communication: bind, |
|
462 accept, connect, gethostbyname, etc. |
|
463 |
2454
|
464 * The installation process should also install octave.el. This |
|
465 needs to detect the appropriate Emacs binary to use to |
|
466 byte-compile the .el file. Following GNU Emacs philosophy, |
|
467 installation would be into $(prefix)/share/emacs/site-lisp by |
|
468 default, but it should be selectable. |
|
469 |
2330
|
470 * The ability to transparently handle very large files: |
|
471 |
|
472 Juhana K Kouhia <kouhia@nic.funet.fi> wrote: |
|
473 |
|
474 If I have a one-dimensional signal data with the size 400 |
|
475 Mbytes, then what are my choices to operate with it: |
|
476 |
|
477 * I have to split the data |
|
478 * Octave has a virtual memory on its own and I don't have to |
|
479 worry about the splitting. |
|
480 |
|
481 If I split the data, then my easily programmed processing |
|
482 programs will become hard to program. |
|
483 |
|
484 If possible, I would like to have the virtual memory system in |
|
485 Octave i.e. the all big files, the user see as one big array or |
|
486 such. There could be several user selectable models to do the |
|
487 virtual memory depending on what kind of data the user have (1d, |
|
488 2d) and in what order they are processed (stream or random |
|
489 access). |
|
490 |
|
491 Perhaps this can be done entirely with a library of M-files. |
|
492 |
3136
|
493 * An interface to gdb. |
|
494 |
|
495 Michael Smolsky <fnsiguc@weizmann.weizmann.ac.il> wrote: |
|
496 |
|
497 I was thinking about a tool, which could be very useful for me |
|
498 in my numerical simulation work. It is an interconnection |
|
499 between gdb and octave. We are often managing very large arrays |
|
500 of data in our fortran or c codes, which might be studied with |
|
501 the help of octave at the algorithm development stages. Assume |
|
502 you're coding, say, wave equation. And want to debug the |
|
503 code. It would be great to pick some array from the memory of |
|
504 the code you're develloping, fft it and see the image as a |
|
505 log-log plot of the spectral density. I'm facing similar |
|
506 problems now. To avoid high c-development cost, I develop in |
|
507 matlab/octave, and then rewrite into c. It might be so much |
|
508 easier, if I could off-load a c array right from the debugger |
|
509 into octave, study it, and, perhaps, change some [many] values |
|
510 with a convenient matlab/octave syntax, similar to |
|
511 a(:,50:250)=zeros(100,200), and then store it back into the |
|
512 memory of my c code. |
|
513 |
2789
|
514 * Add a definition to lgrind so that it supports Octave. |
|
515 (See http://www.tex.ac.uk/tex-archive/support/lgrind/ for more |
|
516 information about lgrind.) |
|
517 |
2330
|
518 ------ |
|
519 Always: |
|
520 ------ |
|
521 |
|
522 * Squash bugs. |
|
523 |
|
524 --30-- |
3162
|
525 </pre> |
|
526 </html> |