From ralf at hemmecke.de  Tue Feb  6 16:21:51 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 06 Feb 2007 22:21:51 +0100
Subject: [Aldor-l] Is this warning serious?
Message-ID: <45C8F16F.6060103@hemmecke.de>

Hello,

could someone tell me about the seriousness of the message that I get 
with the following code.

I must admit that I don't see something recursive at all here.
That I have "Rep == SetSpecies L" should actually be not an issue sinde 
I don't inherit anything from SetSpecies. So what is the compiler 
complaining about?

Thank you in advance.

Ralf

CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
add {
     Rep == SetSpecies L;
     import from Rep;
     nn: I == machine n;
     cycleIndexSeries: CycleIndexSeries == {
	term(coefficient(cycleIndexSeries$SetSpecies(L), nn), nn);
     }
     ...
}

"csspecies.as", line 401: cycleIndexSeries: CycleIndexSeries == {
                           ^
[L401 C1] #8 (Warning) Illegal recursive definition: 
<cycleIndexSeries:CycleIndexSeries, cycleIndexSeries:CycleIndexSeries>




From martin.rubey at univie.ac.at  Sat Feb 10 03:47:11 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 10 Feb 2007 09:47:11 +0100
Subject: [Aldor-l] Partitions
In-Reply-To: <9qtzxuyjhv.fsf@aquin.mat.univie.ac.at>
References: <45C90A6E.6090401@risc.uni-linz.ac.at>
	<9qps8jrqen.fsf@aquin.mat.univie.ac.at>
	<9qtzxuyjhv.fsf@aquin.mat.univie.ac.at>
Message-ID: <9q1wkywga8.fsf@aquin.mat.univie.ac.at>

Dear aldor experts,

I'm forwarding this since there is at least one compiler message which looks
very strange:

#3 (Fatal Error) Storage allocation error (atempt to free unknown space).

Is this a known compiler bug?

Furthermore, how come

#8 (Fatal Error) Looking for `bracket' with code `44492043' in `^G^A^B^A'. 
Export of `^G^A^B^A' not found.

is produced with -q2 and -q3 but not with weaker optimization settings?

Dear Ralf,

I give up. The results of the test below depend on which version you use!  It
seems that if you first access the first generating series g1, then both g1 and
g2 contain the right coefficients, no matter how you generate the series.
Also, if you don't multiply the series with q=1/k everything is OK.

The sum is never working.

This bug is reproducible with debug and ordinary at -q1

Looks like an interesting :-( bug. I hope it is not yet another compiler bug...

There are more problems, by the way:

-------------------------------------------------------------------------------
-- compiling with debug at -q0:

/home/martin/aldor/linux/1.0.3/bin/aldor -Y
/home/martin/combinat2/trunk/combinat/src -Y . -Y
/home/martin/aldor/linux/1.0.3/lib -I
/home/martin/combinat2/trunk/combinat/include -I
/home/martin/aldor/linux/1.0.3/include -lcombinatd                   -dDEBUG
-q0 -lalgebrad -laldord -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
csseries.as
#3 (Fatal Error) Storage allocation error (atempt to free unknown space).
-------------------------------------------------------------------------------
-- compiling with ordinary at -q0:

segfault when starting testsuite
-------------------------------------------------------------------------------
-- compiling with debug or ordinary at -q2 or -q3:

Compiling csspecies.as ...
/home/martin/aldor/linux/1.0.3/bin/aldor -Y
/home/martin/combinat2/trunk/combinat/src -Y . -Y
/home/martin/aldor/linux/1.0.3/lib -I
/home/martin/combinat2/trunk/combinat/include -I
/home/martin/aldor/linux/1.0.3/include -lcombinatd                   -dDEBUG
-q2 -lalgebrad -laldord -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
csspecies.as
#8 (Fatal Error) Looking for `bracket' with code `44492043' in `^G^A^B^A'. 
Export of `^G^A^B^A' not found.
-------------------------------------------------------------------------------

Martin

<<test CharacteristicSpecies>>=
testCharacteristicSpecies4(): () == 
BugWorkaround(CycleIndexSeries has with {sum: Generator % -> %}) {
        setS: CycleIndexSeries := cycleIndexSeries$SetSpecies(Integer);
        set1s: DataStream P := stream generator(setS::DataStream P);
        set1s.0 := 0;
        set1: CycleIndexSeries := set1s::CycleIndexSeries;
        
        set2s: DataStream P := stretch(set1, 2)::DataStream(P);
        set2s := map((p: P): P +-> inv(2)*p)(set2s);
        set2: CycleIndexSeries := set2s::CycleIndexSeries;
        
        assertEquals(Array P, 
            [0, x(1), inv(2)*x(1,2)+inv(2)*x(2),
                inv(6)*x(1,3)+inv(2)*x(1)*x(2)+inv(3)*x(3)],
            [coefficient(set1, n) for n: MachineInteger in 0..3]);
        
        assertEquals(Array P, 
            [0, 0, inv(2)*x(2),0, inv(4)*x(2,2)+inv(4)*x(4)],
            [coefficient(set2, n) for n: MachineInteger in 0..4]);
        
        g: Generator CycleIndexSeries := generate {
                for k: I in 1..2 repeat {
                        q: Q := inv(k::Z);
#if V1
                        d: DataStream(P) := stretch(set1, k)::DataStream(P);
                        s: DataStream(P) := map((p: P): P +-> q*p)(d);
#else
                        d: CycleIndexSeries := stretch(set1, k);
                        s: DataStream(P) := stream(q*m for m in coefficients d);
#endif
                        yield s::CycleIndexSeries;
                }
        }
        
        g1 := next! g;
#if OK        
        assertEquals(Array P, 
            [coefficient(g1, n) for n: MachineInteger in 0..3],        
            [coefficient(set1, n) for n: MachineInteger in 0..3]);        
#endif        
        g2 := next! g;        
        
        assertEquals(Array P, 
            [coefficient(g2, n) for n: MachineInteger in 0..3],
            [coefficient(set2, n) for n: MachineInteger in 0..3]);                
        
        assertEquals(Array P, 
            [coefficient(g1, n) for n: MachineInteger in 0..3],        
            [coefficient(set1, n) for n: MachineInteger in 0..3]);        
        
--        set12 := sum(generate {yield set1; yield set2; });
--        g12 := sum g;        
--        
--        assertEquals(Array P, 
--            [coefficient(set12, n) for n: MachineInteger in 0..3],
--            [coefficient(g12, n) for n: MachineInteger in 0..3]);         
        
}
@
%TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT



From ralf at hemmecke.de  Thu Feb 15 07:14:10 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 15 Feb 2007 13:14:10 +0100
Subject: [Aldor-l] empty Generator?
Message-ID: <45D44E92.2060106@hemmecke.de>

Unfortunately, nobody from the Aldor developers has answered my question.

http://www.aldor.org/pipermail/aldor-l/2007-February/000583.html

Does that mean there are no Aldor developers??? :-(

In the hope there is still somebody listening...

Given g: Generator(Integer). Is it possible to check whether g is empty, 
i.e. whether it will generate *no* element? However, I don't want such a 
function

   empty?: Generator Integer -> Boolean

to modify g. So

g: Generator Integer := generate yield 123;
b: Boolean empty? g;
l: List Integer := [g];

should give

b=false and l=[123].

Ralf


From wn at cs.bath.ac.uk  Thu Feb 15 07:34:11 2007
From: wn at cs.bath.ac.uk (W Naylor)
Date: Thu, 15 Feb 2007 12:34:11 +0000 (GMT)
Subject: [Aldor-l] empty Generator?
In-Reply-To: <45D44E92.2060106@hemmecke.de>
References: <45D44E92.2060106@hemmecke.de>
Message-ID: <Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>


Hi Ralf,

unfortunatly I'm a bit out of context to answer your Feb 6th question :-(
However for your grnerator one, the algebra library exports a partialNext!
function which allows to detect if g is empty:

%14 >> g: Generator Integer := generate yield 123;
  () @ Generator(AldorInteger)
                                           Comp: 0 msec, Interp: 610 msec
%15 >> stdout<<partialNext! g
[F 123]  () @ TextWriter
                                           Comp: 0 msec, Interp: 200 msec
%16 >> stdout<<partialNext! g
[T]  () @ TextWriter
                                           Comp: 10 msec, Interp: 10 msec
%17 >> stdout<<partialNext! g
[T]  () @ TextWriter

all the best,

Bill

On Thu, 15 Feb 2007, Ralf Hemmecke wrote:

> Unfortunately, nobody from the Aldor developers has answered my question.
> 
> http://www.aldor.org/pipermail/aldor-l/2007-February/000583.html
> 
> Does that mean there are no Aldor developers??? :-(
> 
> In the hope there is still somebody listening...
> 
> Given g: Generator(Integer). Is it possible to check whether g is empty, 
> i.e. whether it will generate *no* element? However, I don't want such a 
> function
> 
>    empty?: Generator Integer -> Boolean
> 
> to modify g. So
> 
> g: Generator Integer := generate yield 123;
> b: Boolean empty? g;
> l: List Integer := [g];
> 
> should give
> 
> b=false and l=[123].
> 
> Ralf
> _______________________________________________
> Aldor-l mailing list
> Aldor-l at aldor.org
> http://www.aldor.org/mailman/listinfo/aldor-l
> 
> 
> 


From ralf at hemmecke.de  Thu Feb 15 07:57:38 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 15 Feb 2007 13:57:38 +0100
Subject: [Aldor-l] empty Generator?
In-Reply-To: <Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
References: <45D44E92.2060106@hemmecke.de>
	<Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
Message-ID: <45D458C2.2090100@hemmecke.de>

> However for your grnerator one, the algebra library exports a partialNext!
> function which allows to detect if g is empty:

Thank you for your quick answer, but I should have mentioned that I know 
about "next!" and "partialNext!".

But it does not help to make the following work. If I implement

empty?(g: Generator(Integer)): Boolean == failed? partialNext! g;

then

>> g: Generator Integer := generate yield 123;
>> b: Boolean empty? g;
>> l: List Integer := [g];

would give l=[] instead of l=[123].

So either there is a way supported by the compiler or it simply is not 
possible.

Of course I could define MyGenerator which is like a 
one-token-look-ahead stream, but then MyGenerator is different from 
Generator and it cannot be used in library functions that require Generator.

So my question was in fact, whether Generator is implemented as a 
one-token-look-ahead stream similar to TextReader. (Note that TextReader 
has a function "push!: (Charcater, %) -> ()" to push back one character.)

Ralf


From wn at cs.bath.ac.uk  Thu Feb 15 08:27:16 2007
From: wn at cs.bath.ac.uk (W Naylor)
Date: Thu, 15 Feb 2007 13:27:16 +0000 (GMT)
Subject: [Aldor-l] empty Generator?
In-Reply-To: <45D458C2.2090100@hemmecke.de>
References: <45D44E92.2060106@hemmecke.de>
	<Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
	<45D458C2.2090100@hemmecke.de>
Message-ID: <Pine.LNX.4.61.0702151321330.5763@charlie.cs.bath.ac.uk>


So I guess the problem is that when one tries to look at the Generator, to 
see if it's got anything in it this has to be a desctructive look. Looking 
at the source I see:

        next!(g:%):T == {
                for x in (g pretend Generator T) repeat return x;
                throw GeneratorException;
        }

The only way I can imagine a work around would be do the partialNext! as 
below, then rebuild the original generator (perhaps using the Generator:
        concat: List(%) -> %
function)

a bit dirty I know! but might be some help?

cheers,

Bill

On Thu, 15 Feb 2007, Ralf Hemmecke wrote:

> > However for your grnerator one, the algebra library exports a
> > partialNext!
> > function which allows to detect if g is empty:
> 
> Thank you for your quick answer, but I should have mentioned that I know about
> "next!" and "partialNext!".
> 
> But it does not help to make the following work. If I implement
> 
> empty?(g: Generator(Integer)): Boolean == failed? partialNext! g;
> 
> then
> 
> > > g: Generator Integer := generate yield 123;
> > > b: Boolean empty? g;
> > > l: List Integer := [g];
> 
> would give l=[] instead of l=[123].
> 
> So either there is a way supported by the compiler or it simply is not
> possible.
> 
> Of course I could define MyGenerator which is like a one-token-look-ahead
> stream, but then MyGenerator is different from Generator and it cannot be used
> in library functions that require Generator.
> 
> So my question was in fact, whether Generator is implemented as a
> one-token-look-ahead stream similar to TextReader. (Note that TextReader has a
> function "push!: (Charcater, %) -> ()" to push back one character.)
> 
> Ralf
> 
> 
> 
> 


From ralf at hemmecke.de  Thu Feb 15 08:46:46 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 15 Feb 2007 14:46:46 +0100
Subject: [Aldor-l] empty Generator?
In-Reply-To: <Pine.LNX.4.61.0702151321330.5763@charlie.cs.bath.ac.uk>
References: <45D44E92.2060106@hemmecke.de>
	<Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
	<45D458C2.2090100@hemmecke.de>
	<Pine.LNX.4.61.0702151321330.5763@charlie.cs.bath.ac.uk>
Message-ID: <45D46446.603@hemmecke.de>

> The only way I can imagine a work around would be do the partialNext! as 
> below, then rebuild the original generator (perhaps using the Generator:
>         concat: List(%) -> %
> function)
> 
> a bit dirty I know! but might be some help?

Well if I just want to implement "empty?(g)" (since there is no such 
function) using partialNext! then I would have to step the generator g. 
That is a destructive operation on g. Then I would have to rebuild the 
old g somehow without modifying the memory address of g (since there 
might be other places where g is used). Generator just doesn't have that 
functionality (not that I know of) to do such a destructive rebuild of 
the orginal g, i.e. to do a push back.

I do not desparately want "empty?" to exist, but perhaps it is already 
there an the compiler/library just doesn't give access to it. I simply 
don't know. But I thought that perhaps someone with more knowledge of 
the compiler could tell me.

Ralf



From martin.rubey at univie.ac.at  Fri Feb 16 16:58:16 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 16 Feb 2007 22:58:16 +0100
Subject: [Aldor-l] Special casing...
In-Reply-To: <9qodntsrwc.fsf@aquin.mat.univie.ac.at>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net> <45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net> <45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net> <45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net> <45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net> <45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at> <45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
Message-ID: <9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>

Dear Christian, Dear Gaby,

do you think that something like (i.e., achieving the same or a similar effect
as) the following is possible in Aldor (or in improved SPAD):

I'd like the compiler to allow something like

---------------------------------------------------------------------------
f(a: S): T == { generic implementation }

f(specialValueOfTypeS): T == { special implementation for specialValueOfTypeS }
f(otherSpecialValueOfTypeS): T == { special imp. for otherSpecialValueOfTypeS }

g(c: T, d: T): T == { ... f(c) ... f(d) ...}
---------------------------------------------------------------------------

So, if c happens to be specialValueOfTypeS, then the special implementation is
used, and so on.

As criterion for equality, identical memory location would be sufficient for
me. Of course, f should be allowed to be type-valued.

In the axiom interpreter, the above is allowed for ordinary functions, i.e.,
functions that return an element of a domain.

For example, one can define

f: Integer -> Integer
f 0 == 1
f 1 == 1
f n == f(n-1) + f(n-2)

I guess it is possible to define

f(a: S): T == { 
    if a = specialValueOfTypeS then 
        { special implementation for specialValueOfTypeS }
    else if a = otherSpecialValueOfTypeS then 
        { special imp. for otherSpecialValueOfTypeS }
    else { generic implementation }
}

but this would not really be very extensible...

Martin



From gdr at cs.tamu.edu  Fri Feb 16 18:19:02 2007
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: 16 Feb 2007 17:19:02 -0600
Subject: [Aldor-l] Special casing...
In-Reply-To: <9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net> <45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net> <45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net> <45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net> <45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net> <45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at> <45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
	<9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
Message-ID: <87vei14ro9.fsf@soliton.cs.tamu.edu>

Martin Rubey <martin.rubey at univie.ac.at> writes:

| Dear Christian, Dear Gaby,
| 
| do you think that something like (i.e., achieving the same or a similar effect
| as) the following is possible in Aldor (or in improved SPAD):
| 
| I'd like the compiler to allow something like
| 
| ---------------------------------------------------------------------------
| f(a: S): T == { generic implementation }
| 
| f(specialValueOfTypeS): T == { special implementation for specialValueOfTypeS }
| f(otherSpecialValueOfTypeS): T == { special imp. for otherSpecialValueOfTypeS }
| 
| g(c: T, d: T): T == { ... f(c) ... f(d) ...}
| ---------------------------------------------------------------------------
| 
| So, if c happens to be specialValueOfTypeS, then the special implementation is
| used, and so on.

I believe the Axiom interpreter and compiler internal representation
is prepared to handle something like that.  However, I don't know
whether the algorithms for type ckecing and all that are prepared to
do so.

-- Gaby


From tmgisi at gmx.at  Tue Feb 20 06:32:43 2007
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 20 Feb 2007 12:32:43 +0100
Subject: [Aldor-l] Special casing...
In-Reply-To: <9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net>
	<45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net>
	<45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net>
	<45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net>
	<45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net>
	<45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at>
	<45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
	<9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
Message-ID: <op.tn1o0ta9u6j4vy@spencer.aistleitner.info>

Hello,

> do you think that something like (i.e., achieving the same or a similar  
> effect as) the following is possible in Aldor (or in improved SPAD):
>
> I'd like the compiler to allow something like
>
> ---------------------------------------------------------------------------
> f(a: S): T == { generic implementation }
>
> f(specialValueOfTypeS): T == { special implementation for  
> specialValueOfTypeS }
> f(otherSpecialValueOfTypeS): T == { special imp. for  
> otherSpecialValueOfTypeS }
>
> g(c: T, d: T): T == { ... f(c) ... f(d) ...}
> ---------------------------------------------------------------------------
>
> So, if c happens to be specialValueOfTypeS, then the special  
> implementation is
> used, and so on.

without further machinery, I'll doubt that this is possible. And I  
strongly disadvise you to use such a design.
You are mixing different programming paradigms here. But I am sure you  
thought about this problem and the arising confusion and problems.

If your domain S provides equality checks (PrimitiveType for Aldor), you  
can get something not too far from what you wanted to have while still  
being extensible. For example by using dictionaries (the value of s being  
the key and the various special implementations of f the values). Hiding  
the use of dictionaries within macros should give you the possibility to  
cancel them out and eliminate the overhead, if Aldor chooses to allow  
this  type of programming.
Whether such a design is really applicable depends on how badly you need  
extensibility.

Kind regards,
Christian



From martin.rubey at univie.ac.at  Tue Feb 20 08:55:12 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Feb 2007 14:55:12 +0100
Subject: [Aldor-l] Special casing...
In-Reply-To: <op.tn1o0ta9u6j4vy@spencer.aistleitner.info>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net> <45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net> <45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net> <45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net> <45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net> <45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at> <45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
	<9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
	<op.tn1o0ta9u6j4vy@spencer.aistleitner.info>
Message-ID: <9qsld1lyrj.fsf@aquin.mat.univie.ac.at>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

> Hello,
> 
> > do you think that something like (i.e., achieving the same or a similar
> > effect as) the following is possible in Aldor (or in improved SPAD):
> >
> > I'd like the compiler to allow something like
> >
> > ---------------------------------------------------------------------------
> > f(a: S): T == { generic implementation }
> >
> > f(specialValueOfTypeS): T == { special implementation for
> > specialValueOfTypeS }
> > f(otherSpecialValueOfTypeS): T == { special imp. for
> > otherSpecialValueOfTypeS }
> >
> > g(c: T, d: T): T == { ... f(c) ... f(d) ...}
> > ---------------------------------------------------------------------------
> >
> > So, if c happens to be specialValueOfTypeS, then the special  implementation
> > is
> > used, and so on.
> 
> without further machinery, I'll doubt that this is possible. And I  strongly
> disadvise you to use such a design.

Yes, I think you are right. If a new SPAD or Aldor would support this, it would
imply quite an overhead, since it would only make sense if one could "extend" f
after having it compiled into a library...

Very likely, it is better to implement a (domain valued) function that could be
used roughly as follows:

SpecialCasesForFDictionary: List Record(a: S, t: T) 

f(a: S): T == lookupSpecialCases(a, { generic implementation })

 
Martin



From martin.rubey at univie.ac.at  Thu Feb 22 14:30:01 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 22 Feb 2007 20:30:01 +0100
Subject: [Aldor-l] [ANN] Axiom Workshop 2007
Message-ID: <9qk5yahtxi.fsf@kratt3.mat.univie.ac.at>

Dear all,

We are happy to announce the

                                     _
                                    (_)
                           __ ___  ___  ___  _ __ ___
                          / _` \ \/ / |/ _ \| '_ ` _ \
                         | (_| |>  <| | (_) | | | | | |
                          \__,_/_/\_\_|\___/|_| |_| |_|
                                     _
                                    (_)

          __          ______  _____  _  __ _____ _    _  ____  _____
          \ \        / / __ \|  __ \| |/ // ____| |  | |/ __ \|  __ \
           \ \  /\  / / |  | | |__) | ' /| (___ | |__| | |  | | |__) |
            \ \/  \/ /| |  | |  _  /|  <  \___ \|  __  | |  | |  ___/
             \  /\  / | |__| | | \ \| . \ ____) | |  | | |__| | |
              \/  \/   \____/|_|  \_\_|\_\_____/|_|  |_|\____/|_|

                             ___   ___   ___ ______ 
                            |__ \ / _ \ / _ \____  |
                               ) | | | | | | |  / / 
                              / /| | | | | | | / /  
                             / /_| |_| | |_| |/ /   
                            |____|\___/ \___//_/    
                            

                             Symmetric Functions



It will take place at the RISC institute near Linz from Thursday, June 14 to
Saturday, June 16.

----------------------------------------------------------------------------

Axiom is a Computer Algebra System with a long tradition.  It recently became
free software, see http://www.axiom-developer.org

The workshop aims at a cooperation of Axiom developers with developers of
packages written for other Computer Algebra Systems, and mathematicians that
would like to use a computer algebra system to perform experiments.

One goal of the workshop is to learn about the mathematical theory, the design
of packages written for other CAS and to make those functionalities available
in Axiom.

If you would like to attend the workshop, please send mail to
<axiomize at yahoo.de>.  There will be time for a very limited number of
contributed talks.  If you would like to give a talk, please send us title and
a short abstract as soon as possible.

There will be no conference fee, but it is expected that participants pay
accommodation and meals themselves.  There is a limited number of rooms
available in Hagenberg for approximately 28 EUR/night including breakfast.

----------------------------------------------------------------------------

The following talks are planned:


Fran?ois Descouens and Nicolas Thi?ry 

         Symmetric functions and Hopf algebras

         Usage and design in MuPAD-Combinat

Bertfried Fauser

         Calculations in character Hopf algebras using SCHUR and Maple

Harald Fripertinger        

         TBA

Axel Kohnert 

         Symmetric functions in MAGMA

----------------------------------------------------------------------------

Organisers: Ralf Hemmecke
            Martin Rubey


Email: axiomize at yahoo.de




From ralf at hemmecke.de  Mon Feb 26 12:25:41 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Mon, 26 Feb 2007 18:25:41 +0100
Subject: [Aldor-l] local vs. non-local
Message-ID: <45E31815.7020205@hemmecke.de>

Up to now I thought the "local" keyword just keeps something local. But 
now I stumpled over the following program which does only compile if I 
remove the "local" in front of new although both "new" functions come 
from different domains.

Perhaps I could understand that the compiler complains about two "new" 
functions inside DomB where one of them is local and the other is not. 
But even then it would be strange to think that there is a good reason 
why the compiler should forbid something like

baz(i: Integer): % == ...
local baz(): % == ...

because the two functions have different types.
Does there anybody know what happens here? Is this a compiler bug?

If this is not a compiler bug then the documentation in Chapter 8.13. of 
  the AUG should more clearly state that the type in a "local" 
declaration is irrelevant.

Ralf

---------------------------------------------------------
 >aldor aaa.as
"aaa.as", line 13:         local foo: DomA == new() $ DomA;
                    ...........................^
[L13 C28] #2 (Note 1)  (cf. L14 C15)

"aaa.as", line 14:         local new(x: Integer): % == per x;
                    ..............^
[L14 C15] #1 (Error) It is illegal to declare an identifier free or 
local once it has already been used, defined or assigned.
(see Note 1)

---BEGIN aaa.as
#include "aldor"

DomA: with {
	new: () -> %
} == add {
	Rep == Record(abc: Integer);
	import from Rep;
	new(): % == per [0];
}

DomB: with == add {
	Rep == Integer;
	local foo: DomA == new() $ DomA;
	local new(x: Integer): % == per x;
}
---END aaa.as


From tmgisi at gmx.at  Tue Feb 27 03:14:56 2007
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 27 Feb 2007 09:14:56 +0100
Subject: [Aldor-l] local vs. non-local
In-Reply-To: <45E31815.7020205@hemmecke.de>
References: <45E31815.7020205@hemmecke.de>
Message-ID: <op.toeei6n0u6j4vy@spencer.aistleitner.info>

Hello,

your point was that the following piece of code

> ---BEGIN aaa.as
> #include "aldor"
>
> DomA: with {
> 	new: () -> %
> } == add {
> 	Rep == Record(abc: Integer);
> 	import from Rep;
> 	new(): % == per [0];
> }
>
> DomB: with == add {
> 	Rep == Integer;
> 	local foo: DomA == new() $ DomA;
> 	local new(x: Integer): % == per x;
> }
> ---END aaa.as

does not work, because of the "local" modifier in DomB's "local new" line.

On Mon, 26 Feb 2007 18:25:41 +0100, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> Perhaps I could understand that the compiler complains about two "new"
> functions inside DomB where one of them is local and the other is not.

If you meant something like
   local funcA():() ==
   funcA():() ==
then it would be obviously wrong, as you'd redefine the constant funcA of  
type () -> (). If statement referred to constants with different types,  
read on ;)

> But even then it would be strange to think that there is a good reason
> why the compiler should forbid something like
>
> baz(i: Integer): % == ...
> local baz(): % == ...
>
> because the two functions have different types.

Aldor (the language--according to the AUG) allows to overload constants  
bearing the same name but different type. The modifier local does not  
forbid this:

#include "aldor"

Dom: with == add {
         local new(x: Integer): () == {};
         new(x: Integer, y: Integer): () == {};
}

This style of code can also be found in the Aldor library (compare
   sort!(l:%, less:(T, T) -> Boolean):%    == ...
   local sort!(l:%, n:Z, less:(T, T) -> Boolean):% == ...
of List). Therefore, I assume it is strongly supported by Aldor.

> Does there anybody know what happens here? Is this a compiler bug?

I do not know. Looks like the new()$DomA is messing up the DomB's "add"  
scope, by introducing the symbol "new". However, it should not.
Switching the two local lines of DomB makes the code work. (Thereby, the  
line "local new" introduces the symbol "new".)
To underpin this, one can convert foo into a function (hence the right  
hand side of foo's == gets its own scope). This solves the problem as well.

Kind regards,
Christian



From ralf at hemmecke.de  Tue Feb  6 16:21:51 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Tue, 06 Feb 2007 22:21:51 +0100
Subject: [Aldor-l] Is this warning serious?
Message-ID: <45C8F16F.6060103@hemmecke.de>

Hello,

could someone tell me about the seriousness of the message that I get 
with the following code.

I must admit that I don't see something recursive at all here.
That I have "Rep == SetSpecies L" should actually be not an issue sinde 
I don't inherit anything from SetSpecies. So what is the compiler 
complaining about?

Thank you in advance.

Ralf

CharacteristicSpecies(n:Integer)(L:LabelType): CombinatorialSpecies L == 
add {
     Rep == SetSpecies L;
     import from Rep;
     nn: I == machine n;
     cycleIndexSeries: CycleIndexSeries == {
	term(coefficient(cycleIndexSeries$SetSpecies(L), nn), nn);
     }
     ...
}

"csspecies.as", line 401: cycleIndexSeries: CycleIndexSeries == {
                           ^
[L401 C1] #8 (Warning) Illegal recursive definition: 
<cycleIndexSeries:CycleIndexSeries, cycleIndexSeries:CycleIndexSeries>




From martin.rubey at univie.ac.at  Sat Feb 10 03:47:11 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 10 Feb 2007 09:47:11 +0100
Subject: [Aldor-l] Partitions
In-Reply-To: <9qtzxuyjhv.fsf@aquin.mat.univie.ac.at>
References: <45C90A6E.6090401@risc.uni-linz.ac.at>
	<9qps8jrqen.fsf@aquin.mat.univie.ac.at>
	<9qtzxuyjhv.fsf@aquin.mat.univie.ac.at>
Message-ID: <9q1wkywga8.fsf@aquin.mat.univie.ac.at>

Dear aldor experts,

I'm forwarding this since there is at least one compiler message which looks
very strange:

#3 (Fatal Error) Storage allocation error (atempt to free unknown space).

Is this a known compiler bug?

Furthermore, how come

#8 (Fatal Error) Looking for `bracket' with code `44492043' in `^G^A^B^A'. 
Export of `^G^A^B^A' not found.

is produced with -q2 and -q3 but not with weaker optimization settings?

Dear Ralf,

I give up. The results of the test below depend on which version you use!  It
seems that if you first access the first generating series g1, then both g1 and
g2 contain the right coefficients, no matter how you generate the series.
Also, if you don't multiply the series with q=1/k everything is OK.

The sum is never working.

This bug is reproducible with debug and ordinary at -q1

Looks like an interesting :-( bug. I hope it is not yet another compiler bug...

There are more problems, by the way:

-------------------------------------------------------------------------------
-- compiling with debug at -q0:

/home/martin/aldor/linux/1.0.3/bin/aldor -Y
/home/martin/combinat2/trunk/combinat/src -Y . -Y
/home/martin/aldor/linux/1.0.3/lib -I
/home/martin/combinat2/trunk/combinat/include -I
/home/martin/aldor/linux/1.0.3/include -lcombinatd                   -dDEBUG
-q0 -lalgebrad -laldord -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
csseries.as
#3 (Fatal Error) Storage allocation error (atempt to free unknown space).
-------------------------------------------------------------------------------
-- compiling with ordinary at -q0:

segfault when starting testsuite
-------------------------------------------------------------------------------
-- compiling with debug or ordinary at -q2 or -q3:

Compiling csspecies.as ...
/home/martin/aldor/linux/1.0.3/bin/aldor -Y
/home/martin/combinat2/trunk/combinat/src -Y . -Y
/home/martin/aldor/linux/1.0.3/lib -I
/home/martin/combinat2/trunk/combinat/include -I
/home/martin/aldor/linux/1.0.3/include -lcombinatd                   -dDEBUG
-q2 -lalgebrad -laldord -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
csspecies.as
#8 (Fatal Error) Looking for `bracket' with code `44492043' in `^G^A^B^A'. 
Export of `^G^A^B^A' not found.
-------------------------------------------------------------------------------

Martin

<<test CharacteristicSpecies>>=
testCharacteristicSpecies4(): () == 
BugWorkaround(CycleIndexSeries has with {sum: Generator % -> %}) {
        setS: CycleIndexSeries := cycleIndexSeries$SetSpecies(Integer);
        set1s: DataStream P := stream generator(setS::DataStream P);
        set1s.0 := 0;
        set1: CycleIndexSeries := set1s::CycleIndexSeries;
        
        set2s: DataStream P := stretch(set1, 2)::DataStream(P);
        set2s := map((p: P): P +-> inv(2)*p)(set2s);
        set2: CycleIndexSeries := set2s::CycleIndexSeries;
        
        assertEquals(Array P, 
            [0, x(1), inv(2)*x(1,2)+inv(2)*x(2),
                inv(6)*x(1,3)+inv(2)*x(1)*x(2)+inv(3)*x(3)],
            [coefficient(set1, n) for n: MachineInteger in 0..3]);
        
        assertEquals(Array P, 
            [0, 0, inv(2)*x(2),0, inv(4)*x(2,2)+inv(4)*x(4)],
            [coefficient(set2, n) for n: MachineInteger in 0..4]);
        
        g: Generator CycleIndexSeries := generate {
                for k: I in 1..2 repeat {
                        q: Q := inv(k::Z);
#if V1
                        d: DataStream(P) := stretch(set1, k)::DataStream(P);
                        s: DataStream(P) := map((p: P): P +-> q*p)(d);
#else
                        d: CycleIndexSeries := stretch(set1, k);
                        s: DataStream(P) := stream(q*m for m in coefficients d);
#endif
                        yield s::CycleIndexSeries;
                }
        }
        
        g1 := next! g;
#if OK        
        assertEquals(Array P, 
            [coefficient(g1, n) for n: MachineInteger in 0..3],        
            [coefficient(set1, n) for n: MachineInteger in 0..3]);        
#endif        
        g2 := next! g;        
        
        assertEquals(Array P, 
            [coefficient(g2, n) for n: MachineInteger in 0..3],
            [coefficient(set2, n) for n: MachineInteger in 0..3]);                
        
        assertEquals(Array P, 
            [coefficient(g1, n) for n: MachineInteger in 0..3],        
            [coefficient(set1, n) for n: MachineInteger in 0..3]);        
        
--        set12 := sum(generate {yield set1; yield set2; });
--        g12 := sum g;        
--        
--        assertEquals(Array P, 
--            [coefficient(set12, n) for n: MachineInteger in 0..3],
--            [coefficient(g12, n) for n: MachineInteger in 0..3]);         
        
}
@
%TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT



From ralf at hemmecke.de  Thu Feb 15 07:14:10 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 15 Feb 2007 13:14:10 +0100
Subject: [Aldor-l] empty Generator?
Message-ID: <45D44E92.2060106@hemmecke.de>

Unfortunately, nobody from the Aldor developers has answered my question.

http://www.aldor.org/pipermail/aldor-l/2007-February/000583.html

Does that mean there are no Aldor developers??? :-(

In the hope there is still somebody listening...

Given g: Generator(Integer). Is it possible to check whether g is empty, 
i.e. whether it will generate *no* element? However, I don't want such a 
function

   empty?: Generator Integer -> Boolean

to modify g. So

g: Generator Integer := generate yield 123;
b: Boolean empty? g;
l: List Integer := [g];

should give

b=false and l=[123].

Ralf


From wn at cs.bath.ac.uk  Thu Feb 15 07:34:11 2007
From: wn at cs.bath.ac.uk (W Naylor)
Date: Thu, 15 Feb 2007 12:34:11 +0000 (GMT)
Subject: [Aldor-l] empty Generator?
In-Reply-To: <45D44E92.2060106@hemmecke.de>
References: <45D44E92.2060106@hemmecke.de>
Message-ID: <Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>


Hi Ralf,

unfortunatly I'm a bit out of context to answer your Feb 6th question :-(
However for your grnerator one, the algebra library exports a partialNext!
function which allows to detect if g is empty:

%14 >> g: Generator Integer := generate yield 123;
  () @ Generator(AldorInteger)
                                           Comp: 0 msec, Interp: 610 msec
%15 >> stdout<<partialNext! g
[F 123]  () @ TextWriter
                                           Comp: 0 msec, Interp: 200 msec
%16 >> stdout<<partialNext! g
[T]  () @ TextWriter
                                           Comp: 10 msec, Interp: 10 msec
%17 >> stdout<<partialNext! g
[T]  () @ TextWriter

all the best,

Bill

On Thu, 15 Feb 2007, Ralf Hemmecke wrote:

> Unfortunately, nobody from the Aldor developers has answered my question.
> 
> http://www.aldor.org/pipermail/aldor-l/2007-February/000583.html
> 
> Does that mean there are no Aldor developers??? :-(
> 
> In the hope there is still somebody listening...
> 
> Given g: Generator(Integer). Is it possible to check whether g is empty, 
> i.e. whether it will generate *no* element? However, I don't want such a 
> function
> 
>    empty?: Generator Integer -> Boolean
> 
> to modify g. So
> 
> g: Generator Integer := generate yield 123;
> b: Boolean empty? g;
> l: List Integer := [g];
> 
> should give
> 
> b=false and l=[123].
> 
> Ralf
> _______________________________________________
> Aldor-l mailing list
> Aldor-l at aldor.org
> http://www.aldor.org/mailman/listinfo/aldor-l
> 
> 
> 


From ralf at hemmecke.de  Thu Feb 15 07:57:38 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 15 Feb 2007 13:57:38 +0100
Subject: [Aldor-l] empty Generator?
In-Reply-To: <Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
References: <45D44E92.2060106@hemmecke.de>
	<Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
Message-ID: <45D458C2.2090100@hemmecke.de>

> However for your grnerator one, the algebra library exports a partialNext!
> function which allows to detect if g is empty:

Thank you for your quick answer, but I should have mentioned that I know 
about "next!" and "partialNext!".

But it does not help to make the following work. If I implement

empty?(g: Generator(Integer)): Boolean == failed? partialNext! g;

then

>> g: Generator Integer := generate yield 123;
>> b: Boolean empty? g;
>> l: List Integer := [g];

would give l=[] instead of l=[123].

So either there is a way supported by the compiler or it simply is not 
possible.

Of course I could define MyGenerator which is like a 
one-token-look-ahead stream, but then MyGenerator is different from 
Generator and it cannot be used in library functions that require Generator.

So my question was in fact, whether Generator is implemented as a 
one-token-look-ahead stream similar to TextReader. (Note that TextReader 
has a function "push!: (Charcater, %) -> ()" to push back one character.)

Ralf


From wn at cs.bath.ac.uk  Thu Feb 15 08:27:16 2007
From: wn at cs.bath.ac.uk (W Naylor)
Date: Thu, 15 Feb 2007 13:27:16 +0000 (GMT)
Subject: [Aldor-l] empty Generator?
In-Reply-To: <45D458C2.2090100@hemmecke.de>
References: <45D44E92.2060106@hemmecke.de>
	<Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
	<45D458C2.2090100@hemmecke.de>
Message-ID: <Pine.LNX.4.61.0702151321330.5763@charlie.cs.bath.ac.uk>


So I guess the problem is that when one tries to look at the Generator, to 
see if it's got anything in it this has to be a desctructive look. Looking 
at the source I see:

        next!(g:%):T == {
                for x in (g pretend Generator T) repeat return x;
                throw GeneratorException;
        }

The only way I can imagine a work around would be do the partialNext! as 
below, then rebuild the original generator (perhaps using the Generator:
        concat: List(%) -> %
function)

a bit dirty I know! but might be some help?

cheers,

Bill

On Thu, 15 Feb 2007, Ralf Hemmecke wrote:

> > However for your grnerator one, the algebra library exports a
> > partialNext!
> > function which allows to detect if g is empty:
> 
> Thank you for your quick answer, but I should have mentioned that I know about
> "next!" and "partialNext!".
> 
> But it does not help to make the following work. If I implement
> 
> empty?(g: Generator(Integer)): Boolean == failed? partialNext! g;
> 
> then
> 
> > > g: Generator Integer := generate yield 123;
> > > b: Boolean empty? g;
> > > l: List Integer := [g];
> 
> would give l=[] instead of l=[123].
> 
> So either there is a way supported by the compiler or it simply is not
> possible.
> 
> Of course I could define MyGenerator which is like a one-token-look-ahead
> stream, but then MyGenerator is different from Generator and it cannot be used
> in library functions that require Generator.
> 
> So my question was in fact, whether Generator is implemented as a
> one-token-look-ahead stream similar to TextReader. (Note that TextReader has a
> function "push!: (Charcater, %) -> ()" to push back one character.)
> 
> Ralf
> 
> 
> 
> 


From ralf at hemmecke.de  Thu Feb 15 08:46:46 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Thu, 15 Feb 2007 14:46:46 +0100
Subject: [Aldor-l] empty Generator?
In-Reply-To: <Pine.LNX.4.61.0702151321330.5763@charlie.cs.bath.ac.uk>
References: <45D44E92.2060106@hemmecke.de>
	<Pine.LNX.4.61.0702151230310.5763@charlie.cs.bath.ac.uk>
	<45D458C2.2090100@hemmecke.de>
	<Pine.LNX.4.61.0702151321330.5763@charlie.cs.bath.ac.uk>
Message-ID: <45D46446.603@hemmecke.de>

> The only way I can imagine a work around would be do the partialNext! as 
> below, then rebuild the original generator (perhaps using the Generator:
>         concat: List(%) -> %
> function)
> 
> a bit dirty I know! but might be some help?

Well if I just want to implement "empty?(g)" (since there is no such 
function) using partialNext! then I would have to step the generator g. 
That is a destructive operation on g. Then I would have to rebuild the 
old g somehow without modifying the memory address of g (since there 
might be other places where g is used). Generator just doesn't have that 
functionality (not that I know of) to do such a destructive rebuild of 
the orginal g, i.e. to do a push back.

I do not desparately want "empty?" to exist, but perhaps it is already 
there an the compiler/library just doesn't give access to it. I simply 
don't know. But I thought that perhaps someone with more knowledge of 
the compiler could tell me.

Ralf



From martin.rubey at univie.ac.at  Fri Feb 16 16:58:16 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 16 Feb 2007 22:58:16 +0100
Subject: [Aldor-l] Special casing...
In-Reply-To: <9qodntsrwc.fsf@aquin.mat.univie.ac.at>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net> <45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net> <45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net> <45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net> <45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net> <45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at> <45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
Message-ID: <9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>

Dear Christian, Dear Gaby,

do you think that something like (i.e., achieving the same or a similar effect
as) the following is possible in Aldor (or in improved SPAD):

I'd like the compiler to allow something like

---------------------------------------------------------------------------
f(a: S): T == { generic implementation }

f(specialValueOfTypeS): T == { special implementation for specialValueOfTypeS }
f(otherSpecialValueOfTypeS): T == { special imp. for otherSpecialValueOfTypeS }

g(c: T, d: T): T == { ... f(c) ... f(d) ...}
---------------------------------------------------------------------------

So, if c happens to be specialValueOfTypeS, then the special implementation is
used, and so on.

As criterion for equality, identical memory location would be sufficient for
me. Of course, f should be allowed to be type-valued.

In the axiom interpreter, the above is allowed for ordinary functions, i.e.,
functions that return an element of a domain.

For example, one can define

f: Integer -> Integer
f 0 == 1
f 1 == 1
f n == f(n-1) + f(n-2)

I guess it is possible to define

f(a: S): T == { 
    if a = specialValueOfTypeS then 
        { special implementation for specialValueOfTypeS }
    else if a = otherSpecialValueOfTypeS then 
        { special imp. for otherSpecialValueOfTypeS }
    else { generic implementation }
}

but this would not really be very extensible...

Martin



From gdr at cs.tamu.edu  Fri Feb 16 18:19:02 2007
From: gdr at cs.tamu.edu (Gabriel Dos Reis)
Date: 16 Feb 2007 17:19:02 -0600
Subject: [Aldor-l] Special casing...
In-Reply-To: <9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net> <45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net> <45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net> <45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net> <45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net> <45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at> <45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
	<9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
Message-ID: <87vei14ro9.fsf@soliton.cs.tamu.edu>

Martin Rubey <martin.rubey at univie.ac.at> writes:

| Dear Christian, Dear Gaby,
| 
| do you think that something like (i.e., achieving the same or a similar effect
| as) the following is possible in Aldor (or in improved SPAD):
| 
| I'd like the compiler to allow something like
| 
| ---------------------------------------------------------------------------
| f(a: S): T == { generic implementation }
| 
| f(specialValueOfTypeS): T == { special implementation for specialValueOfTypeS }
| f(otherSpecialValueOfTypeS): T == { special imp. for otherSpecialValueOfTypeS }
| 
| g(c: T, d: T): T == { ... f(c) ... f(d) ...}
| ---------------------------------------------------------------------------
| 
| So, if c happens to be specialValueOfTypeS, then the special implementation is
| used, and so on.

I believe the Axiom interpreter and compiler internal representation
is prepared to handle something like that.  However, I don't know
whether the algorithms for type ckecing and all that are prepared to
do so.

-- Gaby


From tmgisi at gmx.at  Tue Feb 20 06:32:43 2007
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 20 Feb 2007 12:32:43 +0100
Subject: [Aldor-l] Special casing...
In-Reply-To: <9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net>
	<45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net>
	<45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net>
	<45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net>
	<45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net>
	<45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at>
	<45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
	<9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
Message-ID: <op.tn1o0ta9u6j4vy@spencer.aistleitner.info>

Hello,

> do you think that something like (i.e., achieving the same or a similar  
> effect as) the following is possible in Aldor (or in improved SPAD):
>
> I'd like the compiler to allow something like
>
> ---------------------------------------------------------------------------
> f(a: S): T == { generic implementation }
>
> f(specialValueOfTypeS): T == { special implementation for  
> specialValueOfTypeS }
> f(otherSpecialValueOfTypeS): T == { special imp. for  
> otherSpecialValueOfTypeS }
>
> g(c: T, d: T): T == { ... f(c) ... f(d) ...}
> ---------------------------------------------------------------------------
>
> So, if c happens to be specialValueOfTypeS, then the special  
> implementation is
> used, and so on.

without further machinery, I'll doubt that this is possible. And I  
strongly disadvise you to use such a design.
You are mixing different programming paradigms here. But I am sure you  
thought about this problem and the arising confusion and problems.

If your domain S provides equality checks (PrimitiveType for Aldor), you  
can get something not too far from what you wanted to have while still  
being extensible. For example by using dictionaries (the value of s being  
the key and the various special implementations of f the values). Hiding  
the use of dictionaries within macros should give you the possibility to  
cancel them out and eliminate the overhead, if Aldor chooses to allow  
this  type of programming.
Whether such a design is really applicable depends on how badly you need  
extensibility.

Kind regards,
Christian



From martin.rubey at univie.ac.at  Tue Feb 20 08:55:12 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 20 Feb 2007 14:55:12 +0100
Subject: [Aldor-l] Special casing...
In-Reply-To: <op.tn1o0ta9u6j4vy@spencer.aistleitner.info>
References: <45D2A5AD.1090002@hemmecke.de>
	<9q8xf1xidq.fsf@aquin.mat.univie.ac.at>
	<20070214101947.GA2458@eole.rouba.net> <45D2E884.6000105@hemmecke.de>
	<20070214110128.GB2458@eole.rouba.net> <45D2F1CE.8090300@hemmecke.de>
	<20070214114533.GC2458@eole.rouba.net> <45D311BB.8010505@hemmecke.de>
	<20070216092516.GW2458@eole.rouba.net> <45D5A100.4090208@hemmecke.de>
	<20070216123543.GY2458@eole.rouba.net> <45D5A8EA.9060408@hemmecke.de>
	<9qzm7eqmpc.fsf@aquin.mat.univie.ac.at> <45D6125A.9090708@hemmecke.de>
	<9qodntsrwc.fsf@aquin.mat.univie.ac.at>
	<9qbqjtdatj.fsf_-_@aquin.mat.univie.ac.at>
	<op.tn1o0ta9u6j4vy@spencer.aistleitner.info>
Message-ID: <9qsld1lyrj.fsf@aquin.mat.univie.ac.at>

"Christian Aistleitner" <tmgisi at gmx.at> writes:

> Hello,
> 
> > do you think that something like (i.e., achieving the same or a similar
> > effect as) the following is possible in Aldor (or in improved SPAD):
> >
> > I'd like the compiler to allow something like
> >
> > ---------------------------------------------------------------------------
> > f(a: S): T == { generic implementation }
> >
> > f(specialValueOfTypeS): T == { special implementation for
> > specialValueOfTypeS }
> > f(otherSpecialValueOfTypeS): T == { special imp. for
> > otherSpecialValueOfTypeS }
> >
> > g(c: T, d: T): T == { ... f(c) ... f(d) ...}
> > ---------------------------------------------------------------------------
> >
> > So, if c happens to be specialValueOfTypeS, then the special  implementation
> > is
> > used, and so on.
> 
> without further machinery, I'll doubt that this is possible. And I  strongly
> disadvise you to use such a design.

Yes, I think you are right. If a new SPAD or Aldor would support this, it would
imply quite an overhead, since it would only make sense if one could "extend" f
after having it compiled into a library...

Very likely, it is better to implement a (domain valued) function that could be
used roughly as follows:

SpecialCasesForFDictionary: List Record(a: S, t: T) 

f(a: S): T == lookupSpecialCases(a, { generic implementation })

 
Martin



From martin.rubey at univie.ac.at  Thu Feb 22 14:30:01 2007
From: martin.rubey at univie.ac.at (Martin Rubey)
Date: 22 Feb 2007 20:30:01 +0100
Subject: [Aldor-l] [ANN] Axiom Workshop 2007
Message-ID: <9qk5yahtxi.fsf@kratt3.mat.univie.ac.at>

Dear all,

We are happy to announce the

                                     _
                                    (_)
                           __ ___  ___  ___  _ __ ___
                          / _` \ \/ / |/ _ \| '_ ` _ \
                         | (_| |>  <| | (_) | | | | | |
                          \__,_/_/\_\_|\___/|_| |_| |_|
                                     _
                                    (_)

          __          ______  _____  _  __ _____ _    _  ____  _____
          \ \        / / __ \|  __ \| |/ // ____| |  | |/ __ \|  __ \
           \ \  /\  / / |  | | |__) | ' /| (___ | |__| | |  | | |__) |
            \ \/  \/ /| |  | |  _  /|  <  \___ \|  __  | |  | |  ___/
             \  /\  / | |__| | | \ \| . \ ____) | |  | | |__| | |
              \/  \/   \____/|_|  \_\_|\_\_____/|_|  |_|\____/|_|

                             ___   ___   ___ ______ 
                            |__ \ / _ \ / _ \____  |
                               ) | | | | | | |  / / 
                              / /| | | | | | | / /  
                             / /_| |_| | |_| |/ /   
                            |____|\___/ \___//_/    
                            

                             Symmetric Functions



It will take place at the RISC institute near Linz from Thursday, June 14 to
Saturday, June 16.

----------------------------------------------------------------------------

Axiom is a Computer Algebra System with a long tradition.  It recently became
free software, see http://www.axiom-developer.org

The workshop aims at a cooperation of Axiom developers with developers of
packages written for other Computer Algebra Systems, and mathematicians that
would like to use a computer algebra system to perform experiments.

One goal of the workshop is to learn about the mathematical theory, the design
of packages written for other CAS and to make those functionalities available
in Axiom.

If you would like to attend the workshop, please send mail to
<axiomize at yahoo.de>.  There will be time for a very limited number of
contributed talks.  If you would like to give a talk, please send us title and
a short abstract as soon as possible.

There will be no conference fee, but it is expected that participants pay
accommodation and meals themselves.  There is a limited number of rooms
available in Hagenberg for approximately 28 EUR/night including breakfast.

----------------------------------------------------------------------------

The following talks are planned:


Fran?ois Descouens and Nicolas Thi?ry 

         Symmetric functions and Hopf algebras

         Usage and design in MuPAD-Combinat

Bertfried Fauser

         Calculations in character Hopf algebras using SCHUR and Maple

Harald Fripertinger        

         TBA

Axel Kohnert 

         Symmetric functions in MAGMA

----------------------------------------------------------------------------

Organisers: Ralf Hemmecke
            Martin Rubey


Email: axiomize at yahoo.de




From ralf at hemmecke.de  Mon Feb 26 12:25:41 2007
From: ralf at hemmecke.de (Ralf Hemmecke)
Date: Mon, 26 Feb 2007 18:25:41 +0100
Subject: [Aldor-l] local vs. non-local
Message-ID: <45E31815.7020205@hemmecke.de>

Up to now I thought the "local" keyword just keeps something local. But 
now I stumpled over the following program which does only compile if I 
remove the "local" in front of new although both "new" functions come 
from different domains.

Perhaps I could understand that the compiler complains about two "new" 
functions inside DomB where one of them is local and the other is not. 
But even then it would be strange to think that there is a good reason 
why the compiler should forbid something like

baz(i: Integer): % == ...
local baz(): % == ...

because the two functions have different types.
Does there anybody know what happens here? Is this a compiler bug?

If this is not a compiler bug then the documentation in Chapter 8.13. of 
  the AUG should more clearly state that the type in a "local" 
declaration is irrelevant.

Ralf

---------------------------------------------------------
 >aldor aaa.as
"aaa.as", line 13:         local foo: DomA == new() $ DomA;
                    ...........................^
[L13 C28] #2 (Note 1)  (cf. L14 C15)

"aaa.as", line 14:         local new(x: Integer): % == per x;
                    ..............^
[L14 C15] #1 (Error) It is illegal to declare an identifier free or 
local once it has already been used, defined or assigned.
(see Note 1)

---BEGIN aaa.as
#include "aldor"

DomA: with {
	new: () -> %
} == add {
	Rep == Record(abc: Integer);
	import from Rep;
	new(): % == per [0];
}

DomB: with == add {
	Rep == Integer;
	local foo: DomA == new() $ DomA;
	local new(x: Integer): % == per x;
}
---END aaa.as


From tmgisi at gmx.at  Tue Feb 27 03:14:56 2007
From: tmgisi at gmx.at (Christian Aistleitner)
Date: Tue, 27 Feb 2007 09:14:56 +0100
Subject: [Aldor-l] local vs. non-local
In-Reply-To: <45E31815.7020205@hemmecke.de>
References: <45E31815.7020205@hemmecke.de>
Message-ID: <op.toeei6n0u6j4vy@spencer.aistleitner.info>

Hello,

your point was that the following piece of code

> ---BEGIN aaa.as
> #include "aldor"
>
> DomA: with {
> 	new: () -> %
> } == add {
> 	Rep == Record(abc: Integer);
> 	import from Rep;
> 	new(): % == per [0];
> }
>
> DomB: with == add {
> 	Rep == Integer;
> 	local foo: DomA == new() $ DomA;
> 	local new(x: Integer): % == per x;
> }
> ---END aaa.as

does not work, because of the "local" modifier in DomB's "local new" line.

On Mon, 26 Feb 2007 18:25:41 +0100, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> Perhaps I could understand that the compiler complains about two "new"
> functions inside DomB where one of them is local and the other is not.

If you meant something like
   local funcA():() ==
   funcA():() ==
then it would be obviously wrong, as you'd redefine the constant funcA of  
type () -> (). If statement referred to constants with different types,  
read on ;)

> But even then it would be strange to think that there is a good reason
> why the compiler should forbid something like
>
> baz(i: Integer): % == ...
> local baz(): % == ...
>
> because the two functions have different types.

Aldor (the language--according to the AUG) allows to overload constants  
bearing the same name but different type. The modifier local does not  
forbid this:

#include "aldor"

Dom: with == add {
         local new(x: Integer): () == {};
         new(x: Integer, y: Integer): () == {};
}

This style of code can also be found in the Aldor library (compare
   sort!(l:%, less:(T, T) -> Boolean):%    == ...
   local sort!(l:%, n:Z, less:(T, T) -> Boolean):% == ...
of List). Therefore, I assume it is strongly supported by Aldor.

> Does there anybody know what happens here? Is this a compiler bug?

I do not know. Looks like the new()$DomA is messing up the DomB's "add"  
scope, by introducing the symbol "new". However, it should not.
Switching the two local lines of DomB makes the code work. (Thereby, the  
line "local new" introduces the symbol "new".)
To underpin this, one can convert foo into a function (hence the right  
hand side of foo's == gets its own scope). This solves the problem as well.

Kind regards,
Christian



