On 06/10/2017 07:32 AM, [hidden email] wrote:
There is a big ongoing re-organization of the Octave code base to base it squarely on C++11. This will be excellent for future maintainability and accuracy, but will create hiccups in the meantime as the code base is undergoing a lot of change. In particular, make sure you issue Mercurial pulls frequently from the main repository. In the last two days I have delegated basic special functions, like erf or gamma, to the C++ std library. I also alphabetized the header and C++ files for lo-specfun because they were so complicated and alphabetical order seemed to be the lowest common organizing principle.
I don't want to step on your toes, so I'll give you a heads up that I intend to remove the Fortran code in liboctave/external/slatec-fn that we no longer use. In my opinion, it would be nice to shift away from Fortran when possible to C/C++ which matches the core language of the rest of Octave. Perhaps jwe can weigh in here if he has a different opinion. I think this principle should guide your thinking about how to tackle repairing or replacing special functions. In other words, if you find yourself coding elaborate input validation or workarounds for the existing code, for example the Bessel functions from amos, then do consider some alternate source like gnulib, GNU Scientific Library, etc. which are based on C rather than Fortran. And if you must write new code for an algorithm, do it in the m-file language or C++, rather than anything else.
On Wed, Jun 21, 2017 at 1:59 PM, Rik <[hidden email]> wrote:
Many special function will become available in C++17 standard (gcc7):
but already available in std:tr1 namespace (<tr1/cmath) in say gcc 4.8.5 (this is the oldest gcc I have available).
Could we use some configure magic to use them or stick with amos?
|Free forum by Nabble||Edit this page|