[Maxima-discuss] another complex bfloats proposal

[Andrei Z. <zoa...@gm...>]

Dear group,

I've still been thinking about computing with complex numbers with bfloat
reap and imaginary parts. As I tried to explain in September, I need to
perform computing with bfloats and complex numbers, preferably with as many
automatic simplifications  as possible and without lots of conversions
to/from rationals. (In particular, these conversions seem to occur when I
ask for an %e^bfloat as a bfloat: I call rectform of bfloat of a temporary
value over and over again...).

Despite my recent criticism I do like Maxima and consider using it as my
major tool.

I don't have a solution for rat/bfloat conversions, but I have an idea
about complex numbers with bfloat parts. Here it is: one can add a flag in
the internal form of such an expression, so it looks like
     ((mplus bfcomplex) a ((mtimes) b $%i)
where a and b are either MNUMBERs or BFLOATs. Then, the multiplication
routine like SIMPTIMES can consider only such special cases and carry out
expansion and simplification of a product like
     ((mplus bfcomplex) a1 ((mtimes) b1 $%i) * ((mplus bfcomplex) a2
((mtimes) b2 $%i)
This approach seems attractive to me since:
1)  it doesn't actualy introduce a new primitive type to Maxima (as opposed
to the approach in src/numerics.lisp - another attempt to introduce
bigfloat complex numbers with aim at efficiency, but I expect same issues
with requests to fully incorporate this new datatype to the Maxima
kernel/simplifier)
2) it doesn't break anything working right now - we just add one new flag
which will be ignored by default
3) fixes at different places in the kernel code to add this flag, when a
new expression of the form a+b*%i is constructed, can be done
incrementally, steadily improving coverage of this new feature
4) annoying unneccesary factors as in 1.0*(2+4*%i) will be finally cleared
out.

Andrei Zorine