Menu
▾
▴
#409 "step" fails for negative values
Using Maxima 5.9.0 (GCL, Debian package 5.9.0-11), I
have tried out a simple "for" loop from -3 to 3, and
then the same loop in reverse order from 3 to -3. The
second one fails:
(C10) x1: -3$
(C11) x2: 3$
(C12) p: 5$
(C13) for x:x1 step (x2-x1)/p thru x2 do display(x);
x = - 3
9
x = - -
5
3
x = - -
5
3
x = -
5
9
x = -
5
x = 3
(D13) DONE
(C14) x1: 3$
(C15) x2: -3$
(C16) for x:x1 step (x2-x1)/p thru x2 do display(x);
(D16) DONE
In this second case I had to use a '' that was not
necessary in the first case:
(C17) for x:x1 step ''(x2-x1)/p thru x2 do display(x);
x = 3
9
x = -
5
3
x = -
5
3
x = - -
5
9
x = - -
5
x = - 3
Logged In: YES
user_id=588346
Yes, the current code for DO foolishly assumes that the
step's sign can be determined from the syntactic form of the
unevaluated step expression, but it also (peculiarly) re-
evaluates the step each time around the loop. It also uses
the most generic way of comparing things (is), but I suppose
that ensures that it will correctly handle fixnums, floats,
bfloats, rats, and possible etc.'s.
So we have such lovely nonsense as:
q:-1$
for i : 1 thru -5 step q do print(xxx)
... does nothing because "q" is syntactically positive
for i step i thru 10 do print(i)
... prints 1 2 4 8
... note re-evaluation of i each time through
for i:1 thru 20 step i*2-i do print(i);
... note trick for multiplicative counting
for i:1 thru -8 step -i*2-i do print(i);
... even alternating sign... but why does it end with 16?
=> 1 , - 2 , 4 , - 8 , 16
assume(u>0,v>0);
for i:u step v thru u+10*v do print(i);
... amazing, eh?
The solution is to evaluate step exactly once.
Logged In: YES
user_id=501686
Still present in 5.9.3cvs.
Problem stated in bug description fixed by commit c767d782ee.
Also,
prints xxx 7 times. So that''s fixed now.
As to the examples in which the loop variable appears in the step expression, I claim those are handled correctly now: if the loop variable is bound to some value before the loop, then that value is used, otherwise, the step expression evaluates to the loop variable (e.g. step i --> i, when i is not already bound), and therefore the step value is the value of the loop variable. Unless we want to prohibit such expressions (which would be reasonable, I guess, given their ambiguity), I don't see how else they could be interpreted.
The final example doesn't seem to be a bug, and it works the same in the current version of Maxima (5.29+commits).
The original problem is fixed, and I don't see any remaining problems. If someone wishes to argue otherwise, I hope they'll open a new bug report, so that this one isn't cluttered.