[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Bug 215: sin asin(7.0::COMPLEX FLOAT)
From: |
Gabriel Dos Reis |
Subject: |
Re: [Axiom-developer] Bug 215: sin asin(7.0::COMPLEX FLOAT) |
Date: |
17 Jan 2007 09:53:32 -0600 |
Waldek Hebisch <address@hidden> writes:
| The problem here is that sin asin(7.0::COMPLEX FLOAT) give something
| close to -7. This is due to wrong bunch cuts during evaliation.
| Namely in trigcat we have:
|
| asin x == atan(x/sqrt(1-x**2))
|
| this formula for asin has wrong branch cuts. When x is real and bigger
| then 1 sqrt(1-x**2) is imaginary with positive imaginary part. So
| x/sqrt(1-x**2) is imaginary with _negative_ imaginary part. atan has
| branch cut on %i*[-1, %minusInfinity], with jump discontinuity when
| real part goes to 0 trough positve values. This discontinuity means
| that values of asin are wrong (of opposite sign) for big real x.
|
| There is an easy workaround, put:
|
| asin x == -atan(-x/sqrt(1-x**2))
|
| However, the problem with asin is just one special case. We
| would like to support many multivalued special functions (which in
| numerical version require branch cuts). Tracking that we get
| "correct" values on cuts may well take significant portion of
| effert to implements those functions. OTOH computing with
| values on branch cuts does not seem very useful. So I am tempted
| to declare that arguments branch cuts are errors (like divison
| by 0).
I'm concerned with that approach.
After all, this is a mathematical computational platform. If we go
that way, how else can we expect other people to take branch cuts
seriously?
-- Gaby