Why is *print-circle* set to T by default? WAS: grinding, etc.

Stavros Macrakis wrote:

> Michel,
> 
> The problems you describe below go away if you set *print-circle* to NIL.
>  As for creating a formula suitable for evaluation by C, I don't
>  understand
> why you're looking at grind or print at all: I'd think that you'd want to
> start with the code of the fortran command and modify it as necessary. 
> (I'd have thought someone has already written a Maxima-to-C printer.)
> 

Indeed these problems disappear. As to why i cannot start from the fortran 
command, or f90, it is because i want to produce formulas for multiprecision
computation which have awkward syntax such as pow(x, expnt) but also
add(x, y, z,...) instead of x+y+z, and similarly for all operations. This
is for using by some java program, and java doesn't allow overloading of 
operators +, *, ... so that only awkward syntax is available. I also need to 
write for Gnu GMP under C++, which has some nasty notations. Moreover i want 
to do these computations for complex numbers, so i have to promote reals to 
complex numbers when they appear in the expressions, etc. So it is very 
necessary to somewhat analyze the expressions.

Second i look at grind because i have discovered reading fortra.lisp that 
the bulk of work is indeed hidden in grind.lisp. In fact fortran does very 
little, sets some global variables and then delegates all work to grind.

Grind is complicated because it has to cut long lines, which is not really 
necessary here. But i have observed that things may be quite tricky since
Fateman has found useful to lift large parts of grind to write the tex 
command. Of course i want to follow this example but don't have the talent
to hack grind without understanding anything to how it works.

Finally it is true that maxima doesn't have a command to produce C syntax 
formulas, and this appears to be a major obstacle to maxima adoption by the 
people around me. Of course f2c is not a solution. For example it will never 
solve the multiprecision problem. I think it is a valuable aim to try to 
close this gap. You may say, why not directly use maxima or the underlying 
lisp to do the multiprecision computations? The people most involved in that
around me say that writing their programs in C++ with GMP allowed them to
get order of magnitude more speed that computing directly with maple (their 
tool of choice) and that this allowed them to gain an edge in their research 
against their colleagues. So if i want to be useful, there is no chance to
proceed in another direction ... 

An example of typical necessary computation
is diagonalizing 1000x1000 matrix with 150 digits. Lapack does that quickly 
but with double precision. For the problems at hand (Bethe ansatz problems)
this is akin to completely random Bethe roots. Maxima with bfloats has the 
precision but saturates at far smaller matrices. The problem is not to 
compute the roots of charpoly, in fact bfallroots is able to do that. But
getting charpoly is a major problem. The command charpoly() saturates very 
quickly. By computing the traces of powers of the matrix one gets indirectly 
the charpoly through Newton sums, but one cannot get far more than 100x100
matrices (with bfloat entries). But these Bethe ansatz problems grow ultra 
quickly, so at this point you have explored almost nothing. Another example 
is iteration of birational maps. By computing in C++ with many decimals you 
can iterate millions of times and still get reliable results. This allows to 
compute so-called "algebraic entropy" in cases unavailable to people using
exclusively maple or similar tools to do their iterations.




-- 
Michel Talon