#1151 error evaluating asinh(-1)


gnuplot> print asinh(-1)
# asinh(-1) might be of the opposite sign...

gnuplot> print sinh(asinh(-1))
gnuplot> print sinh(-1*asinh(-1))

Version 4.6 patch level 0


  • Ethan Merritt

    Ethan Merritt - 2012-07-12

    Ironically, the analogous bug was fixed over a year ago for sin/asin (Bug #2879772).
    Apparently the same "fix" was also applied to the code for sinh/asinh even though it wasn't needed, thus breaking it rather than fixing it. So I think we can just revert that "fix".

    thanks for the report

  • Ethan Merritt

    Ethan Merritt - 2012-07-12
    • assigned_to: nobody --> markisch
  • Ethan Merritt

    Ethan Merritt - 2012-07-12

    Could you have a look at this, revisiting your patch of May 2011?
    Reverting it altogether would reintroduce the original problem, but the current code isn't correct either. Check for example

    plot sinh(asinh(x)) / x # should equal 1 everywhere, right?


    set xr [-10:10]; set yr [-10:10]; set cbr [-10:10]; set isosampl 50,50
    set view map
    splot '++' using 1:2:(imag((asin((sin( $1 + $2*{0,1} )))))) with pm3d

    # should this really flip sign for different ranges of the real component?

  • Ethan Merritt

    Ethan Merritt - 2012-07-12
    • assigned_to: markisch --> nobody
  • Ethan Merritt

    Ethan Merritt - 2012-07-12

    I misread the but report. Sorry. I though the issue was asinh(x) for x with an imaginary component. That was the trigger for the earlier bug/fix that I referred to.

    The specific case you give as an example is not a bug, since by definition asinh(x) > 0 for real x.

    asinh(z) = ln( z + sqrt( z**2 + 1) )

    Nevertheless there is a bug lurking here, so thank you for forcing me to look into these functions more deeply. I have attached a script that tests the various trig functions for complex input and output. It sets up a color map for the complex plane such that the resulting plots can be compared to the ones on wikipedia created using Mathematica:

    The test script shows that asin(), sinh(), asinh() are working correctly, as are cosh(), acosh() and tanh(), atanh().

    But acos() is broken. A fix is attached.

    Prior to last year's fix, asin() and asinh() were also broken, as shown by running the test script though gnuplot version 4.4.0.

  • Ethan Merritt

    Ethan Merritt - 2012-07-12

    acos(z) returns incorrect values when imag(z) > 0

  • Ethan Merritt

    Ethan Merritt - 2012-07-12

    test script to exercise trig functions with complex input

  • Hans-Bernhard Broeker

    > since by definition asinh(x) > 0 for real x.

    Huh? Surely you're joking. asin() is negative for negative arguments. It has to be.

  • Hans-Bernhard Broeker

    • assigned_to: nobody --> markisch
  • Bastian Märkisch

    Patch to sin and sinh, partially reverting the change of March 2011

  • Bastian Märkisch

    test cases for asin and asinh

  • Bastian Märkisch

    The patch of March 2011 got the (x == 0.0) case wrong, both in f_asin and f_asinh. The attached patch partially reverts the changes. I also attached a script with various test cases.

  • Ethan Merritt

    Ethan Merritt - 2012-07-18

    I have commited the fix for acos() to both 4.6 and 4.7

    WIth acos fixed, the problem with asin is now easily seen using test plot
    plot imag(acos(x*{0,1})), imag(pi/2 - asin(x*{0,1}))

    Compare with
    plot imag(acos(0.01 + x*{0,1})), imag(pi/2 - asin(0.01 + x*{0,1}))

    Please go ahead and commit the asin/asinh fixes also.

  • Bastian Märkisch

    Thanks again for the report. Now fixed in CVS for 4.6 and 4.7.

  • Bastian Märkisch

    • status: open --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks