11 Optimizer bug I had sent this mail to the aldor mailing group. I think it explains the bug I encountered. I don't think I need to produce more code than this explanation. The optimizer evaluated the index in A.(i+j+k) wrongly intermittently but did it right if I replace (i+j+k) with a variable. Hi Ralf, Thanks for your help on this problem! The code I sent was intended to give some idea of what I was doing. Luckily, I discovered that the problem was with the aldor optimizer. Down the road of compilation it did wrong additions because of the way I used some variables. As an Example: k had value 0, j also 0 and m 2 but the optimizer gave index k+j+m as 7 in some few instances when I tried to access an array with A.(k+j+m) instead of: kjm := k+j+m and then A.kjm. This was an intermittent problem that disappeard when I surrounded the code with extraneous stdouts but is fixed now at my code level. I will file a bug report later. As for the usage of the PrimeField, this is the spec: %27 >> PrimeField () @ (p: AldorInteger) -> ( PrimeFieldCategory with == PrimeField0(p) add () ) That means PrimeField(p:AldorInteger) is permissible. I have also been told by some Aldor experts to do "macro constv == value" which I do follow even though I don't see the penalty of constv == value to define a constant. Thanks again for all your time. Akpodigha. yes The optimizer evaluated the index in A.(i+j+k) wrongly intermittently but did it right if I replace (i+j+k) with a variable var:=i+j+k and then do A.var This can not be easily reproduced with a simple example. This also only occurs in packages as against local functions 2 1.0.2 afilatei@scl.csd.uwo.ca yes dk dk dk dk Q2 yes yes