"Simpler" bigfloat and complex bigfloat arithmetic

R Fateman wrote:
> An alternative design that I used in my generic arithmetic package
> (free/....) is to do the conversion this way:
>
>  have the program that makes a number into a bigfloat called "to"
>  have the program that makes a number into a quadfloat called "to"
>  ...etc
> and have the packages make the difference.
>
> e.g.  (generic:+    (bigfloat:to  3) (bigfloat:to 1/2))
I'm certainly open to having the appropriate interface that makes it
easy for users.

In this case, I'd would certainly like (coerce 3 'bigfloat) to work. 
Haven't implemented that yet and there are various issues with doing
that.  In any case, we need some function to convert maxima's internal
bigfloat representation to a bigfloat object.  Haven't done that either.
>
> With the right declarations for package usage you can eliminate some
> of the package
> qualifications.
Yeah, I think typical usage would have an (in-package "NUMERIC") to get
rid of the package qualifiers. 

One thing that would be nice to have is to modify the existing routines
for special functions to use the new objects, since reading and writing
bigfloat code is a bit difficult.  (It's fpplus and fpminus but fpminus
is unary minus, not binary, which is fpdifference.  It's fptimes* not
fptimes,.  There's fpgreaterp and fplessp, but no
fpgreater-or-equal-p.)  But the existing code works, so perhaps this
isn't worth doing.

One issue with the current numeric code is that for some of the special
functions it calls mevalp to compute them.  I think it would be nicer
not to have to do that.  A nice side-effect, though, is that the numeric
package always computes EXACTLY what maxima would otherwise have computed.

Ray