MuPAD-Combinat

Hi Nicolas,

I am experimenting computations of Macdonald polynomials using =20
determinantal formulas in order to have quick computations of these =20
guys.
Which day of next week you plan to make your experimentation ?

Francois



Le 07-09-28 =E0 01:00, Nicolas M. Thiery a =E9crit :

> 	Hi Fran=E7ois,
>
> Alexander Woo is running a reading seminar here at Davis about
> Macdonald polynomials, and I suggested to make a little demo /
> tutorial next week about how to actually play with them on the
> machine.
>
> Do you think you can get the S::MacDonald(q,t) thing working?  Also,
> most of the participants will work on the same machine/network. So, I
> will use the occasion to experiment with "persistent remembering" on a
> larger scale:
>
> http://mupad-combinat.sf.net/doc/en/operators_Combinat/=20
> persistentRemember.html
>
> So that each MacDonald polynomial would be computed only once for all
> for all participants.
>
> Cheers,
> 					Nicolas
> --=20
> Nicolas M. Thi=E9ry "Isil" <nthiery@...>
> http://Nicolas.Thiery.name/
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mupad-combinat-devel mailing list
> Mupad-combinat-devel@...
> https://lists.sourceforge.net/lists/listinfo/mupad-combinat-devel

> I am experimenting computations of Macdonald polynomials using
> determinantal formulas in order to have quick computations of these
> guys.

Cool!

What were the results of your experiments using interpolation?

> Which day of next week you plan to make your experimentation ?

Next Thursday. Note that the users will mainly be newcomers to
Macdonald's which, therefore and for the moment, will be more in need
of a stable interface than pure speed.

Cheers,
					Nicolas

PS: We can discuss over the phone sometime today if you want
sip:nthiery@...

-- 
Nicolas M. Thiéry "Isil" <nthiery@...>
http://Nicolas.Thiery.name/

Hi Mike,

> I'm currently spending the semester in Madison, WI sitting in on
> Arun Ram's course on Lie algebras.

Nice!

> I wanted to let you know that I finally have an initial version of my
> combinatorics package in SAGE.  As you may have guessed, it's pretty
> heavily influenced by MuPAD-Combinat so it shouldn't be terribly
> uncomfortable for you to use ;)

Cool :-)

> One of the main differences is that specific combinatorial classes (
> such as partitions of 5 ) are represented by Python objects.  Their
> class (in the object-oriented sense of class) is a subclass of
> CombinatorialClass.

This sounds very good. I am glad that you are making such progress!

Note: we are also going in a similar direction:

>> l := combinat::partitions::subClass(5):
>> l::list()

  [[5], [4, 1], [3, 2], [3, 1, 1], [2, 2, 1], [2, 1, 1, 1], [1, 1, 1, 1, 1]]


Just a question: for combinatorial classes whose elements are really
typed (I don't remember whether your partitions are): what syntax do
you use for the constructor? In MuPAD-Combinat, class(...) is the
constructor, and class::subClass() gives access to the sub classes:


>> combinat::tableaux([[3],[1,2]])

                                  +---+
                                  | 3 |
                                  +---+---+
                                  | 1 | 2 |
                                  +---+---+
                                                                 Time: 11 msec
>> combinat::tableaux::subClass(3)

                       combinat::tableaux::subClass(3)
                                                                  Time: 2 msec
>> (combinat::tableaux::subClass(3))::list()

               --                                      +---+ --
               |                                       | 3 |  |
               |                 +---+      +---+      +---+  |
               |                 | 3 |      | 2 |      | 2 |  |
               |  +---+---+---+  +---+---+  +---+---+  +---+  |
               |  | 1 | 2 | 3 |, | 1 | 2 |, | 1 | 3 |, | 1 |  |
               -- +---+---+---+  +---+---+  +---+---+  +---+ --

> I also have a very initial version of CombinatorialAlgebra.

Cool.

> class SymmetricGroupAlgebra_n(CombinatorialAlgebra):
>     def __init__(self, R, n):
>         self.n = n
>         self._combinatorial_class = permutation.Permutations(n)

I suggest you go in the direction of what we call "indexed
combinatorial classes" (or if you prefer generalized associative
container) to represent the basis. Mathematically, one usually denotes
the basis of a vector space (or a set of algebra generators for an
algebra, ...) by a family (s_i)_{i \in I}, where I is any
combinatorial class. You want to be able to model such a family by a
single object which is itself a combinatorial class and allows for
indexed access s[i].

> sage: QS3 = SymmetricGroupAlgebra(QQ, 3)

Note: we take the convention to pass QQ as second (last) parameter;
this allows for making it optional.

> There's definitely a lot left that I want to do such as
> Hall-Littlewood and Macdonald polynomials

François: can you send Mike (a pointer to) your latest tutorial?

> and combinatorial species.  I've started looking at Ralf and
> Martin's species stuff this weekend and was able to get their (lazy,
> recursion supporting) power series working in SAGE.

Good. Have a look to combinat::countingFunctions as well.

> If you're interested, I could make a page on the SAGE Wiki
> describing the relationship between my SAGE code and MuPAD-Combinat.

Yes, please! And if needed, please update the link at the bottom of

	http://mupad-combinat.sourceforge.net/Wiki/HomePage

> Hope you're enjoying UC-Davis!

I definitely am :-)

Best regards,
					Nicolas
-- 
Nicolas M. Thiéry "Isil" <nthiery@...>
http://Nicolas.Thiery.name/

Hello,

> Just a question: for combinatorial classes whose elements are really
> typed (I don't remember whether your partitions are): what syntax do
> you use for the constructor? In MuPAD-Combinat, class(...) is the
> constructor, and class::subClass() gives access to the sub classes:
>

There are a few ways to do it.  In general, a plural name represents a
combinatorial class while a singular name is for objects of that
combinatorial class.  If you have a combinatorial class C and you want
to get the typed version of c (which is in C), then you can do C(c)
since combinatorial classes know about their object class.

sage: p =3D Partition([2,1])
sage: p.hook_lengths()
[[3, 1], [1]]
sage: P =3D Partitions()
sage: P([2,1]).hook_lengths()
[[3, 1], [1]]
sage: P =3D Partitions(5)
sage: P =3D Partitions(3)
sage: P([2,1]).hook_lengths()
[[3, 1], [1]]
sage: P([2,2])  #gives an error

For all the combinatorial classes, there is a wrapper function (e.g.
Partitions) that returns the correct combinatorial class for the
arguments that you pass it.  That way, all the type checking is done
at the beginning and you don't need to worry about it in your
implementations of list, count, etc.  On the other hand, this means
there are a lot more Python classes that you have to create.  For
example,

sage: p =3D Permutations(3); type(p)
<class 'sage.combinat.permutation.StandardPermutations_n'>
sage: p =3D Permutations([1,1,2]); type(p)
<class 'sage.combinat.permutation.Permutations_mset'>
sage: p =3D Permutations([1,1,2],2); type(p)
<class 'sage.combinat.permutation.Permutations_msetk'>
sage: p =3D Permutations(4, avoiding=3D[1,3,2]); type(p)
<class 'sage.combinat.permutation.StandardPermutations_avoiding_132'>
sage: p =3D Permutations(5, avoiding=3D[[3,4,1,2],[4,2,3,1]]); type(p)
<class 'sage.combinat.permutation.StandardPermutations_avoiding_generic'>

Many of the other things in SAGE are handled in this sort of manner.

>
> > class SymmetricGroupAlgebra_n(CombinatorialAlgebra):
> >     def __init__(self, R, n):
> >         self.n =3D n
> >         self._combinatorial_class =3D permutation.Permutations(n)
>
> I suggest you go in the direction of what we call "indexed
> combinatorial classes" (or if you prefer generalized associative
> container) to represent the basis. Mathematically, one usually denotes
> the basis of a vector space (or a set of algebra generators for an
> algebra, ...) by a family (s_i)_{i \in I}, where I is any
> combinatorial class. You want to be able to model such a family by a
> single object which is itself a combinatorial class and allows for
> indexed access s[i].
>

Combinatorial classes in SAGE allow indexed access by default.

sage: st =3D StandardTableaux(3)
sage: st[0]
[[1, 2, 3]]
sage: st[2]
[[1, 2], [3]]

> > sage: QS3 =3D SymmetricGroupAlgebra(QQ, 3)
>
> Note: we take the convention to pass QQ as second (last) parameter;
> this allows for making it optional.

In SAGE, almost all base rings are passed explicitly.

sage: P.<x,y,z> =3D PolynomialRing(QQ, 3)
sage: P.<x,y,z> =3D PolynomialRing(SR, 3); P
Polynomial Ring in x, y, z over Symbolic Ring

Generic symbolic expressions have so far gotten a second-class role in
SAGE (except in the calculus section).  Part of this is because we
rely on Maxima at the moment to handle symbolic expressions so they're
a bit inefficient.  This may change in the upcoming future as SymPy
gets a bit more mature.


> > There's definitely a lot left that I want to do such as
> > Hall-Littlewood and Macdonald polynomials
>
> Fran=E7ois: can you send Mike (a pointer to) your latest tutorial?

That'd be great!

> > If you're interested, I could make a page on the SAGE Wiki
> > describing the relationship between my SAGE code and MuPAD-Combinat.
>
> Yes, please! And if needed, please update the link at the bottom of
>
>         http://mupad-combinat.sourceforge.net/Wiki/HomePage
>

I'll probably do that some time this weekend.


Have you given any thought to caching results for when classes use the
default algorithms? I haven't decided the best approach to this.


Also, there is a MuPAD interface in SAGE, but it could use a little
polishing (for example tab-completion, changing Python's '.' into
MuPAD's '::', etc).
sage: mupad('combinat::partitions::list(3)')
                            [[3], [2, 1], [1, 1, 1]]
But, in the notebook interface for SAGE, then you can set the
evaluation mode to mupad and you can interact with MuPAD directly.

Finally, in the upcoming months, I think there will be a fair amount
of work done with resepect to Coxeter groups, Weyl groups, root
systems, etc. in SAGE.  I'm going to put together an SEP for this
(SAGE Enhancement Proposal, based on Python's PEP, see
http://wiki.sagemath.org/CalculusSEP ).  I'm going to be surveying the
current software packages for working with these objects to see what
functionality we need / want.  I know the MuPAD-Combinat team has been
doing some work in this area.  Is there something on the wiki (or
elsewhere) that outlines how these objects will be organized and
structured in MuPAD-Combinat?

--Mike

> There are a few ways to do it.  In general, a plural name represents a
> combinatorial class while a singular name is for objects of that
> combinatorial class.  If you have a combinatorial class C and you want
> to get the typed version of c (which is in C), then you can do C(c)
> since combinatorial classes know about their object class.

Ah ok, that sounds very good to me. I just wonder whether users would
not get confused by two names which differ by just a s (I probably
would not, but could do some mistyping).

> Many of the other things in SAGE are handled in this sort of manner.

Ok, good.

> Combinatorial classes in SAGE allow indexed access by default.

I have seen this. But here to model a family (s_i)_{i\in I}, you want
indexing by elements of I, which is orthogonal to unranking.

For example, for QS3, I would want to write something like.

b := QS3::basis:
b[ [1,3,2] ]:

> In SAGE, almost all base rings are passed explicitly.

Ok. Follow the Sage convention then.

> Generic symbolic expressions have so far gotten a second-class role
> in SAGE (except in the calculus section).  Part of this is because
> we rely on Maxima at the moment to handle symbolic expressions so
> they're a bit inefficient.  This may change in the upcoming future
> as SymPy gets a bit more mature.

Ok. Symbolic expressions are highly practical yet highly lousy stuff
anyway.

> Have you given any thought to caching results for when classes use the
> default algorithms? I haven't decided the best approach to this.

We took the path not to introduce too much magic, and to leave full
control to the class writer. If (s)he just wants to implement list,
then he is free to decide whether to put an option remember on it or
not.

> Also, there is a MuPAD interface in SAGE, but it could use a little
> polishing (for example tab-completion, changing Python's '.' into
> MuPAD's '::', etc).

Ok.

> Finally, in the upcoming months, I think there will be a fair amount
> of work done with resepect to Coxeter groups, Weyl groups, root
> systems, etc. in SAGE.  I'm going to put together an SEP for this
> (SAGE Enhancement Proposal, based on Python's PEP, see
> http://wiki.sagemath.org/CalculusSEP ).  I'm going to be surveying the
> current software packages for working with these objects to see what
> functionality we need / want.  I know the MuPAD-Combinat team has been
> doing some work in this area.  Is there something on the wiki (or
> elsewhere) that outlines how these objects will be organized and
> structured in MuPAD-Combinat?

Most of the basics have been implemented now, see:

http://mupad-combinat.sourceforge.net/Wiki/RootSystems

For example, counting the elements in E_8 starting from just its
cartan matrix takes about 20s on my machine, which is not completely
ridiculous.

The documentation is yet to be written, but if you tell me you want to
look at in in more detail, that will whip me to work on it sooner.
IMHO, so far the design feels rather good.

Cheers,
					Nicolas
-- 
Nicolas M. Thiéry "Isil" <nthiery@...>
http://Nicolas.Thiery.name/

> Ah ok, that sounds very good to me. I just wonder whether users would
> not get confused by two names which differ by just a s (I probably
> would not, but could do some mistyping).

I'll have to see how it plays out.


> I have seen this. But here to model a family (s_i)_{i\in I}, you want
> indexing by elements of I, which is orthogonal to unranking.
>
> For example, for QS3, I would want to write something like.
>
> b := QS3::basis:
> b[ [1,3,2] ]:

I see -- I had misunderstood your original comment.  In SAGE, the
natural thing do to get that basis element is to "coerce" [1,3,2] into
QS3.

sage: 2*QS3([1,3,2])
2*[1, 3, 2]
sage: QS3(5/6)
5/6*[1, 2, 3]


> We took the path not to introduce too much magic, and to leave full
> control to the class writer. If (s)he just wants to implement list,
> then he is free to decide whether to put an option remember on it or
> not.

That seems like a reasonable decision.

> Most of the basics have been implemented now, see:
>
> http://mupad-combinat.sourceforge.net/Wiki/RootSystems
>
> For example, counting the elements in E_8 starting from just its
> cartan matrix takes about 20s on my machine, which is not completely
> ridiculous.
>
> The documentation is yet to be written, but if you tell me you want to
> look at in in more detail, that will whip me to work on it sooner.
> IMHO, so far the design feels rather good.

Excellent -- I'll take a look at it.

--Mike

> I see -- I had misunderstood your original comment.  In SAGE, the
> natural thing do to get that basis element is to "coerce" [1,3,2] into
> QS3.
> 
> sage: 2*QS3([1,3,2])
> 2*[1, 3, 2]
> sage: QS3(5/6)
> 5/6*[1, 2, 3]

Which we actually also do. But we also want to deal in a uniform way
with basis and with algebra/group/operad/module/... generators)?  In
the following example, the vector space and algebra generators of the
group algebra of the affine Weyl group are both modeled by a single gadget:

>> A41 := Dom::WeylGroup(["A",4,1]): A41::Name := hold(A41):
>> S := Dom::GroupAlgebra(A41):
>> s := S::basis:
>> s::keys
                                     A41
>> s::count()
                                   infinity
>> s[A41::one]

                            / +-               -+ \
                            | |  1, 0, 0, 0, 0  | |
                            | |                 | |
                            | |  0, 1, 0, 0, 0  | |
                            | |                 | |
                           B| |  0, 0, 1, 0, 0  | |
                            | |                 | |
                            | |  0, 0, 0, 1, 0  | |
                            | |                 | |
                            | |  0, 0, 0, 0, 1  | |
                            \ +-               -+ /

>> s := S::algebraGenerators:
>> s::keys
                               [0, 1, 2, 3, 4]
>> s::count()
                                      5
>> s[0]

                           / +-                -+ \
                           | |  -1, 1, 0, 0, 1  | |
                           | |                  | |
                           | |   0, 1, 0, 0, 0  | |
                           | |                  | |
                          B| |   0, 0, 1, 0, 0  | |
                           | |                  | |
                           | |   0, 0, 0, 1, 0  | |
                           | |                  | |
                           | |   0, 0, 0, 0, 1  | |
                           \ +-                -+ /
>> s::list()

--  / +-                -+ \   / +-                -+ \
|   | |  -1, 1, 0, 0, 1  | |   | |  1,  0, 0, 0, 0  | |
|   | |                  | |   | |                  | |
|   | |   0, 1, 0, 0, 0  | |   | |  1, -1, 1, 0, 0  | |
|   | |                  | |   | |                  | |
|  B| |   0, 0, 1, 0, 0  | |, B| |  0,  0, 1, 0, 0  | |,
|   | |                  | |   | |                  | |
|   | |   0, 0, 0, 1, 0  | |   | |  0,  0, 0, 1, 0  | |
|   | |                  | |   | |                  | |
|   | |   0, 0, 0, 0, 1  | |   | |  0,  0, 0, 0, 1  | |
--  \ +-                -+ /   \ +-                -+ /
 ...

And one could not really achieve that with just overloading coerce.

Cheers,
					Nicolas
-- 
Nicolas M. Thiéry "Isil" <nthiery@...>
http://Nicolas.Thiery.name/

Hi Mike,

Good to heard about you again.

I have just added my small tutorial on symmetric functions in the =20
directory Papers of MuPAD-Combinat.
You can also look at the code which is splitted inside the files =20
contained in the directory SymmetricFunctionsTools. But the code is =20
still in developpement and major change are made regularly.

Best,

Francois

>>> There's definitely a lot left that I want to do such as
>>> Hall-Littlewood and Macdonald polynomials
>>
>> Fran=E7ois: can you send Mike (a pointer to) your latest tutorial?
>
> That'd be great!
>
>>> If you're interested, I could make a page on the SAGE Wiki
>>> describing the relationship between my SAGE code and MuPAD-Combinat.
>>
>> Yes, please! And if needed, please update the link at the bottom of
>>
>>         http://mupad-combinat.sourceforge.net/Wiki/HomePage
>>
>
> I'll probably do that some time this weekend.
>
>
> Have you given any thought to caching results for when classes use the
> default algorithms? I haven't decided the best approach to this.
>
>
> Also, there is a MuPAD interface in SAGE, but it could use a little
> polishing (for example tab-completion, changing Python's '.' into
> MuPAD's '::', etc).
> sage: mupad('combinat::partitions::list(3)')
>                             [[3], [2, 1], [1, 1, 1]]
> But, in the notebook interface for SAGE, then you can set the
> evaluation mode to mupad and you can interact with MuPAD directly.
>
> Finally, in the upcoming months, I think there will be a fair amount
> of work done with resepect to Coxeter groups, Weyl groups, root
> systems, etc. in SAGE.  I'm going to put together an SEP for this
> (SAGE Enhancement Proposal, based on Python's PEP, see
> http://wiki.sagemath.org/CalculusSEP ).  I'm going to be surveying the
> current software packages for working with these objects to see what
> functionality we need / want.  I know the MuPAD-Combinat team has been
> doing some work in this area.  Is there something on the wiki (or
> elsewhere) that outlines how these objects will be organized and
> structured in MuPAD-Combinat?
>
> --Mike
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mupad-combinat-devel mailing list
> Mupad-combinat-devel@...
> https://lists.sourceforge.net/lists/listinfo/mupad-combinat-devel

Greetings Francois,

Thanks for that.  It'll give me some things to play with.  By the way,
on the example S::s(S::HallLittlewood::Qp[2,1,1]), the exponent on
s[4] should be t^3 and not t.  The code gives the correct result -- it
looks like it just got miscopied into the PDF.

--Mike

On 9/27/07, Francois Descouens <francois.descouens@...> wrote:
> Hi Mike,
>
> Good to heard about you again.
>
> I have just added my small tutorial on symmetric functions in the
> directory Papers of MuPAD-Combinat.
> You can also look at the code which is splitted inside the files
> contained in the directory SymmetricFunctionsTools. But the code is
> still in developpement and major change are made regularly.
>
> Best,
>
> Francois
>
> >>> There's definitely a lot left that I want to do such as
> >>> Hall-Littlewood and Macdonald polynomials
> >>
> >> Fran=E7ois: can you send Mike (a pointer to) your latest tutorial?
> >
> > That'd be great!
> >
> >>> If you're interested, I could make a page on the SAGE Wiki
> >>> describing the relationship between my SAGE code and MuPAD-Combinat.
> >>
> >> Yes, please! And if needed, please update the link at the bottom of
> >>
> >>         http://mupad-combinat.sourceforge.net/Wiki/HomePage
> >>
> >
> > I'll probably do that some time this weekend.
> >
> >
> > Have you given any thought to caching results for when classes use the
> > default algorithms? I haven't decided the best approach to this.
> >
> >
> > Also, there is a MuPAD interface in SAGE, but it could use a little
> > polishing (for example tab-completion, changing Python's '.' into
> > MuPAD's '::', etc).
> > sage: mupad('combinat::partitions::list(3)')
> >                             [[3], [2, 1], [1, 1, 1]]
> > But, in the notebook interface for SAGE, then you can set the
> > evaluation mode to mupad and you can interact with MuPAD directly.
> >
> > Finally, in the upcoming months, I think there will be a fair amount
> > of work done with resepect to Coxeter groups, Weyl groups, root
> > systems, etc. in SAGE.  I'm going to put together an SEP for this
> > (SAGE Enhancement Proposal, based on Python's PEP, see
> > http://wiki.sagemath.org/CalculusSEP ).  I'm going to be surveying the
> > current software packages for working with these objects to see what
> > functionality we need / want.  I know the MuPAD-Combinat team has been
> > doing some work in this area.  Is there something on the wiki (or
> > elsewhere) that outlines how these objects will be organized and
> > structured in MuPAD-Combinat?
> >
> > --Mike
> >
> > ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Mupad-combinat-devel mailing list
> > Mupad-combinat-devel@...
> > https://lists.sourceforge.net/lists/listinfo/mupad-combinat-devel
>
>

Hi Mike,

Yes, there are some typos which have to be corrected in this tutorial.

Thanks,
Francois


Le 07-09-28 =E0 03:57, Mike Hansen a =E9crit :

> Greetings Francois,
>
> Thanks for that.  It'll give me some things to play with.  By the way,
> on the example S::s(S::HallLittlewood::Qp[2,1,1]), the exponent on
> s[4] should be t^3 and not t.  The code gives the correct result -- it
> looks like it just got miscopied into the PDF.
>
> --Mike
>
> On 9/27/07, Francois Descouens <francois.descouens@...> wrote:
>> Hi Mike,
>>
>> Good to heard about you again.
>>
>> I have just added my small tutorial on symmetric functions in the
>> directory Papers of MuPAD-Combinat.
>> You can also look at the code which is splitted inside the files
>> contained in the directory SymmetricFunctionsTools. But the code is
>> still in developpement and major change are made regularly.
>>
>> Best,
>>
>> Francois
>>
>>>>> There's definitely a lot left that I want to do such as
>>>>> Hall-Littlewood and Macdonald polynomials
>>>>
>>>> Fran=E7ois: can you send Mike (a pointer to) your latest tutorial?
>>>
>>> That'd be great!
>>>
>>>>> If you're interested, I could make a page on the SAGE Wiki
>>>>> describing the relationship between my SAGE code and MuPAD-=20
>>>>> Combinat.
>>>>
>>>> Yes, please! And if needed, please update the link at the bottom of
>>>>
>>>>         http://mupad-combinat.sourceforge.net/Wiki/HomePage
>>>>
>>>
>>> I'll probably do that some time this weekend.
>>>
>>>
>>> Have you given any thought to caching results for when classes =20
>>> use the
>>> default algorithms? I haven't decided the best approach to this.
>>>
>>>
>>> Also, there is a MuPAD interface in SAGE, but it could use a little
>>> polishing (for example tab-completion, changing Python's '.' into
>>> MuPAD's '::', etc).
>>> sage: mupad('combinat::partitions::list(3)')
>>>                             [[3], [2, 1], [1, 1, 1]]
>>> But, in the notebook interface for SAGE, then you can set the
>>> evaluation mode to mupad and you can interact with MuPAD directly.
>>>
>>> Finally, in the upcoming months, I think there will be a fair amount
>>> of work done with resepect to Coxeter groups, Weyl groups, root
>>> systems, etc. in SAGE.  I'm going to put together an SEP for this
>>> (SAGE Enhancement Proposal, based on Python's PEP, see
>>> http://wiki.sagemath.org/CalculusSEP ).  I'm going to be =20
>>> surveying the
>>> current software packages for working with these objects to see what
>>> functionality we need / want.  I know the MuPAD-Combinat team has =20=

>>> been
>>> doing some work in this area.  Is there something on the wiki (or
>>> elsewhere) that outlines how these objects will be organized and
>>> structured in MuPAD-Combinat?
>>>
>>> --Mike
>>>
>>> --------------------------------------------------------------------=20=

>>> --
>>> ---
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Mupad-combinat-devel mailing list
>>> Mupad-combinat-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/mupad-combinat-devel
>>
>>

Hallo Martin,

Thank you for your answer. This solution worked.

Vielen Dank!

Anne

Martin Knelleken wrote:
> Dear Nicolas,
> 
> Sorry for the delayed answer. I didn't noticed the report in
> the bug tracker. :-(
> 
>> Could you give me a quick update on http://www.mupad.de/trac/ticket/2236?
> 
> I think (and hope) the answer is easy. Use MuPAD Pro 4.0.2.
> 
> MuPAD 4.0.0 was a build for PPC Macs only and you are compiling
> Intel code. This does not work.
> 
> MuPAD 4.0.2 is an universal binary and so both the kernel executable
> and your module will be compatible.
> 
> Another possibility would be to compile the module with the
> '-arch ppc' option but I expect problems in this case, because
> MuPAD 4.0.0 was compiled with gcc 3.3 and AFAIR there was a few
> incompatibilities to gcc 4.x in the libc.
> 
> I hope this helps
> 
> 
> Kind regards
> 
> Martin

Dear Teresa,

> Nicolas has added a new toGraph function in 
> DOMAINS/CATEGORY/CombinatorialModule.mu, and I am trying
> to make it working for some of the examples in the test file,

Thanks for investigating this!

> And what I don't understand (maybe there is a good reason) is why I
> can't have two edges between two vertices with different
> weights/costs/descriptions:

It's just that the current internal data structure of Graph does not
support multiple edges from a to b, even with different weights and
costs:

>> G := Graph([a,b,c],[[a,b],[b,c]], EdgeWeights=[1,2],Directed):
>> extop(G)

                                                              table(
                                         table(                 c = [b],
[a, b, c], [[a, b], [b, c]], FAIL, FAIL,   [b, c] = 2,, FAIL,   b = [a],,
                                           [a, b] = 1           a = []
                                         )                    )

   table(
     c = [],
     b = [c],, TRUE
     a = [b]
   )

That's definitely a technical burden, but there is no reason why it
could not be changed. In particular, we certainly want to have
different data structures for graphs in the long term, all belonging
to a common Graph category.

> Nicolas, this is why I think that to generate dot files
> it is maybe not a good idea to generate a Graph ...

It might well not be possible right now. But I am still convinced that
this is the long term way to go if we want to avoid duplication of
dot-code generation all other MuPAD-Combinat. Furthermore, there are a
lot of graph algorithms that one may want to apply to a combinatorial
module (e.g. Anne will want to test whether it is strongly connected).

Now for the short term: do we have a lot of our combinatorial modules
with multiple edges? Can we possibly temporarily deal with them by
putting a single edge, and a "multiple weight":

E.g. model:

   label1
a --------> b
\          /
 ----------
  label2

by

   [label1,label2]
a -----------------> b

It is sure that not all of the functionnalities in Combinatorial
Module can be lifted right away to Graph, but I am pretty sure we can
do that progressively.

Kind regards,
					Nicolas
-- 
Nicolas M. Thiéry "Isil" <nthiery@...>
http://Nicolas.Thiery.name/