octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave 2.2.x Was: A group in Norway ...


From: Andy Adler
Subject: Re: Octave 2.2.x Was: A group in Norway ...
Date: Mon, 23 Jun 2003 11:07:24 -0400 (EDT)

On Fri, 20 Jun 2003, John W. Eaton wrote:
> |   - allow calling from C++ rather than casting to octave_value
>
> Do you mean introducing a separate class structure for sparse
> operations that could be used in liboctave?  That would probably be
> useful to have.

Yes. However, since it is currently possible to use octave_value wrappers
from liboctave, I'm not sure how useful this would be. Does using the
wrappers cost much time?

> | If there are any specific requirements (from you or
> | others on the list) I can probably find some time
> | this summer to work on them.
>
> I would like to have the code be in the style of the rest of the
> Octave code.  The doc strings definitely need to use Texinfo markup
> and follow the style of the other doc strings so that they can be
> included in the manual.

OK.

> Unless there is a really good reason for
> using malloc or other C library calls in the C++ code, they should be
> eliminated in favor of standard C++ features.

The underlying superLU libs use malloc a lot. I started trying to use
new, but found it a pain to remember when something may be freed by
superLU, so I changed to using C style allocators throughout.

> Finally, the sparse
> operations need to be integrated with the other existing operations so
> that lu (X) works whether X is sparse or full.  We can do this for a
> few types (sparse, N-dimensional arrays) case by case since there may
> not be too many functions, but it would be nice to also come up with a
> more general dispatch scheme.

Paul Kienzle's "dispach" mechanism allows this currently. A generalized
mechanism would be nice, but this works well now.


Andy




reply via email to

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