arcsin, arccos reject valid arguments
Hi,
I am using SpeedCrunch 0.12 on Windows 10 (64-bit). I have noticed that the built-in arccos and arcsin seem to erratically reject valid arguments saying "undefined for argument domain".
For example: arcsin(0.2) -> OK arcsin(0.25) -> "undefined" arcsin(0.251) -> OK arcsin(0.2511) -> "undefined" arcsin(0.25111) -> OK
Replacing arccos for arcsin, I get exactly the same sequence of results, so I figured it might be a problem with the parser?
Thanks for investigating this.
Best regards, Martin
Comments (9)
-
-
Ok, got it. The issue occurs if in degree mode with complex numbers enabled.
I'll look into it.
-
The issue is the following:
- With complex numbers enabled,
arcsin
uses the complex definition involving square roots and logarithms to compute the result. - Rounding errors introduce a small imaginary part, on the order of 10^-80.
- The result is still in radians, so we convert it to degrees. The corresponding code checks if the number is real, because otherwise the conversion makes no sense (geometrically speaking).
- The rounding error kills it.
Not sure what our policy should be here. We could just make it so that the user cannot enable complex numbers while in degrees mode and vice versa.
Maybe the easiest solution would just be to remove the check to see if the 'angle' is real. Is ther any important reason for it, apart from the fact that a complex angle makes no geometric sense? I don't remember us putting it in place to fix some specific bug.
Let's decide on either approach, and I'll prepare a PR.
EDIT: Apparently some people argue that complex angles do make sense. Duh. I'll do that then.
- With complex numbers enabled,
-
Allow complex values to be displayed in degrees
See issue
#781for context. Also re-encoded functions.cpp in unicode.→ <<cset 520c3d0310c7>>
-
-
assigned issue to
- changed milestone to 1.0
- changed component to mathengine
Submitted pull request #92.
-
assigned issue to
-
Hi Pol,
Thank you so much for looking into this and submitting a patch so quickly, that's awesome!
Best, Martin
-
repo owner - changed status to closed
-
Issue
#1038was marked as a duplicate of this issue. -
Issue
#1055was marked as a duplicate of this issue. - Log in to comment
Hi Martin,
I cannot reproduce that behaviour. Can you post some more details about the output, e.g. the exact numbers for those lines that do not fail? Also tell us what your settings are, specifically if you have complex numbers enabled or not.
Could it be that you set the decimal separator to
,
instead of.
? See Settings -> Input Format -> Radix Character. Then it would rejectarcsin(0.2) = arcsin(2)
, provided that complex numbers are disabled.