Franz,

On Wed, Oct 21, 2009 at 9:59 AM,  you wrote:
> On Sat, Oct 17, 2009 at 09:57:43AM +0100, Bertfried Fauser wrote:
>> Bases of symmetric function Hopf algebras:
> At the moment we concentrate on
> PowerSum, Elementary, Complete, Schur symmetric functions.
> This is always the same algebra with different basis.
>
> All these bases are indexed by Partition,
> therefore I suggest the following model
> (of course more general bases will need other implementations).
> For SymmetricFunctions We need products
> inner, outer ...: (%,%)->%
>
> and coproducts:
> coinner, coouter ...: % -> TensorPower(2,...,%)
>

I worry about the situation in which we must write something like:

  outerProduct: (%:TensorPower(n,...),%:TensorPower(m,...)) ->
TensorPower(n+m, ... )

I think this will cause some difficulty. If this can be solved by a
recursive definition something like below, I think that would be quite
beautiful.

> All these products are defined on the basis and then linearly extended,
> the latter code is always the same. Therefore I propose
>
> SymmetricFunction(R:CommutativeRing,B:SymmetricFunctionBasisCategory)
>   with
>   inner, outer:(%,%)->%
>   coinner,couter:%->TensorPower(2,...,%)
>   add
>     inner(x,y) = bilinearExtend(inner$B,x,y)
>
> SymmetricFunctionBasisCategory == with
>    inner:(%,%) -> SymmetricFunction(Integer,%)
>    ...
>
> then all there is to do is to implement the different bases,
> the linear extensions are always the same.
> The above code however is recursive:
> SymmetricFunction uses SymmetricFunctionBasisCategory
> and SymmstricFunctionBasisCategory uses SymmetricFunction.
>
> Apparently the spad compiler accepts this.
> ...

Yes, this is a very important feature of spad!

>
> However I suspect problems when the file is split.
> How can this be solved?
>

Compiling together is preferred. Then the compiler can automatically
solve the recursion.  If you must split the code, the usual approach
is to use a kind of iterative bootstrap: Define one of the categories
twice, first a dummy one without the recursion, then the one that
depends on it, finally re-define the first one.

Regards,
Bill Page.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to 
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to