Tommaso Cucinotta wants to merge 2 commits from /u/kefren/gnuplot/ to master, 2023-06-08
This patch adds the cubic root function, cbrt(), with name inspired to the cbrt() function of the C standard library, which pairs with the already supported sqrt().
With a negative argument, raising to the power of 1.0/3.0 gnuplot outputs a complex number. But, in such a case, the wanted behavior by users is the standard real cubic root, which is computed by the new cbrt() function.
In case the user applies it to complex numbers, then the function is also able to compute a standard complex cubic root (cubic root of magnitude, with angle divided by 3, i.e., the same as raising to 1.0/3.0).
Without this function, a user might define something like this
cbrt(x) = sgn(x)*abs(x)**(1/3.0)
but having directly the function in gnuplot would seem better :-)!
Thanks.
Your efforts to improve gnuplot are very welcome.
However, this implementation extends the real-valued function cbrt to the complex plane in such a way the the function ends up discontinuous (see attached plot). I am dubious that anyone using complex math would prefer this to the continuous complex extension provided by z**(1/3.)
Can you provide an example of use where this is "the wanted behavior by users"?
If the use case is real-only, would it not be better to provide a function that is explicitly limited to real domain and range?
you're absolutely right, it was an arbitrary extension. All in all, it probably makes sense to keep it for real values only. I've just reflected that in the updated patch (setting undefined to TRUE and returning { not_a_value(), 0.0 } -- just guessing from some other code in standard.c, if there's a better way, pls, let me know).
I like a lot that now I can easily
while the other way I get into the painful:
Thanks for your prompt reaction, I love gnuplot -- and contributing to its code would be fantastic!
T.
The idea is right, but I still have two reservations
First: cbrt() was added to the C standard math library with c99. You might think that a standard from 22 (um... 23) years ago would now be found everywhere but that turns out not to be the case. I have been moving towards an explicit requirement for c99 to build gnuplot but so far anything that requires it is hidden behind conditional configuration code so that the program will still build on older systems. That doesn't mean we couldn't add this, just that I think we would want to make the code conditional on a test for the C routine in the configuration script.
Second: Could you back up a step and present your rationale for deciding that wrapping a C library call is better than simply defining the function in
~/.gnuplot? I could understand wanting a hard-coded implementation for some complicated function that could potentially eat up a lot of cpu time if defined as a gnuplot (interpreted) function, but this doesn't seem to fall in that category.I've updated/refreshed the modification, with a 2nd commit adding configure-time check for cbrt(), and falling back to an alternate implementation using pow() in case the function is not found.
Very good observation about the ~/.gnuplot customization: my use-case derives mostly from the use of gnuplot for newbies. Personally, I've been using gnuplot over the last (20?) years in (almost all) my research papers, I'm a computer engineer, I can work-around any of my needs through scripting, UNIX piping, sometimes awk-ing/octave-ing and the likes :-), but still I like more to embed gnuplot scripts in BaSH scripts, rather than switching to Python & matplotlib.... However, I've also found myself in suggesting the use of gnuplot for high-school students due to its interactive plotting capabilities, esp. for visual inspection of 3D plots.... during some of these sessions, I stumbled across this lack of immediateness in plotting a cube root function, which seemed to be such an easy and basic functionality to add, and probably needed by others
https://stackoverflow.com/questions/36449046/plotting-of-parametric-functions-using-cubic-function-close-to-zero-generates-ga
https://groups.google.com/g/comp.graphics.apps.gnuplot/c/VzB6LDS-gxE/m/IZiK7qoT6w4J
... that I thought to add it myself to the program to start y2022 with something ;-P!
OK. It's merged. I added it to the documentation as well.
Thanks!
Great, and thanks for documenting the new function :-)!