[sage-devel] Re: Problem building develop branch

[Daniel Bump]

On Sunday, July 19, 2020 at 4:02:01 PM UTC-7, Zachary Scherr wrote:
>
> A brief look at the log file suggests that it's using python 2 from 
> homebrew.  Maybe try remove python@2 from homebrew? I don't think they 
> support it anymore


After brew uninstall python@2 I am able to proceed.

Thanks!


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3f58d0e4-599b-497b-b39c-598353aa77e2o%40googlegroups.com.

[sage-devel] Problem building develop branch

[Daniel Bump]

I am trying to build on an iMac running MacOS 10.14.6 (Mojave). I have 
homebrew installed.

I can build the master branch.

When I try to build the develop branch, I quickly run into this:

[patch-2.7.5] ValueError: unsupported hash type sha512

[patch-2.7.5] 


[patch-2.7.5] Traceback (most recent call last):

[patch-2.7.5]   File 
"/Users/bump/sagemath/sage/build/bin/../sage_bootstrap/download/cmdline.py", 
line 130, in run_safe

[patch-2.7.5] run()

[patch-2.7.5]   File 
"/Users/bump/sagemath/sage/build/bin/../sage_bootstrap/download/cmdline.py", 
line 112, in run

[patch-2.7.5] app.download_tarball(args.url_or_tarball, 
args.destination, args.allow_upstream)

[patch-2.7.5]   File 
"/Users/bump/sagemath/sage/build/bin/../sage_bootstrap/download/app.py", 
line 41, in download_tarball

[patch-2.7.5] tarball.download(allow_upstream=allow_upstream)

[patch-2.7.5]   File 
"/Users/bump/sagemath/sage/build/bin/../sage_bootstrap/tarball.py", line 
145, in download

[patch-2.7.5] if self.checksum_verifies():

[patch-2.7.5]   File 
"/Users/bump/sagemath/sage/build/bin/../sage_bootstrap/tarball.py", line 
132, in checksum_verifies

[patch-2.7.5] sha1 = self._compute_sha1()

[patch-2.7.5]   File 
"/Users/bump/sagemath/sage/build/bin/../sage_bootstrap/tarball.py", line 
118, in _compute_sha1

[patch-2.7.5] return self._compute_hash(hashlib.sha1())

[patch-2.7.5] AttributeError: 'module' object has no attribute 'sha1'

[patch-2.7.5] 


[patch-2.7.5] 


[patch-2.7.5] Error downloading patch-2.7.5.tar.gz

[patch-2.7.5] 




I'm attaching patch-2.7.5.log.


Daniel Bump




-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a9e8c17a-a371-4971-97ce-089311052eaeo%40googlegroups.com.
Found local metadata for patch-2.7.5
ERROR [hashlib|:150]: code for hash md5 was not found.
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
ERROR [hashlib|:150]: code for hash sha1 was not found.
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha1
ERROR [hashlib|:150]: code for hash sha224 was not found.
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha224
ERROR [hashlib|:150]: code for hash sha256 was not found.
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 97, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha256
ERROR [hashlib|:150]: code for hash sha384 was not found.
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 147, in 
globals()[__func_name] = __get_hash(__func_name)
  File 
"/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py",
 line 97, i

Re: [sage-devel] Unable to build sage

[Daniel Bump]

On Saturday, July 4, 2020 at 3:12:36 PM UTC-7, Dima Pasechnik wrote:
>
> I guess this is due to gfortran 10.
> We still do not support gcc 10, I think.
> Can you downgrade it to gfortran 9?
>

I had gfortran10 which came with gcc. In installed gfortran (with Homebrew)
which gave me gfortran 8.2. I was then able to build sage.

Thanks!
Dan
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1f6c7908-af7a-4438-b2da-4d8994d7ba25o%40googlegroups.com.

[sage-devel] Unable to build sage

[Daniel Bump]

I'm unable to build Sage since yesterday on an iMac running mojave. 

I have tried (repeatedly) to build the develop branch and others including 
fusion_central_charge-29615. 
I mention the last one since there has been no activity on that branch 
since July 1 and I was able to
build it on this machine previously.

So the code on that branch has not changed, yet I can no longer build Sage 
even
from a clean directory.

What has changed locally is that Homebrew has been updated.

Frequently the build fails in scipy with a complaint unable to install with 
pip3. I am attaching
an excerpt from install.log.

Daniel Bump


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a6e2c4fa-321c-49ff-b6fd-61534bd72051o%40googlegroups.com.


install-exerpt
Description: Binary data

[sage-devel] Re: OS X 10.7 testers needed

[bump]

> > 10.7.3. But I think it's on the slowest oldest ibook that will run lion:-)
>
> Newer 10.7 OS on older system; I'm the reverse.  What does 'About This Mac' 
> say your processor is?

I am running 10.7.3 on a newer Macbook Pro (2.2 GHz i7) and I get a
build failure with 5.0beta1.

Like Justin, I have a configure error building MPIR:

configure: error: could not find a working compiler, see config.log
for details.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Exterior algebras.

[bump]

> (suggestions, or better patches, to improve that example are welcome)

Earlier I posted code to construct exterior algebras in Sage here:

http://sporadic.stanford.edu/bump/exterior.sage

This uses CombinatorialAlgebras. Currently the preferred method of
constructing a ring is to implement it as a subclass of
CombinatorialFreeModule
using convenient hooks that are provided there. I reimplemented the
exterior
algebra that way and for comparison, here it is:

http://sporadic.stanford.edu/bump/exterior1.sage

Both methods are about the same number of lines of code, but the
second method
is cleaner and easier if you know how to do it. I think both rings
have identical behavior.

I would like to comment on the deprecation warnings in
combinatorial_algebra.py.

The method of constructing a ring in combinatorial_algebra.py is quick
and convenient. I do agree that the preferred method is better. I
think
that any construation that is to be put into sage should not use
CombinatorialAlgebras.

However I think the deprecation warning (just "deprecated - don't
use!")
in combinatorial_algebras.py is not helpful. After all,
the old method does work and is convenient and
quick. If I want a quick and dirty ring for some experiment I might
use it.

There is the deprecation warning but no pointer towards a better way.

Dan



-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Exterior algebras.

[bump]

On Mar 19, 10:46 am, mmarco wrote:
> I would need to deal with exterior algebras, and as far as i have
> seen, they are not defined in sage. I could try working on
> implementing them, but i have no idea how to build the corresponding
> class in sage.
>
> What should be the appropiate aproach? Is there some documentation
> about how to build new ring classes?.

Here is an implementation of exterior algebras in sage:

http://sporadic.stanford.edu/bump/exterior.sage

This uses combinatorial_algebra.py. That has a deprecation
warning (do not use). I think that means that you should not
use it for code that is going into Sage itself, but it sure is
handy to be able to implement a ring in just a few lines.

The exterior algebra on [0, 1, 2, 3]

After attaching the file, you can do this:

sage: E = ExteriorAlgebra(4); E
sage: [x0, x1, x2, x3] = E.generators()
sage: x0*x1
x0*x1
sage: x1*x0
-x0*x1
sage: (x0+x1*x2+x3)*x0
-x0*x3 + x0*x1*x2

Daniel Bump

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: Exterior algebras.

[bump]

> I hope other people respond, too.  I would suggest looking at
>
> 
>
> and the code in sage/algebras/quatalg (for quaternion algebras): use
> this as one model for how to implement a noncommutative algebra.

Another place to look is algebras/iwahori_hecke_algebra.py,
showing how to an algebra as a subclass of CombinatorialFreeModule.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[sage-devel] Re: conjugacy_class(es)_representatives

[bump]

> Presumably the method could be moved up the hierarchy a level.  Can
> you make a ticket, or should I add it to my queue?

I made a ticket: http://trac.sagemath.org/sage_trac/ticket/8510

> I think I like the singular.  ;-)

Me too.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] conjugacy_class(es)_representatives

[bump]

The group SL(2,3) has a method conjugacy_class_representatives()
while the group DiCyclicGroup(3) has a method
conjugacy_classes_representatives(). These names are similar but not
identical. Presumably one should be changed.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: newbie: how to "update" a patch

[bump]

> make a new patch replacing the present one?
> --- I have trouble understanding how to do this in mercurial.
> Do I backout my previous patch and make a new one? (I tried this
> and it didn't seem to work. If anyone knows
> how to do this exactly, I'd most appreciate hearing details or being
> pointed to a readable manual/howto...)

It's a good idea to use a mercurial queues, which bring sanity to
working on patches.

Mercurial queues are explained in O'Sullivan's book, which are online:
http://hgbook.red-bean.com/
as well as the doc patches in #8108 and #8147.

But to get started, clone sage:

$ sage -clone work

This will create a subdirectory of the sage root directory called
devel/sage-work. Here $ is command line prompt.

In the directory devel/sage-work you can start a mercurial queue with
the command
$ hg qinit -c

Then you can start a new patch with the command $ hg qnew
or you can import an existing patch that you want to work on with $ hg
qimport [patchname].

The patches are in the directory devel/sage-work/.hg/patches .

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: showcasing your features in release tour of Sage 4.3.1

[bump]

I think #7729 implementing Iwahori Hecke algebras deserves comment.

Dan

On Jan 21, 7:02 am, Minh Nguyen  wrote:
> Hi folks,
>
> The release tour for Sage 4.3.1 [1] is nearly complete. If you can
> help out with showcasing new features in Sage 4.3.1 in the release
> tour, please do so. In case I missed some new features, I appreciate
> your help in showcasing those new features. It would be good to have a
> second pair of eyes to look through the release tour.
>
> [1]http://wiki.sagemath.org/ReleaseTours/sage-4.3.1
>
> --
> Regards
> Minh Van Nguyen
-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Error building sage-4.3.1

[bump]

> However, the error message was fairly clear as to what needs to be done:
> Error installing Fortran: You must install gfortran or set
> SAGE_FORTRAN (and possibly SAGE_FORTRAN_LIB).

Yes, after installing gfortran I was able to build Sage.

Dan
-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Error building sage-4.3.1

[bump]

I had errors building sage-4.3.1.

The trouble came after this warning:

sage-spkg fortran-20100118 2>&1
Warning: Attempted to overwrite SAGE_ROOT environment variable
fortran-20100118

Eventually I got:

Error installing Fortran: You must install gfortran or set
SAGE_FORTRAN (and possibly SAGE_FORTRAN_LIB).

This is on an ubuntu system which never failed to build sage before.
If anyone wants to look at
my install.log, it is here:

http://sporadic.stanford.edu/bump/sage-4.3.1-errors

Dan


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: [sage-combinat-devel] Kazhdan-Lusztig patch / Customizing element printing

[Daniel Bump]

> Thanks! If you don't mind the overhead, I'd suggest to put your code
> on the Sage-Combinat patch server to ease playing around with it and
> merging/coordinating with related patches on the topic.

I was unable to get a working combinat queue. With sage-4.3.alpha1
I get errors in trac_7420-fix-infinite-coercion-discovery-loop.patch.

I did however make a trac ticket:

http://trac.sagemath.org/sage_trac/attachment/ticket/7751/

There are quite a few changes from yesterday. I took your advice and
made a class for Kazhdan Lusztig polynomials, with methods for the
R and P polynomials. I also added a trace feature, so that you
can follow the function calls. Try

sage: R.=QQ[]
sage: W = WeylGroup("F4", prefix = "s")
sage: [s1,s2,s3,s4]=W.simple_reflections()
sage: KL = KazhdanLusztigPolynomial(W,q,trace=true)
sage: KL.P(s4,s1*s2*s3*s4*s3*s2)

If you omit the cache=true, it takes 50 seconds to compute this
polynomial. (However coxeter3 gives it instantly.) But speed is
much better than yesterday. I found a good speedup by caching
reduced words for Weyl group elements. I think it's 3 or 4
times faster now.

At the moment I don't have it working for anything but
finite Weyl groups.

I added a method to produce the reflections of the Weyl group.
This is implemented for finite Weyl groups only. The reflections
(i.e. conjugates of the simple reflections) are in bijection
witht he positive roots, and sometimes you want to know the
corresponding elements, so this returns a dictionary:

sage: W = WeylGroup("A3", prefix = "s")
sage: W.reflections()

{s1*s2*s3*s2*s1: (1, 0, 0, -1),
 s1*s2*s1: (1, 0, -1, 0),
 s1: (1, -1, 0, 0),
 s2*s3*s2: (0, 1, 0, -1),
 s2: (0, 1, -1, 0),
 s3: (0, 0, 1, -1)}

I added a method to produce the Bruhat graph. This is a
graph structure on the Bruhat interval {t | u <= t <= v}
in which x and y are adjacent if x y^(-1) is a reflection.
(Introduced I think by Carrell and Peterson but inspired by
Deodhar.) So you can:

sage: W = WeylGroup("A3",prefix="s")
sage: [s1,s2,s3] = W.simple_reflections()
sage: W.bruhat_graph(s1*s3,s2*s1*s2*s3*s2).plot()
sage: W.bruhat_graph(s1*s3,s2*s1*s2*s3*s2*s1).plot()

> > (1) The algorithms should be moved to coxeter_groups.py.
> > They are applicable to arbitrary coxeter groups.
> > I put them in weyl_groups.py because I'm more familiar
> > with that file and wanted to get a fast prototype.
> 
> Ok. I can't promise to work on this shortly, so I'd suggest you give
> it a shot yourself. It's mostly a question of putting the methods for
> the parent in ParentMethods, and the methods for the elements in
> ElementMethods in the CoxeterGroups class (leaving for the moment the
> option handling to the constructor of WeylGroup).

I will try to do this but it may not be until after Christmas.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: [sage-combinat-devel] Kazhdan-Lusztig patch / Customizing element printing

[Daniel Bump]

> Nice. We will want other representations as well (permutation
> representation, compact reduced word, ...). So this calls for some
> option like:
> 
>   sage: W = WeylGroup("B3", element_print_style = "reduced_word")
> 
> Customizing the way the elements of a given parent are printed is a
> feature that we need in many other situations. So we want a standard
> user interface. I remember David Roe mentioning a couple months ago he
> had done something like this for some parent of his but I did not find
> back his e-mail. Pointers anyone?
> 
> Call for votes / suggestions: what option name should we use?
> 
>  - element_print?
>  - element_print_style? (this is long)?
>  - element_repr? (this is not only about repr, but also latex/...)

We use 'style' in WeylCharacterRing elements. (Thus style="coroots".)

> Yep. I would be perfectly fine just putting a systematic cache on all
> those methods. At least for the moment. If someone comes up with a use
> case where caching actually hurts, then it will still be time to go
> the extra mile.

The harm is that it creates potentially huge RAM-eating dictionaries.
There is optional caching in WeylCharacter rings. See Michael Abshoff's
comments in this message:

http://groups.google.com/group/sage-combinat-devel/msg/f26b726871ab0796?hl=en

and the thread.

> It would feel more natural to me to set this as an option of the KL
> methods. Or would this be too heavy notation wise?  An alternative
> approach would be to add a separate parent modeling the set of all KL
> polynomials:
> 
> sage: W = WeylGroup("A3")
> sage: KL = KazhdanLusztigPolynomials(W, q = ...)  (or 
> W.kazhdan_luztig_polynomials(q))
> sage: KL.P(u,v)
> ...
> 
> That definitely would make sense if this set has some useful algebraic
> structure; but I am too much of an ignorant in the subject to have any
> point of view.

So KazhdanLusztigPolynomials would be a new class, and R,P
would be methods of it. I think I agree.

I'll look again at unique_representation and address your
other comments later.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Segmentation Fault in coerce_actions.c

[Daniel Bump]

I will explain how to make sage have a segmentation fault
with the following alarming message:


Unhandled SIGSEGV: A segmentation fault occured in SAGE.
This probably occured because a *compiled* component
of SAGE has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run SAGE under gdb with 'sage -gdb' to debug this.
SAGE will now terminate (sorry).


Apply the following patch to sage-4.3.rc0:

http://sporadic.stanford.edu/bump/patches/coerce_actions_segfault.patch

This creates a file called sage/algebras/iwahori.py. Eventually
it will make the Iwahori Hecke algebra of a Weyl group but
at the moment it just makes the group algebra. You can do
stuff like this:

sage: H = WeylGroupAlgebra("B3")
sage: [T1,T2,T3]=H.simple_reflections()
sage: (T2*T3)^4
1
sage: (T1*T2)^3
1

Unfortunately you can get a crash by evaluating 2*T1.

A backtrace with gdb shows frames in coerce_actions.c,
coerce.c, parent.c, parent_old.c and element.c, all
in sage/structure/ with corresponding cython files *.pyx.

To get the backtrace, run sage -gdb, make it crash, then 
type bt at the gdb prompt. 

Examination of the backtrace led to the following more 
direct way of causing the crash:

sage: WeylGroupAlgebra("A2").get_action(ZZ)

I can probably work around this by writing a
new _get_action_ method, so maybe this is not
such a severe bug. But I am reporting it here.

If it is deemed severe I will make a trac ticket.

Daniel Bump

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: [sage-combinat-devel] Categories: final report!

[Daniel Bump]

> This is my final status report for the category patches:
> 
>   Yiiippeee!

+1

> Mike just merged them today in Sage 4.3-alpha0, together with one year
> of hard work worth of feature-full patches around root systems, Weyl
> characters, symmetric functions, enumerated sets, semigroups, Hopf
> algebras, by Daniel Bump, Florent Hivert, Anne Schilling, and many others.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: [sage-combinat-devel] Re: Testing the Categories Code in 4.3.alpha0

[Daniel Bump]

> I just ran each long test individually, and annotated them with how
> much time they took (on my macbook pro). They are indeed all below
> 30s, except for a big E8 test which takes 160s. I marked that one as

Oops, E8(1,0,0,0,0,0,0,0) has degree 3875. That could be slow.
I think I probably meant to branch E8(0,0,0,0,0,0,0,1) which
is the standard representation having degree 248. But I think
it's OK to leave the test in but mark it not tested.

> #not tested, and the file now runs under 150s which is good enough
> (especially since I expect further serious improvements when we will
> optimize the combinatorial free module code).

Thanks!

> Dan or Mike: please review trac_5794-long-time-nt.patch on #5794!

One thing to watch out for: since the fundamental weights are
cached, doing one computation with E8 would speed up all
subsequent branching rules involving the same representations.

This is not an issue with this patch, so it looks OK to me.

Dan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-combinat-devel] Re: [sage-devel] Re: [Cython] LiE in Cython

[Daniel Bump]

> By the way: what's the status of this spkg? Is there some
> documentation somewhere of what can be done with it from Sage? (I just
> tried lie-2.2.2.p3 but it does not seem compile on my 32bits i686
> ubuntu box).

William Stein has stated that LiE would not be made a
standard package because it is no longer supported. See:

http://groups.google.com/group/sage-devel/msg/613cc5aa78c89f3d?hl=en

My belief is that this is the right decision and that
the functionality in LiE should be redone natively in
sage.

It can do quite a few things and people have found it
very useful.

One important thing LiE can so is to compute
Kazhdan-Lusztig polynomials. However it is slow and
can't get much past around B3. Coxeter3 is a better
program for this. KL polynomials are quite important
and it should be a priority to get them in Sage. When
I needed them I wrote my own routines, but only for
type A.

Before KL Polynomials can be implemented Bruhat order
must be implemented in Sage. The root system patch does
not do this. Currently Bruhat order is in Sage but only
for Type A. I think a good way to give a fast recusive
definition would be to use Proposition 1.1 in
Stembridge, A Short Derivation of the Möbius Function
for the Bruhat Order, Journal of Algebraic Combinatorics
25, (2007).

Kazhdan-Lusztig polynomials can be computed quickly if
one is willing to cache a large number of results. If
one just caches everything computed, the main limitation
is the size of the Weyl group. Coxeter3 takes a more
intelligent approach by deciding carefully what to
cache.

Dan

--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---

Re: [sage-combinat-devel] Re: [sage-devel] Categories restart: the end?

[Daniel Bump]

> Is this question addressed to me, or ?

Yes. 

Note that the root system patch depends on the category 
patches, which why it came in this thread. Various other
long pending patches depend on it.

Dan

--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---

Re: [sage-combinat-devel] Re: [sage-devel] Categories restart: the end?

[Daniel Bump]

> The next Sage version will be 4.2.  Send me a list of technical
> patches with positive review related to categories, and they can be
> the *first* to go in.  I also see 4.2 as being a relatively quick
> release (compared to the extremely long 4.1.2).

Is it possible to conjecture a timetable for the root system 
patch (#4326)?

Dan

--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] [sage-combinat-devel] Re: Sage 4.0.3 (or 4.1?)

[bump]

> PS 1: a personal point of view for the reviewers: the new category
> code is certainly far from perfect. Yet, I think the reviewing goal
> should concentrate on making sure that the Sage rules are satisfied
> (100% doctests, ...) and that there is no complete show stopper. I am
> eagerly looking forward further comments and suggestions for
> improvements. However, given the difficulty of maintaining this patch
> bomb outside of Sage, and given the amount of code that depends on it,
> those should be left for later patches. Release early, release often.

+1

The slowness in merging code from the combinat queue is a major
problem. After the category patches are merged, there is the root
system patch,
affine root systems, the 5794 patches and a *lot* of other things in
the
combinat queue.

$ wc -l sage-combinat/.hg/patches/series
208

Dan


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Web page looks pretty poor compared to Mathematica's

[bump]

I agree that the sage web page is good, and preferrable to the
mathematica page.

I have one constructive comment, which is that one gets misled
in looking for the documentation. There are two buttons, one
called "help" and one called "library". If you want the docs you
want help. But if you guess that the documentation would be
under library, the first thing you see is "documentation project".

If you go there, you miss the main sage docs.

To me it would be better if the "help" button were supplemented
by a button called "documentation", and "help" was reserved for
links to sage-support etc. Moreover the "library" links that are
documentation related could be moved to documentation, and
the remaining links could be relabelled "news" since the word
library could mean different things to different people.

This is just a suggestion. There could be a better way, but I
do think there is a minor problem here. When I go to the main
page I want to see the word "documentation", not guess where
to look with multiple choices.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Laurent Polynomial problem

[Daniel Bump]

The following appears to me to be a bug. Shouldn't q^(-1) be
in this Laurent polynomial ring?

Dan

sage: P. = LaurentPolynomialRing(QQ)
sage: type(q),type(q^(-1))

(,
 )
sage: q in P
True
sage: q^(-1) in P
False

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Pickling functions

[Daniel Bump]

Some code that has been proposed by Nicolas Thiery
for sage/combinat/families.py would create classes
that have as attributes dictionaries of functions.

However dumps(s) will raise an exception if s is
such a class instance.

Example: the simple reflections in a Weyl group. See:

http://groups.google.com/group/sage-combinat-devel/msg/8b987cd471db3493?hl=en

What it boils down to is this. The following is 
fine in native Python:

>>> import pickle
>>> def f(x): return x+1
... 
>>> pickle.dumps(f)
'c__main__\nf\np0\n.'
>>> pickle.dumps({1:f})
'(dp0\nI1\nc__main__\nf\np1\ns.'

But if you try to run this from within Sage, 
both calls to dumps() will raise exceptions.

Is this a bug in Sage?

Dan



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage Days

[Daniel Bump]

> (hopefully with help from John Voight), and "Lie Algebras/Algebraic
> Groups" as a new package.  For this last one I know that there are
> several freely available packages (e.g. LIE), but I'm not sure if they
> are actively maintained.

Lie Algebras/Algebraic groups as a new package ... many of the things
LiE does can now be done natively in Sage.

I'll take this as a cue to advertise the fact that Sage now (as of
3.0.2) has nontrivial capability for Lie group/Lie algebra computations
including computation of Weyl characters, weight multiplicities, tensor
products and branching rules for characters, conjugation of roots and
weights by Weyl group elements.

For example, we can create the spin representation of Spin(7):

sage: B3=WeylCharacterRing(['B',3])
sage: spin=B3(B3.lattice().fundamental_weights()[2]); spin
B3(1/2,1/2,1/2)

Tensor it with itself and see how that decomposes into
irreducibles:

sage: spin*spin
B3(0,0,0) + B3(1,0,0) + B3(1,1,0) + B3(1,1,1)

Get the decomposition of that into weights:

sage: b3=WeightRing(B3)
sage: b3(spin*spin)
b3(-1,-1,-1) + 2*b3(-1,-1,0) + b3(-1,-1,1) + 2*b3(-1,0,-1) +
4*b3(-1,0,0) + 2*b3(-1,0,1) + b3(-1,1,-1) + 2*b3(-1,1,0) + b3(-1,1,1) +
2*b3(0,-1,-1) + 4*b3(0,-1,0) + 2*b3(0,-1,1) + 4*b3(0,0,-1) +
8*b3(0,0,0) + 4*b3(0,0,1) + 2*b3(0,1,-1) + 4*b3(0,1,0) + 2*b3(0,1,1) +
b3(1,-1,-1) + 2*b3(1,-1,0) + b3(1,-1,1) + 2*b3(1,0,-1) + 4*b3(1,0,0) +
2*b3(1,0,1) + b3(1,1,-1) + 2*b3(1,1,0) + b3(1,1,1)

Restrict it to GL(3) embedded as a Levi subgroup in Spin(7):

sage: (spin*spin).branch(A2,rule="levi")
A2(-1,-1,-1) + 2*A2(0,-1,-1) + 3*A2(0,0,-1) + 4*A2(0,0,0) + A2(1,-1,-1)
+ 2*A2(1,0,-1) + 3*A2(1,0,0) + A2(1,1,-1) + 2*A2(1,1,0) + A2(1,1,1)

Conjugate weights around using the Weyl group:

sage: W = B3.lattice().weyl_group()
sage: [s1,s2,s3]=W.simple_reflections()
sage: s1*s2*s3

[ 0  0 -1]
[ 1  0  0]
[ 0  1  0]
sage: b3(1/2,1/2,1/2).weyl_group_action(s1*s2*s3)
b3(-1/2,1/2,1/2)

Dan

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: GMP license problem, anyone?

[Daniel Bump]

> I have read v2 and I started to read version 3 some time ago. Once I
> got to all the bits that had been tacked on to a perfectly good
> license, i.e. stuff about patent agression, tivoisation, cryptographic
> keys, I stopped reading.

It's good to remember why GPLv3 has provisions against 
patent aggression. Here are a couple of articles written
about a year ago. 

The first, from Fortune Magazine (a pro-corporate source),
deals with the Microsoft-Novell agreement, Microsoft's
claim that the Linux kernel violated 235 software patterns.

The second, from Groklaw, contains an analysis of the
patent provisions that were added to draft 3 of GPLv3.
(This was not the final draft of GPLv3 but the article
remains relevant.)

http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/
http://www.groklaw.net/articlebasic.php?story=20070328231130436

GPLv3 seeks to limit the conveyer's ability to use
software patents to sue or intimidate users. This is the
reason Microsoft doesn't like it. Microsoft has
already threatened the Linux kernel by making claims of
patent infringement. This (recent) history shows why
Microsoft must be treated cautiously, and this is the
subtext of Section 11 of GPLv3.

> >  It is certainly in Microsoft's monopolistic interest to sabotage Free
> >  Software projects, and to cause forks to be created.  A Judas kiss
> >  from Microsoft.
>
> I don't see how a fork will sabotage GMP. Forking is one of the
> essential freedoms that GPL allows.
>
> When you see Microsoft allowing people to fork their operating system,
> that will be the day.

The point of free software is to grant freedom to modify,
which in the limit means the freedom to fork. But if your
project is forked your development base and your user base
are diminished. Forks are thus harmful to a project.
This is a situation where having a freedom is a right, but
exercising that freedom can cause harm.

I understand that the decision to fork GMP has been
taken and isn't likely to be reversed. But I think it's
important to be aware of the broad picture.

> This is one straightforward reason why GPLv3+ only code
> is a problem for the Sage project.It has nothing to do with
> ideological stubborness by Sage developers (instead it is
> ideological stubborness by Stallman).

RMS has been known to be pragmatic about licensing. The parsers
produced by Bison are not GPL'd. And GNU Go (which is
mostly GPLv3) contains two files that are published under the X11
license (similar to BSD) to promote the acceptance of the
Go Text Protocol by allowing these files implementing the
protocol in other programs. RMS was personally involved in both
licensing decisions. Both were taken for pragmatic
reasons: a judgement that this licensing decision best
advanced the cause of free software.

One thing to bear in mind is that it is RMS that makes
the ultimate decision about licensing. I don't suppose
he'd agree to license GMP under v2 but if there was
some compromise that would help here you should talk
to him directly (or Eben Moglen).

Daniel Bump

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Missing Link

[Daniel Bump]

In half_integral.py there is a link:

ALGORITHM: Basmaji (page 55 of his Essen thesis, "Ein Algorithmus
zur Berechnung von Hecke-Operatoren und Anwendungen auf modulare
Kurven", http://wstein.org/scans/papers/basmaji/).  

The URL doesn't seem valid (and assuming it's Jacques Basmaji the
paper doesn't seem published according to mathscinet.

Dan

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Weyl Characters

[Daniel Bump]

> This looks really awesome Dan. It's really great you are working on this.
> Is there any functionality planned for products of GL(1)'s (for example)?

I think you're asking about branching to products,
like GL(4) to the Levi GL(2)xGL(2), i.e. A3->A1xA1.

This is clearly needed. Maybe we need to be able
to make products of root systems. If you can build
the root system for A1 x A1 then the branching
rule is sufficiently general.

Or did I misunderstand the question?

Dan

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Weyl Characters

[Daniel Bump]

I have implemented some tools for working with characters of Lie
groups in Sage. I intend to make a trac ticket for this, but
first I posted in sage-combinat-devel for comment. I'm linking
here to that post for people here interested in Lie groups. A
a link to the patch and a description may be found here:

http://groups.google.com/group/sage-combinat-devel/browse_thread/thread/74ed91d5153e6022?hl=en

I forgot to explain in that post how to extract the
weight multiplicities from a character. Here's
how you do that, using Freudenthal's algorithm.

sage: G2 = WeylCharacterRing(['G',2])
sage: w = 2*G2.lattice().fundamental_weights()[0]; w
(2, 0, -2)
sage: chi = G2(w); chi
G2("2.0.-2")
sage: chi.mlist()
[[(-1, 1, 0), 2],
 [(-1, -1, 2), 1],
 [(1, 1, -2), 1],

 [(0, 0, 0), 3],
 [(1, -2, 1), 1]]

In this list, the first element of a pair is a weight,
the second element its multiplicity. Apart from that,
you can decompose tensor products, extract the character 
of a crystal, and do branching rules, all explained in
the above link.

Dan


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: small documentation problem: "\ " at the end of a line

[Daniel Bump]

> On Wed, 23 Apr 2008 at 01:25PM -0700, John H Palmieri wrote:
> This is exactly why die-hard Python people say "don't use backslashes to
> continue statements":
> 
> http://docs.python.org/dev/howto/doanddont.html#using-backslash-to-continue-statements
> 
> Perhaps we should link to the above guide in the Sage Programming Guide?

Perhaps backslashes followed by whitespace and a newline
could be handled by the preparser. Strip the whitespace
so the newline is properly escaped.

This wouldn't help with .py files where the preparser
is not invoked but it would help with the problem at hand,
unless I'm missing something.

Dan




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Trouble finding the normalizer of a subgroup

[Daniel Bump]

> Perhaps someone can help me figure this out.  I am trying to create an
> elementary abelian subgroup of a symmetric group and then look at its
> normalizer.  Here's what doesn't work:
> 
> s6 = SymmetricGroup(6)
> 
> c1 = s6([(1,2)])
> c2 = s6([(3,4)])
> c3 = s6([(5,6)])
> 
> e8 = s6.subgroup([c1,c2,c3])
> print e8.order()
> 
> n = s6.normalizer(e8)
> 
> It's good through printing the order of "e8".  Then the horrible
> traceback which follows.

I think this is a bug. But the following works:

sage: s6._gap_().Normalizer(gap(e8).name())
Group( [ (5,6), (3,4), (1,2), (3,5,4,6), (1,3,5,2,4,6) ] )

Daniel Bump

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Bug: G2 fundamental weights

[Daniel Bump]

>  In fact, any code that blatantly gives mathematically incorrect results
> should -- in my opinion -- always be marked a BLOCKER in
> trac.  No matter whether the relevant mathematics is small or
> big or important or not.  If nothing else, if a function is known
> to return false results on any input, we should do something
> to make that crystal clear (in the docs, print warnings, etc.), even
> if we can't easily fix the problem.

In any case, it's now in. Michael Abshoff added the G2
fix this morning.

Dan

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Weyl Groups

[Daniel Bump]

> This is very nice but I searched trac for "Weyl" and did not see it.
> How does it compare with GAP?
> http://www.gap-system.org/Manuals/doc/htm/ref/CHAP061.htm#SSEC007.17

It's not in the trac, but you can view the patch at the URL
that I posted. My intention was to make a trac ticket after
perhaps some comment by others, especially the
sage-combinat-devel people.

It's based on GAP in that WeylGroup_gens is a derived
class of MatrixGroup_gens which is a wrapper for GAP's matrix
groups.

But it is independent of the Lie code in GAP but rather
is based on combinat/root_system.py which is in turn the
basis of combinat/crystals/ . I think that root_system.py
together with combinat/crystals/ are nearing some point
of completeness from the point of view of someone that
needs to actually do calculations. The lack of Weyl
groups was a gap (no pun intended).

Dan






--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Weyl Groups

[Daniel Bump]

I've posted a patch here:

http://match.stanford.edu/bump/patches/weylgroup2.patch

I can make a trac ticket but I'm posting it here temporarily
first.

This patch implements Weyl groups as a derived class
of MatrixGroup, with access to the root lattice,
length function, etc.

Dan


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Bug: G2 fundamental weights

[Daniel Bump]

I found that the G2 fundamental weights in combinat/root_systems.py
are the negatives of what they should be. 

http://sagetrac.org/sage_trac/ticket/2808

I should have added some justification for this conclusion
in the trac report. Instead I'm giving it here. You can
look the weights up in Bourbaki, Lie Groups and Lie
Algebras Ch 4-6 (Appendix) and you can also check
the inner products of the weights with the simple
roots (which are correct). The inner product of
the i-th fundamental weight with the j-th simple
root should be positive if i=j and zero otherwise.
I checked that all the other root systems are right
by examining the output following program on the ambient 
lattices. This change had no effect on the output of
the Weyl dimension formula.

def test_lattice(L):
rank = L.ct[1]
roots = L.simple_roots()
weights = L.fundamental_weights()
   return [[i,j, roots[i].inner_product(weights[j])] for i in range(rank) 
for j in range(rank)]

Since this is a genuine bug and trivial to fix I gave
it priority major. Let me know if that was wrong.

Dan

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Root Systems and Weyl Groups

[Daniel Bump]

I'm cross-posting this to sage-devel and sage-combinat. I know
that's a mailing list no-no and I promise not to do it again
but I think there's people on both lists that I'm writing this to.

The original thread was started by Joel Mohler on March 12.

> For starters, I'd like to have two big pieces of new functionality.  We need a
> way to enumerate the Weyl Group and the set of positive roots for a root
> system.  I see that I can get this from lie so I think that makes sense as a
> first implementation.  It seems that the only way to get these things from
> lie is to enumerate them all in memory as a list -- I'd rather have a more
> incremental approach as the Weyl groups are not always small. 

Some of this is in Sage-3.0.alpha0.

sage: L = RootSystem(['E',8]).ambient_lattice()
sage: sage: L.positive_roots()

[(1, 1, 0, 0, 0, 0, 0, 0),
 (1, 0, 1, 0, 0, 0, 0, 0),
 (1, 0, 0, 1, 0, 0, 0, 0),
... snip ...

Second fundamental representation of F4:

sage: WeylDim(['F',4],[0,1,0,0])
1274

Currently (thanks to Justin for the exceptional groups) all root system
are in Sage. They use the Bourbaki convention, not the Dynkin one
for ordering the fundamental weights. These only differ for types 
G and E.

You can also build the crystal graph of any representation
for Cartan types A,B,C,D, and G2. This allows you to do
tensor product decompositions, though I won't explain how
right here.

Enumerating the Weyl group would need to be implemented.

Nicolas Thiery wrote:

> > and from this, it seems that the alternatives above could both be
> > considered "canonical": the first is the Bourbaki numbering.  The
> > second is the Dynkin numbering.
> 
> So far in MuPAD-Combinat, we have taken the Kac convention (although I
> really don't like it for twisted affine). We should definitely add at
> some point an option Bourbaki that would give the other convention (by
> simply applying a permutation to the nodes of the dynkin diagram).

The rest of this message was posted to the sage-combinat
list, but here it is again.

One question is how Weyl characters are to be represented.

A Weyl character is essentially an element of the group
algebra for the weight lattice, which is an infinite abelian group.
This ring could also be represented as an element of a ring of
Laurent polynomials, and some start was made on Laurent
polynomials by Jason Bandlow, David Roe and Mike Hanson.
In any case, I would like the coefficient module to be
an arbitrary commutative ring rather than just ZZ.

In other words, if G is a Lie group of rank r, T its maximal
torus, the Weyl character lives in the group algebra
over X*(T) = ZZ^r, which is the group of rational characters
of T. Any W-invariant element of this group algebra
is a linear combination of Weyl characters. The group
algebra of X*(T) is isomorphic to the ring of Laurent
polynomials with ZZ coefficients, but I'd like the
coefficients to be allowed in an arbitrary commutative
ring, for example a polynomial ring in an auxiliary
variable q.

Once the ring in which the Weyl characters live is
implemented, they could be computed using the Freudenthal
multiplicity formula. There is also a map from the
crystal to X*(T), which is the weight map. It is
actually already implemented.

sage: C = CrystalOfLetters(['D',4])
sage: v = C.list()[0]
sage: v.weight()
(1, 0, 0, 0)

For small representations, the crystal could thus
be used to compute the Weyl character, but this
would be more efficiently done using the
Freudenthal multiplicity formula.

Dan




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Multivariable LaurentSeries Ring?

[Daniel Bump]

> I'll try to get this all taken care of tonight.

Here's another bug. The 1 is not getting coerced into the ring. I
don't know how to fix it.

Dan

sage: R.=LaurentPolynomialRing(QQ,2)
sage: 1+x
---
 Traceback (most recent call last)

/home/bump/ in ()

/home/bump/element.pyx in sage.structure.element.ModuleElement.__add__()

/home/bump/coerce.pyx in 
sage.structure.coerce.CoercionModel_cache_maps.bin_op_c()

: unsupported operand parent(s) for '+': 'Integer 
Ring' and 'Multivariate Laurent Polynomial Ring in x ,y over Rational Field'





--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Multivariable LaurentSeries Ring?

[Daniel Bump]

> Jason Bandlow has been working on this - see his patches (on top of
> David Roe's) at #2291. I don't know in which state that code is, but
> it would be nice if somebody could play with it so we can shake out
> the bugs and merge this once it is ready. There is certainly demand
> for this feature ;)

I applied all five patches to sage-2.10.4.

R. = LaurentPolynomialRing(QQ,2); R

This works and is what I need immediately. Not everything works for me and I
have some comments on the documentation.

>  1. LaurentPolynomialRing(base_ring, name,sparse=False):
>sage: PolynomialRing(QQ, 'w')
>Univariate Laurent Polynomial Ring in w over Rational Field

Should the second line read LaurentPolynomialRing ?

> INPUT:
>base_ring -- a commutative ring
>name -- a string
>names -- a list or tuple of names, or a comma separated string
>n -- a positive integer

Perhaps it should be stated explicitly somewhere that n is the number of
generators.

> Use the diamond brackets notation to make the variable
> ready for use after you define the ring:
> sage: R. = LaurentPolynomialRing(QQ)
> sage: (1 + w)^3
> w^3 + 3*w^2 + 3*w + 1

This doesn't work for me. I get:

sage: R. = LaurentPolynomialRing(QQ)
[snip]
261 break
262 R = _single_variate_poly(base_ring, name, sparse)
--> 263 RR = _multi_variate_poly(base_ring, (name, prepend_string + name), 
2, False, 'degrevlex')
264 P = LaurentPolynomialRing_generic(base_ring, 1, R, RR, 
prepend_string, (name,))
265 _save_in_cache(key, P)

: cannot concatenate 'str' and 'tuple' objects

I realize that I'm commenting on work in progress (that is immediately
useful to me). I won't list more failures like this since they're turned up
by sage -t laurent_polynomial_ring.py.

Thanks,
Dan




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Multivariable LaurentSeries Ring?

[bump]

On Feb 19, 1:27 pm, "David Roe" <[EMAIL PROTECTED]> wrote:

> This should be pretty easy (though multivariable Laurent series rings have
> all kinds of issues associated with them).  I don't have time to implement
> it right now, but if nobody has done it before the weekend poke me and I can
> probably throw something together.
> David

Did anything ever come of this? Multivariable Laurent polynomials
would
be extremely useful.

Daniel Bump

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Build fails with gcc 3.3.5

[Daniel Bump]

Sage 2.9 fails to build on this machine running Debian Sarge. The
ggc version is 3.3.5.

gcc version 3.3.5 (Debian 1:3.3.5-13)
Kernel 2.6.12.6 i686 GNU/Linux

Log exerpt below.

Daniel Bump


periods.cc: In constructor `periods_via_lfchi::periods_via_lfchi(const level*, 
   const newform*)':
periods.cc:382: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
periods.cc:383: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
periods.cc: In member function `virtual void periods_direct::compute()':
periods.cc:459: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
periods.cc:460: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
periods.cc: In member function `virtual void part_period::compute()':
periods.cc:554: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
periods.cc: In member function `void ldash1::init(const level*, const 
   std::vector >&, long int, const 
   rational&)':
periods.cc:593: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
periods.cc: In constructor `lfchi::lfchi(const level*, const newform*)':
periods.cc:635: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
periods.cc: In function `NTL::RR G(int, NTL::RR)':
periods.cc:975: error: call of overloaded `log(int)' is ambiguous
/usr/include/bits/mathcalls.h:110: error: candidates are: double log(double)
/usr/include/c++/3.3/cmath:419: error: long double 
   std::log(long double)
/usr/include/c++/3.3/cmath:411: error: float std::log(float)
make[3]: *** [periods_n.o] Error 1
make[3]: Leaving directory 
`/home/bump/src/sage-2.9/spkg/build/cremona-20071124.p4/src/g0n'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/home/bump/src/sage-2.9/spkg/build/cremona-20071124.p4/src'
Error building cremona

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---