octave-maintainers
[Top][All Lists]
Advanced

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

Re: odepkg private functions in core


From: Rik
Subject: Re: odepkg private functions in core
Date: Wed, 21 Oct 2015 07:59:47 -0700

On 10/21/2015 04:27 AM, address@hidden wrote:
Subject:
odepkg private functions in core
From:
Jacopo Corno <address@hidden>
Date:
10/21/2015 01:03 AM
To:
address@hidden, Carlo de Falco <address@hidden>, Sebastian Schöps <address@hidden>
List-Post:
<mailto:address@hidden>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0
Message-ID:
<address@hidden>
Content-Type:
text/plain; charset=utf-8; format=flowed
Message:
4

Dear all,

While doing the cleanup in odepkg after moving functionalities in core, I realized a problem in the current structure.

For odepkg to work with 4.2, some of the functions that are currently private need to be accessible. They should not be used directly by the user, but some of the solvers in odepkg need access to:

integrate_adaptive.m
integrate_const.m
integrate_n_steps.m
odepkg_event_handler.m (now ode_event_handler.m)
ode_struct_value_check.m
starting_stepsize.m

The functions that remain "really" private are:

AbsRel_Nom.m
kahan.m
runge_kutta_interpolate.m

and the steppers (runge_kutta_45_dorpri.m and the steppers of whichever solver we will move to core).

Is it possible to move them out? Or is there a better solution to deprecate their direct access by the user?
Jack,

This occasionally happens.  I can think of three solutions immediately, but maybe someone else can think of something better.

1) Have the "pkg load" script for odepkg add the core ode/private directory to Octave's path.
2) Move the helper functions up from the private directory into the ode directory.  Rename them to have '__' prefix and postfix which indicates that they are really for internal use even though they are visible to the programmer.  See, for example, scripts/plot/util which has __plt_get_axis_arg__.m, __default_plot_options__.m, etc.
3) Have the "pkg install" script copy over the necessary files from ode/private into the odepkg's own private directory.  Given that you can't install a package without having core Octave around, these will always be available for copying.

--Rik

Cheers,
Jack


reply via email to

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