2026-40-18 Denis Hugonnard-Roche : Fix #1206 And Faster Log Function

[dyoparis]

modified :         libcob/ChangeLog
modified :         libcob/coblocal.h
modified :         libcob/intrinsic.c
modified :         tests/testsuite.src/run_functions.at
modified :         tests/testsuite.src/run_misc.at

Fix ticket #1206 for FACT, EXP and EXP10 intrinsic functions by implementing limits
Add tests in run_misc.at to covr code .

cob_mpf_log:
implement a new algorithm that is about 4x faster
add test to run_functions.at to cover the new code (with
CHECK-PERF)
add other tests to cover all cob_intr_log and cob_intr_log10

[GitMensch]

This is hard to review now, please split this into multiple (3?) different PRs so each one solves exactly one issue.

[GitMensch]

... but I can indeed just try to go through each commit, as long as it is self contained.

I may have asked this again but how do you know about the mathematical basis needed to adjust the logic of the new code (which is in most cases "more complex" - but when gmp can perform that fast then that's no problem in general)?

[dyoparis]

... but I can indeed just try to go through each commit, as long as it is self contained.

I may have asked this again but how do you know about the mathematical basis needed to adjust the logic of the new code (which is in most cases "more complex" - but when gmp can perform that fast then that's no problem in general)?

Hi Simon

Regarding the PR i don't know how to create a PR for each commit :-(
i'll try to do taht in the following days
Rearding the commit only the last that fixe ticket of cob_decimal_pow is dependent of the previous as it used the constant limits i have implemented for fixing cob_intr_fact, exp and exp10

For the math part in fact it depends :)
Regarding cos .... i re implemented a method i have used just one year before my 'abitur' in 8 bits 6502 assembler !! :-)
i was participating at a computer club organized by my math teacher.

For log i have just took some math book to re study the log function and all his associated Taylor's series and i finally find a solution

For exp it was more complicated as i have study several 'complicated' paper of numerical analysis and i finally peek up the 'simplest' adapted to GnuCobol context

But the pure mathematical parts are not the only thing : the way of reducing argument value close to 0 to make the series convergence faster is very important , without loosing the initial precision of the GnuCobol previous implementation

To do that, i systematically verified the precision by confronting my result to mpfr which is the reference in term of arbitrary precision math library

[GitMensch]

I've already started to inspect the exp stuff which seems self-contained and think I understand the general math concept behind it now.
So I'll go for integrating that soon.

[dyoparis]

I've already started to inspect the exp stuff which seems self-contained and think I understand the general math concept behind it now. So I'll go for integrating that soon.

hello .
ok . i think exp needs the previous commit as it needs the cob_log_two new constant

[GitMensch]

Coming back to this... also because I've seen a pre-production issue with the current implementation. The nice thing: that provides an additional testbad.

@dyoparis: Can you please rebase this PR (also in the hope to see the CIs passing now)?
Also: Would it be bad to cache input+result in cob_mpf_log and cob_mpf_exp (note: those are static functions, if we don't see why those directly should be put into the generated C code, we may drop the "external" cob_ prefix) , especially as those functions are used in cob_decimal_pow.1
The issue on the customer side has shown to be a loop where only one part of the A = B ** C side changes (subscript), the other part has the exact same input data; still it is calculated over and over again.

(improved on the code in question by moving to explicit EXP + LOG so the calculation is done only once on the COBOL side - but that additional COBOL intermediate takes more time and looses mopre precision than keeping the intermediate result cached in libcob)

Not sure how that effects performance in the common case "both decimals change their value".

In theory we could also come to the conclusion "good idea but needs to be deduced by the compiler and only if a side is likely to be identical then generate different code".