Why does this code causes the machine to crash?

I am trying to run this code but it keeps crashing:

log10(x):=log(x)/log(10);
char(x):=floor(log10(x))+1;
mantissa(x):=x/10**char(x);
chop(x,d):=(10**char(x))*(floor(mantissa(x)*(10**d))/(10**d));
rnd(x,d):=chop(x+5*10**(char(x)-d-1),d);
d:5;
a:10;
Ibwd:[[30,rnd(integrate((x**60)/(1+10*x^2),x,0,开发者_运维知识库1),d)]];
for n from 30 thru 1 step -1 do Ibwd:append([[n-1,rnd(1/(2*n-1)-a*last(first(Ibwd)),d)]],Ibwd);

Maxima crashes when it evaluates the last line. Any ideas why it may happen?

Thank you so much.

The problem is that the difference becomes negative and your rounding function dies horribly with a negative argument. To find this out, I changed your loop to:

for n from 30 thru 1 step -1 do
  block([],
    print (1/(2*n-1)-a*last(first(Ibwd))),
    print (a*last(first(Ibwd))),
    Ibwd: append([[n-1,rnd(1/(2*n-1)-a*last(first(Ibwd)),d)]],Ibwd),
    print (Ibwd));

The last difference printed before everything fails miserably is -316539/6125000. So now try

rnd(-1,3)

and see the same problem. This all stems from the fact that you're taking the log of a negative number, which Maxima interprets as a complex number by analytic continuation. Maxima doesn't evaluate this until it absolutely has to and, somewhere in the evaluation code, something's dying horribly.

I don't know the "fix" for your specific example, since I'm not exactly sure what you're trying to do, but hopefully this gives you enough info to find it yourself.

If you want to deconstruct a floating point number, let's first make sure that it is a bigfloat. say z: 34.1

You can access the parts of a bigfloat by using lisp, and you can also access the mantissa length in bits by ?fpprec.

Thus ?second(z)*2^(?third(z)-?fpprec) gives you :

4799148352916685/140737488355328

and bfloat(%) gives you :

3.41b1.

If you want the mantissa of z as an integer, look at ?second(z) Now I am not sure what it is that you are trying to accomplish in base 10, but Maxima does not do internal arithmetic in base 10.
If you want more bits or fewer, you can set fpprec, which is linked to ?fpprec. fpprec is the "approximate base 10" precision. Thus fpprec is initially 16 ?fpprec is correspondingly 56.

You can easily change them both, e.g. fpprec:100 corresponds to ?fpprec of 335.

If you are diddling around with float representations, you might benefit from knowing that you can look at any of the lisp by typing, for example, ?print(z)

which prints the internal form using the Lisp print function.

You can also trace any function, your own or system function, by trace. For example you could consider doing this:

trace(append,rnd,integrate);

If you want to use machine floats, I suggest you use, for the last line,

for n from 30 thru 1 step -1 do :

Ibwd:append([[n-1,rnd(1/(2.0*n- 1.0)-a*last(first(Ibwd)),d)]],Ibwd);

Note the decimal points. But even that is not quite enough, because integration inserts exact structures like atan(10). Trying to round these things, or compute log of them is probably not what you want to do. I suspect that Maxima is unhappy because log is given some messy expression that turns out to be negative, even though it initially thought otherwise. It hands the number to the lisp log program which is perfectly happy to return an appropriate common-lisp complex number object. Unfortunately, most of Maxima was written BEFORE LISP HAD COMPLEX NUMBERS.

Thus the result (log -0.5)= #C(-0.6931472 3.1415927) is entirely unexpected to the rest of Maxima. Maxima has its own form for complex numbers, e.g. 3+4*%i.

In particular, the Maxima display program predates the common lisp complex number format and does not know what to do with it.

The error (stack overflow !!!) is from the display program trying to display a common lisp complex number.

How to fix all this? Well, you could try changing your program so it computes what you really want, in which case it probably won't trigger this error. Maxima's display program should be fixed, too. Also, I suspect there is something unfortunate in simplification of logs of numbers that are negative but not obviously so.

This is probably waaay too much information for the original poster, but maybe the paragraph above will help out and also possibly improve Maxima in one or more places.

It appears that your program triggers an error in Maxima's simplification (algebraic identities) code. We are investigating and I hope we have a bug fix soon.

In the meantime, here is an idea. Looks like the bug is triggered by rnd(x, d) when x < 0. I guess rnd is supposed to round x to d digits. To handle x < 0, try this:

rnd(x, d) := if x < 0 then -rnd1(-x, d) else rnd1(x, d);

rnd1(x, d) := (... put the present definition of rnd here ...);

When I do that, the loop runs to completion and Ibwd is a list of values, but I don't know what values to expect.