[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Numerical or other significant code in DEFUN functions
From: |
Mike Miller |
Subject: |
Re: Numerical or other significant code in DEFUN functions |
Date: |
Fri, 3 May 2013 09:11:30 -0400 |
On Fri, May 3, 2013 at 1:41 AM, John W. Eaton wrote:
> The recent addition of the ellipj function to the Octave sources
> reminded me of a long-standing issue that I would like to correct. In
> the new ellipj function, the numerical code is inside the new DEFUN
> function, so it is not easily accessible from other C++ code.
>
> As much as possible, DEFUN functions should be simple wrappers aroudn
> library code. Ideally, they should decode arguments and then call
> library functions and not do much else. We have a number of other
> functions where this is a problem, so I'm not picking on ellipj in
> particular. But I would prefer to not have more functions like this,
> or encourage more functions like this to be added in the future.
>
> In the case of ellipj, I would move the sncndn functions into
> liboctave (preferably with more meaningful names), and I would also
> provide versions of those functions that accept array arguments so
> that they might be used from C++ without having to write the loops.
Thanks for the feedback, sounds good to me.
There is also an ellipj.m implementation mentioned in an earlier
thread that I am planning on taking a look at. If the performance is
not too much worse I would drop the C++ ellipj and add the m-file. Now
that you mention adding the functions to liboctave, though, is that a
compelling enough reason to keep this C++ implementation? Or if the
m-file performs good enough is it ok to drop it?
--
mike