From g.vanuxem at wanadoo.fr  Sun Sep  4 10:00:57 2005
From: g.vanuxem at wanadoo.fr (Vanuxem =?ISO-8859-1?Q?Gr=E9gory?=)
Date: Sun, 04 Sep 2005 16:00:57 +0200
Subject: [Aldor-l] AMD 64 ports
In-Reply-To: <430103FB.3020101@hemmecke.de>
References: <430103FB.3020101@hemmecke.de>
Message-ID: <1125842457.10238.1.camel@localhost.localdomain>

Hi,

I'm asking if aldor will be ported to AMD 64 in a near future.
What do you think.


Cheers,

Greg




From bill.page1 at sympatico.ca  Sun Sep  4 12:03:46 2005
From: bill.page1 at sympatico.ca (bill.page1 at sympatico.ca)
Date: Sun, 4 Sep 2005 12:03:46 -0400
Subject: [Aldor-l] AMD 64 ports
In-Reply-To: <1125842457.10238.1.camel@localhost.localdomain>
Message-ID: <000201c5b16a$40df6880$6400a8c0@asus>

On September 4, 2005 10:01 AM Vanuxem Gr?gory wrote:
> 
> I'm asking if aldor will be ported to AMD 64 in a near future.
> What do you think.
> 

On August 31, 2005 10:37 AM I received the following reply from
Laurentiu Dragan [mailto:ldragan at uwo.ca] (Aldor compiler maintainer)
Re: compiling Aldor from source for x86-64 (AMD 64).

I wrote to Stephen concerning access to the source code so that
I could do the build myself but so far I have not had any response.

Regards,
Bill Page.

> 
> 
> Dear Bill Page,
> 
> The sources for the compiler are not open, only libaldor and 
> libalgebra.
> 
> Currently we don't have a 64bit version of aldor for linux.  
> If you want access to the sources you should email Stephen
> Watt at watt at aldor.org and ask him.  We'll try to build aldor
> on FC3 x86-64 to produce 64bit binaries.
> 
> Regards,
> --
> Laurentiu Dragan
> 
> Bill Page wrote:
> > Laurentiu Dragan or Cosmin Oancea,
> > 
> > I am one of the current developers of the open source version
> > of Axiom. Recently Peter Broadbery completed the re-integration
> > of Aldor as a library compiler for Axiom. (You might know that
> > Aldor used to be sold as part of the commercial version of Axiom).
> > I am building Axiom under Fedora Core 3 on x86-64 architecture.
> > Axiom works fine on this platform but the linux binary version
> > of Aldor form http://www.aldor.org fails because the compiler
> > produces 64-bit code but libfoam.a is build for 32-bits. This
> > is the error message that I get:
> > 
> > ...
> > /usr/bin/ld: skipping
> > incompatible /usr/local/aldor/linux/1.0.2/lib/libfoam.a 
> > when searching for -lfoam
> > 
> > --------
> > 
> > I would like to be able to build Aldor from sources. Would it
> > be possible for you to register me as an Aldor developer so that
> > I can access the aldor CVS?
> > 
> > Thanks in advance.
> > 
> > Regards,
> > Bill Page.
> > http://www.axiom-developer.org
> > 




From afilatei at scl.csd.uwo.ca  Mon Sep 26 22:44:03 2005
From: afilatei at scl.csd.uwo.ca (Akpodigha Filatei)
Date: Mon, 26 Sep 2005 22:44:03 -0400 (EDT)
Subject: [Aldor-l] Aldor Problem
Message-ID: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>


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


From ralf at hemmecke.de  Tue Sep 27 07:39:39 2005
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 27 Sep 2005 13:39:39 +0200
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
Message-ID: <43392F7B.7060809@hemmecke.de>

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


From afilatei at scl.csd.uwo.ca  Tue Sep 27 20:33:33 2005
From: afilatei at scl.csd.uwo.ca (Akpodigha Filatei)
Date: Tue, 27 Sep 2005 20:33:33 -0400 (EDT)
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <43392F7B.7060809@hemmecke.de>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
 <43392F7B.7060809@hemmecke.de>
Message-ID: <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>

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


From ralf at hemmecke.de  Wed Sep 28 06:32:37 2005
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 28 Sep 2005 12:32:37 +0200
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca> <43392F7B.7060809@hemmecke.de> <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>
Message-ID: <433A7145.3030404@hemmecke.de>

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()


From filatei at gmail.com  Wed Sep 28 21:28:40 2005
From: filatei at gmail.com (Akpodigha Filatei)
Date: Wed, 28 Sep 2005 21:28:40 -0400
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <433A7145.3030404@hemmecke.de>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
	 <43392F7B.7060809@hemmecke.de>
	 <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>
	 <433A7145.3030404@hemmecke.de>
Message-ID: <d95dd910509281828624b3d33@mail.gmail.com>

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://aldor.org/pipermail/aldor-l_aldor.org/attachments/20050928/333d4d37/attachment.html 

From g.vanuxem at wanadoo.fr  Sun Sep  4 10:00:57 2005
From: g.vanuxem at wanadoo.fr (Vanuxem =?ISO-8859-1?Q?Gr=E9gory?=)
Date: Sun, 04 Sep 2005 16:00:57 +0200
Subject: [Aldor-l] AMD 64 ports
In-Reply-To: <430103FB.3020101@hemmecke.de>
References: <430103FB.3020101@hemmecke.de>
Message-ID: <1125842457.10238.1.camel@localhost.localdomain>

Hi,

I'm asking if aldor will be ported to AMD 64 in a near future.
What do you think.


Cheers,

Greg




From bill.page1 at sympatico.ca  Sun Sep  4 12:03:46 2005
From: bill.page1 at sympatico.ca (bill.page1 at sympatico.ca)
Date: Sun, 4 Sep 2005 12:03:46 -0400
Subject: [Aldor-l] AMD 64 ports
In-Reply-To: <1125842457.10238.1.camel@localhost.localdomain>
Message-ID: <000201c5b16a$40df6880$6400a8c0@asus>

On September 4, 2005 10:01 AM Vanuxem Gr?gory wrote:
> 
> I'm asking if aldor will be ported to AMD 64 in a near future.
> What do you think.
> 

On August 31, 2005 10:37 AM I received the following reply from
Laurentiu Dragan [mailto:ldragan at uwo.ca] (Aldor compiler maintainer)
Re: compiling Aldor from source for x86-64 (AMD 64).

I wrote to Stephen concerning access to the source code so that
I could do the build myself but so far I have not had any response.

Regards,
Bill Page.

> 
> 
> Dear Bill Page,
> 
> The sources for the compiler are not open, only libaldor and 
> libalgebra.
> 
> Currently we don't have a 64bit version of aldor for linux.  
> If you want access to the sources you should email Stephen
> Watt at watt at aldor.org and ask him.  We'll try to build aldor
> on FC3 x86-64 to produce 64bit binaries.
> 
> Regards,
> --
> Laurentiu Dragan
> 
> Bill Page wrote:
> > Laurentiu Dragan or Cosmin Oancea,
> > 
> > I am one of the current developers of the open source version
> > of Axiom. Recently Peter Broadbery completed the re-integration
> > of Aldor as a library compiler for Axiom. (You might know that
> > Aldor used to be sold as part of the commercial version of Axiom).
> > I am building Axiom under Fedora Core 3 on x86-64 architecture.
> > Axiom works fine on this platform but the linux binary version
> > of Aldor form http://www.aldor.org fails because the compiler
> > produces 64-bit code but libfoam.a is build for 32-bits. This
> > is the error message that I get:
> > 
> > ...
> > /usr/bin/ld: skipping
> > incompatible /usr/local/aldor/linux/1.0.2/lib/libfoam.a 
> > when searching for -lfoam
> > 
> > --------
> > 
> > I would like to be able to build Aldor from sources. Would it
> > be possible for you to register me as an Aldor developer so that
> > I can access the aldor CVS?
> > 
> > Thanks in advance.
> > 
> > Regards,
> > Bill Page.
> > http://www.axiom-developer.org
> > 




From afilatei at scl.csd.uwo.ca  Mon Sep 26 22:44:03 2005
From: afilatei at scl.csd.uwo.ca (Akpodigha Filatei)
Date: Mon, 26 Sep 2005 22:44:03 -0400 (EDT)
Subject: [Aldor-l] Aldor Problem
Message-ID: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>


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


From ralf at hemmecke.de  Tue Sep 27 07:39:39 2005
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 27 Sep 2005 13:39:39 +0200
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
Message-ID: <43392F7B.7060809@hemmecke.de>

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


From afilatei at scl.csd.uwo.ca  Tue Sep 27 20:33:33 2005
From: afilatei at scl.csd.uwo.ca (Akpodigha Filatei)
Date: Tue, 27 Sep 2005 20:33:33 -0400 (EDT)
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <43392F7B.7060809@hemmecke.de>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
 <43392F7B.7060809@hemmecke.de>
Message-ID: <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>

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


From ralf at hemmecke.de  Wed Sep 28 06:32:37 2005
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Wed, 28 Sep 2005 12:32:37 +0200
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca> <43392F7B.7060809@hemmecke.de> <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>
Message-ID: <433A7145.3030404@hemmecke.de>

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()


From filatei at gmail.com  Wed Sep 28 21:28:40 2005
From: filatei at gmail.com (Akpodigha Filatei)
Date: Wed, 28 Sep 2005 21:28:40 -0400
Subject: [Aldor-l] Aldor Problem
In-Reply-To: <433A7145.3030404@hemmecke.de>
References: <Pine.LNX.4.63.0509262239520.26592@ptibonum.scl.csd.uwo.ca>
	 <43392F7B.7060809@hemmecke.de>
	 <Pine.LNX.4.63.0509272017180.18510@ptibonum.scl.csd.uwo.ca>
	 <433A7145.3030404@hemmecke.de>
Message-ID: <d95dd910509281828624b3d33@mail.gmail.com>

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>

