>>>>> "Stavros" == Stavros Macrakis <stavros.macrakis@verizon.net> writes:
>> I think the code is getting sufficiently Common Lispy that this is
>> going to be hard if that decent Lisp isn't a full Common Lisp.
Stavros> Maybe in some areas of the code, but where I've been looking, there are
Stavros> vast swathes that look identical to the Maclisp code I remember from the
Stavros> 1970's (not excluding my blunders). But if we converted all RATs to
Stavros> Common Lisp rationals (for example), there'd be no going back.
Agreed. But I expect more of the code to be come CL as things are
fixed or new things added.
Stavros> About branches, I do think at some point one of us (I suspect I will end
Stavros> up doing it, but I am promising nothing) needs to go through and check
Stavros> CL built-ins, float ops, bfloat ops, simp, hayat, and rpart for
Stavros> consistency in branch cuts as well as consistency with usual
Stavros> mathematical conventions. Then at least we will know where we agree and
Stavros> disagree with CL conventions.
A very good idea. I'll help if I can. We probably also need to
decide that, if they're maxima and CL disagree, which branch cuts do
we really want.
>> Yep. The sleazy way out is to just bump up fpprec for the computation
>> and then reduce it for the final result.
Stavros> To get sinh(1.0b-10) correct to 16 places, you need fpprec=25, and to
Stavros> get sinh(1.0b-2000) correct to 16 places, you need fpprec=2015. That
Stavros> doesn't seem like a practical solution to me....
I did say sleazy, not good. But why do we need 2015 digits for
sinh(1.0b-2000)? Since sinh(x) ~ x + x^3/6 = x*(1+x^2/6), once x^2/6
is less than 16-digits, I'll have sinh(x) accurate to 16 digits. And
this happens for x ~ 2.5e-8 or so. Or did I screw up again?
Ray