[Aldor-l] Aldor Problem

[Akpodigha Filatei]

On Tue, 27 Sep 2005, Ralf Hemmecke wrote:
Thanks Ralf for your reply.  I have corrected my algebrad usage according 
to the documentation you referred to with same result.
Pasted below is the content of a revised dfttest.as.  Here I test the 
'dft' 
in the package aliased as FFTMPKG against an exact (same) function local 
to dfttest.as and got diff results with -lalgebra but correct same result 
with -lalgebrad.

One more weird thing about this is that I could get it to work by placing 
"stderr" or "stdout" in the dft function at the package.  This, I noticed 
by chance as I was profiling the function.  It is taking me a heck of a 
time to specify exact location and minimum number of stderr/stdout statements that 
would make it make but I am willing to do this.

I think you are right to say this is a compiler bug but I am working on 
a work-around as I have had to do in some other instances.

#include "algebra"

macro {
         Z==Integer;
         MI == MachineInteger;
         FFTMPKG == FFTMultiplicationPackage;
         PRUF == PrimitiveRootOfUnityFinder;
}

import from TextWriter,String,Character,Symbol;
p:Z := 17;

K == PrimeField(p);

U == DenseUnivariatePolynomial(K,-"x");
PAK == PrimitiveArray K;

import from K,U,FFTMPKG(K,U),Partial(K), PRUF(K);
import from PAK,MI;
x == monom;

main():() == {
     local n,k:MI;
     Y1:U := x^(3 at Z) + x^(2 at Z)+x+1::K::U;
     Y2:U := x^(3 at Z) + (3::K)*x + 1::K::U;

     s:MI := fftSize(Y1,Y2);
     stdout << "fftSize? "<< s <<newline;

     n := shift(1,s); -- 2^s
     ww:Partial(K) := primitiveRootOfUnity(n);

     assert( not failed?(ww) );

     w := retract(ww);

     y1a:PAK := new(n,0$K);
     y11a:PAK := new(n,0$K);

     kk := 0;
     for k in coefficients(Y1) repeat {
         y1a.kk := k;
         kk := next(kk);
     }

     wp:PAK := omegaPowers(w,n);

     stdout << " DFT TEST ----- " << newline;

     dftres11:PAK := dftt(s,y1a,wp);
     dftres21:PAK := dft!(s,y1a,wp);

     stdout<<"dft local [";
     for k in 0..prev(n) repeat {
         stdout  << dftres11.k <<" ";
     }

     stdout<<"]"<<newline;

     stdout<<"dft from package [ ";

     for k in 0..prev(n) repeat {
         stdout  << dftres21.k <<" ";
     }
     stdout<<"]"<<newline;

}

dftt(s:MI,pol:PAK,wp:PAK):PAK == {....}

main()













> Could you send a clearer bugreport. I don't have the file dfttest.as so I 
> cannot say anything.

> Just one comment. If you use the library algebrad, then you should also use 
> aldord and the -DDEBUG switch. See section "Profiling and debugging" in the 
> "Algebra User Guide and Reference Manual"
> http://www-sop.inria.fr/safir/WHOSWHO/Manuel.Bronstein/algebra/index.html
>
> Usually, if code compiled against the debug version of the library gives a 
> correct result and compiled against the ordinary library returns something 
> wrong then it is an indication of a bug in the compiler itself.
>
> Ralf
>
> Akpodigha Filatei wrote:
>> 
>> 
>> Hi All,
>> The same piece of aldor code  when compiled with the -l algebra or -l 
>> algebrad library flags give different results.  The result from algebrad is 
>> correct but that from algebra is wrong.  Any of you encountered this in the 
>> past?  Any known fix?  Compiler version is 1.0.3 with latest libalgebra.
>> 
>> e.g
>> [afilatei at medium FFT]$ aldor -lalgebrad -laldor -Fx dfttest.as
>> [afilatei at medium FFT]$ ./dfttest
>> dft! w shf [5 61394 513 53234 65534 4145 65026 12305 ]    <--- correct 
>> result
>> 
>> [afilatei at medium FFT]$ aldor -lalgebra -laldor -Fx dfttest.as
>> [afilatei at medium FFT]$ ./dfttest
>> dft! w shf [5 57298 256 53217 65534 8241 65281 12320 ]  <--- wrong result
>> 
>> The package was defined thus:
>> FFTMultiplicationPackage(K:Field,U:UnivariatePolynomialAlgebra(K)): with {
>> 
>> If the function with the problem is written as a standalone it gives 
>> correct results in both cases.  So, I am about to suspect either of "Field" 
>> or "UnivariatePolynomialAlgebra" implementation in libalgebra. What say any 
>> of you?
>> 
>> More info:  I have already implemented the same code in C++ (NTL) 
>> successfully which gives me additional reason to believe that the code 
>> might be correct.
>> 
>> Thanks
>> 
>> 
>> Filatei
>

-- 
Regards

Filatei
http://www.scl.csd.uwo.ca/~afilatei