> 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.
Maybe in some areas of the code, but where I've been looking, there are
vast swathes that look identical to the Maclisp code I remember from the
1970's (not excluding my blunders). But if we converted all RATs to
Common Lisp rationals (for example), there'd be no going back.
About branches, I do think at some point one of us (I suspect I will end
up doing it, but I am promising nothing) needs to go through and check
CL built-ins, float ops, bfloat ops, simp, hayat, and rpart for
consistency in branch cuts as well as consistency with usual
mathematical conventions. Then at least we will know where we agree and
disagree with CL conventions.
> Yep. The sleazy way out is to just bump up fpprec for the computation
> and then reduce it for the final result.
To get sinh(1.0b-10) correct to 16 places, you need fpprec=25, and to
get sinh(1.0b-2000) correct to 16 places, you need fpprec=2015. That
doesn't seem like a practical solution to me....
-s