Re: Numerical or other significant code in DEFUN functions

[Mike Miller]

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