[Aldor-l] Aldor Problem

[Ralf Hemmecke]

Hi Akpodigha,

I cannot compile your code. It is incomplete. Neither 
FFTMultiplicationPackage nor PrimitiveRootOfUnitFinder is in my Aldor 
distribution. So I cannot reproduce your bug. Maybe it is even better do 
file your problem with complete code at
http://www.aldor.org/bugreport.html
so that the compiler people can try to trace the bug. I cannot because, 
I don't have the compiler sources.

But perhaps I can give some experiences with some constructions.

 > p:Z := 17;
 > K == PrimeField(p);

I really wonder whether this should compile at all. p is a variable here 
and thus the compiler should reject it as an argument to PrimeField. 
Only constants are allowed as an argument to a domain constructor.

A workaround would be to put things inside a function

foo(p: Z): () == {
   K == PrimeField p;
   U == DenseUnivariatePolynomial(K,-"x");
    ...
}

and then call foo(17).

Further, I remember that I often had problems with defining domain 
constants in my code. Like the

   K == PrimeField p;

line above. I was told by some Aldor developer long ago that I should 
try something like
   macro K == PrimeField p;
instead. I don't know what the compiler does exactly in both cases, but 
if one looks at instantiations in both cases PrimeField(p) gets only 
instantiated once even if it is used later several times.
If some compiler developer could say some words here, I would be happy.

Ralf

Akpodigha Filatei wrote:
> 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()