Re: [Axiom-developer] Bug 215: sin asin(7.0::COMPLEX FLOAT)

[Waldek Hebisch]

Gabriel Dos Reis wrote:
> Waldek Hebisch <address@hidden> writes:
> | 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? 
> 

1)
What can be more serious than signaling error?

2) 
I am mathematician and I do not "take branch cuts seriously".
Serious math works with arbitrary branches, multivalued functions
or Riemennian surfaces.  Branch cuts are an artifical convention
which pretends that multivalued functions can be used naively in
numerical computations.  In some sense it is an ideal field for
standarisation: many choices are arbitrary, but for effective
shortcut communication everybody should use the same choices.
However, standarizing branch cuts produces a formal structure
which has little to do with original functions.  Once such structure
is available there is good chance that somebody will abuse it to
archive some good effect.  But in most cases it would be better to
use another mechanizm.  More specifically, serious complex numerical
computation can not depend on values on branch cuts -- simply
because of rounding error you never know whether you are exactly
on branch cut (you can only guarantee that you stay _away_ from
branch cut).  So, only relatively trivial formulas (where you
can fully anayze roundoff) can use values on branch cuts.  But
even then, it may well turn out (as is in our case) that the
values in not the needed one.

-- 
                              Waldek Hebisch
address@hidden