Hi Simon
I have finished a project I started a few months ago: an implementation of an algorithm for calculating the ln function that is approximately four times faster.
Looks quite interesting! I'm eager to run the tests with the old/new code and "in case of performance check run the tests multiple times" under perf to see the differences.
Giving the new testcase, I guess you've already checked the coverage [6a98be0ba0] of your function to be complete.
Can you please reformat (we use leading tab for example and no trailing space before/after ";")? That makes comparing changes easier.
The one thing I wonder before testing the patch: do we need all the temporary mpf_t (and allocate/free them)? Aren't there other temporary mpf_t that stay alive after first use until teardown which can be reused?
It seems to me that this will be the easiest to integrate of your changes so I'd love to do that within the next two days.
- performance
- result give the same results that the old one (12500 values )
I even compare with mpfr to be sure :-)
I will send you tomorow thye bench package it will be easier for you to check.
1) Code Coverage :
Yes the coverage is complete (expect the case scr_val is 0 as cob_intr_log does not call the cob_mpf_log in this case)
2) Code formating --> yes ... i loose the tab du to copy/paste :-)
3) Regarding the number of temporaries mpf i have check that all are needed as it is a critical point regarding the performances ... but il will recheck (NB there are no more temporaries mpf_t than in the original :-) )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Simon
Here are the test attached
The test : we take un base number en mutiply it by another number and compute the log of the result
the param.h contains the base number, the multiplier the number of loop and the number of digits tp compare
Denis
git-clang-format could definitely be used, but only when operating on a git mirror.
Adjusting the python script, possibly via a coding agent, should make it possible to use it as svn-clang-format (a quick check at their issue tracker didn't show any effort on that yet).
... but the first part would be to create a .clang-format file that matches our style; last time I've checked it was not possible to do a 1:1 translation (but at least an overall start and the python scripts run the formatter only on the changed lines and create an unstaged change for easy compare allowing to easily integrate only the changes you want and adjust/ignore the rest [as svn has no staging the adjusted script may use a second file]).
... nowadays I'd let an agent figure out "the best" (=good) match; I may let OpenCode do that (there's no reasonable thought of infringement or necessary copyright on the formatter definition, so using an LLM output is fine here - it isn't for GnuCOBOL's source code).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another question
Why is there only cob_mpf_log and cob_mpf_exp that COB_MPF_CUTOFF to test the end of the series ?
All other functions (sin, cos ..) use COB_MPF_PREC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Simon
do you want me to integrate the patch for ln an for the ticjer #1206 in my github repo in order to create a pull request (now that i begin to use git & github serioulsy , may ba it would be good to have all in github)
Denis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Feel free to do so (note: having at least a "hint" here is always good, as GitHub will only be a mirror - but learning git + PR workflows is good, as that will be nearly identical when we migrate from here to codeberg late[r] this year).
I hope to get back to the PRs (and other open issues) when some of the load at work is down again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks quite interesting! I'm eager to run the tests with the old/new code and "in case of performance check run the tests multiple times" under perf to see the differences.
Giving the new testcase, I guess you've already checked the coverage [6a98be0ba0] of your function to be complete.
Can you please reformat (we use leading tab for example and no trailing space before/after ";")? That makes comparing changes easier.
The one thing I wonder before testing the patch: do we need all the temporary mpf_t (and allocate/free them)? Aren't there other temporary mpf_t that stay alive after first use until teardown which can be reused?
It seems to me that this will be the easiest to integrate of your changes so I'd love to do that within the next two days.
Related
Discussion: 6a98be0ba0
Hi Simon
I have bench the function in two ways :
I even compare with mpfr to be sure :-)
I will send you tomorow thye bench package it will be easier for you to check.
1) Code Coverage :
Yes the coverage is complete (expect the case scr_val is 0 as cob_intr_log does not call the cob_mpf_log in this case)
2) Code formating --> yes ... i loose the tab du to copy/paste :-)
3) Regarding the number of temporaries mpf i have check that all are needed as it is a critical point regarding the performances ... but il will recheck (NB there are no more temporaries mpf_t than in the original :-) )
Hi Simon
Here are the test attached
The test : we take un base number en mutiply it by another number and compute the log of the result
the param.h contains the base number, the multiplier the number of loop and the number of digits tp compare
Denis
and here si the patch with tab restored
By the way : do you know a tool to reformat teh C code according to GnuCobol standards ?
git-clang-format could definitely be used, but only when operating on a git mirror.
Adjusting the python script, possibly via a coding agent, should make it possible to use it as svn-clang-format (a quick check at their issue tracker didn't show any effort on that yet).
... but the first part would be to create a .clang-format file that matches our style; last time I've checked it was not possible to do a 1:1 translation (but at least an overall start and the python scripts run the formatter only on the changed lines and create an unstaged change for easy compare allowing to easily integrate only the changes you want and adjust/ignore the rest [as svn has no staging the adjusted script may use a second file]).
... nowadays I'd let an agent figure out "the best" (=good) match; I may let OpenCode do that (there's no reasonable thought of infringement or necessary copyright on the formatter definition, so using an LLM output is fine here - it isn't for GnuCOBOL's source code).
Another question
Why is there only cob_mpf_log and cob_mpf_exp that COB_MPF_CUTOFF to test the end of the series ?
All other functions (sin, cos ..) use COB_MPF_PREC
Hi Simon
do you want me to integrate the patch for ln an for the ticjer #1206 in my github repo in order to create a pull request (now that i begin to use git & github serioulsy , may ba it would be good to have all in github)
Denis
Feel free to do so (note: having at least a "hint" here is always good, as GitHub will only be a mirror - but learning git + PR workflows is good, as that will be nearly identical when we migrate from here to codeberg late[r] this year).
I hope to get back to the PRs (and other open issues) when some of the load at work is down again.
Ok .
By the way i manage to have a version of cob_mpf_exp that on my pc is between 4 and 5 times faster .