Bertfried, On Sat, Oct 17, 2009 at 4:57 AM, you wrote: > > [this mail is cc-ed to fricas-devel since it may be of interest to people > trying > to use/implement Hopf algebras with fricas] >
Thank you for sharing your ideas concerning Hopf algebras in FriCAS. I am very interested in this and when I get more time I plan to reply in some detail - including some code for FreeProduct which improves upon http://axiom-wiki.newsynthesis.org/SandBoxFreeProduct > ... > Given such a variety of things, freeModule should take (as it does) > not a specific indexing class, but should just expect something like > OrderedSet, [I think we need a total order here] It may be not too > hard to envision also Hopf algebras for any poset, along the lines > of incidence Hopf algebras, but that is perhaps a different0 story. > I very much agree. If you have not already done so, I would also recommend taking a closer look at domains like MonoidRing which together with FreeGroup can be used to construct (among other things) non-commutative Laurent polynomials. > > Since Franz knows what the tensor does, I guess he can judge what to do > best. As far as I see, the grading can be done later in the actual HA at the > moment. (By implementing the 2-cocycle c(a,b)->k and switching tensor > factor with respect to this 2-cocyle) > I hope that Franz will soon commit his tensor code to the FriCAS source repository. I have captured a preliminary version of his code here: http://axiom-wiki.newsynthesis.org/SandBoxTensorProduct and as applied here: http://axiom-wiki.newsynthesis.org/SandBoxHopfAlgebra I am sure there can be many improvements but I think it would be good to make it available as part of FriCAS sooner rather than later (in true open-source development style!). > However, I would like to have a notion of a graded free module (super > module) which would allow to introduce odd generators x^2=0 (or for > finite characteristic purposes even x^(p^n)=0 for p a prime number, that > calls actually for the use of finite fields F(p^n)). Graded commutativity > is the fact that \sigma(a \otimes b) = (-1)^(|a|,|b|) b\otimes a (and hence > a special case of the above 2-cocycle [q-deformations arise from > c(a,b) = (q)^(|a|,|b|)] > > Given such a module is available, this would make it easy to define > exterior algebras on any totally ordered set as index set. The above > construction of HAs from cofree cogenerated modules would then allow > to introduce (quantum) Clifford algebras with the same code. > Yes! This would be excellent. I have spent some time on-and=off this last month playing with some code for Grassmann algebra but I was not very happy with would be be easily accomplished in FriCAS now. In particular there needs to be a better approach for graded algebras and for that I think proper coproducts are essential. Again I have some code that might be useful and will post it here or on the wiki as soon as I have more time. > I am surely not on my way to do all this, but we should keep this in mind > when designing categories and domains, not to block our [or anybody > elses <grin>] way to such venues. Agreed. > > Franz: You had a list with compiler errors, could you send this to me? > I get a compiler errors like 'bad form' and 'blah has no hash' and need > to see what error I made. > On Sat, Oct 17, 2009 at 1:05 PM, Bertfried Fauser wrote: > > Dear Ralf, > > in principle I would like to have aldor support. However, when we did some > coding (mainly Franz <grin>, but I may have got me actually started to do own > things) we decided to do it in FriCAS and with the spad compiler. > > Sencond question, no. I tried to install sage (because of the mupad combinat > port) but sage did not run on my moderately old system (SuSE 10.1) and I > have _no_ intention momentarily to update the machine. Furthemore, we noted > that the combinat code in sage is partly broken due to some old coercion > scheme > in use. That is we cannot make use of it. > > I am currently fussing arround implementing some very minor routines for > partitions and power/schur symmetric functions, but I have to fight compiler > messages I don't understand and other things..... > > So I would not put pressure on you to do anything on teh spot. If you have a > working aldor interface. I'll would like to know about it. > Bertfried, I very highly recommend using Aldor in FriCAS even if you intend ultimately to implement the same code using SPAD (for greater compatibility with Axiom). Compiler messages in Aldor are MUCH more useful than those generated by SPAD. When I first started trying to write a lot more in SPAD I found it much easier to get it right first using the Aldor interface and then just back-port the resulting code to SPAD. Although I am more used to SPAD's quirks now and have started to develop a style of coding in SPAD that almost always works, there are still times that SPAD is so frustrating that I find the Aldor strategy to be the best alternative. Besides that of course, Aldor is still technically a better language than SPAD in several ways. It remains a tragedy that those people responsible for it's licensing seem to be devoted mostly to destroying any future this language might have. :-( 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 -~----------~----~----~----~------~----~------~--~---
