[Aldor-l] Aldor Problem

Akpodigha Filatei filatei at gmail.com
Wed Sep 28 21:28:40 EDT 2005


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.



On 9/28/05, Ralf Hemmecke <ralf at hemmecke.de> wrote:
>
> 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 <http://dfttest.as>.
> Here I test the
> > 'dft' in the package aliased as FFTMPKG against an exact (same) function
>
> > local to dfttest.as <http://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()
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.aldor.org/pipermail/aldor-l_aldor.org/attachments/20050928/333d4d37/attachment-0001.html>


More information about the Aldor-l mailing list