On Fri, Jan 29, 2010 at 06:54:52PM -0800, Anne Schilling wrote:
> > By the way, I just realized that: isn't the cartan type information
> > redundant? Shouldn't HighestWeightCrystal just take a weight as input?
>
> Ok, in principle I agree.
>
> From the programming point of view, how can this be done?
> Currently there are only the optional inputs dominant_weight
> or dominant_weights. For type E they are dealt with in
> __classcall__ . Should this go into HighestWeightCrystal?
> Otherwise, one cannot use
> weight.parent().cartan_type()
> to get the Cartan type and dispatch appropriately.
Mathematically speaking, do we really want to accept:
HighestWeightCrystal(dominant_weights = (...))?
That is, do we want to consider a disconnected crystal as a highest
weight crystal, if all its connected components are highest weight?
I am not so sure. Notes:
- This feature is not currently documented
- The current implementation only works for distinct weights
If not, HighestWeightCrystal would just take a single mandatory
argument weight, and extract the cartan type out of it. At first
sight, I vote for this option.
Long run speaking, I think all the logic would be simpler if there
were only plain highest weight crystal implemented, together with a
clever direct_sum_of_crystals that would detect when all its arguments
would be tensor products and all the weights be distinct, and then
optimize it into a single tensor product with several module
generators (sorry for not realizing this earlier).
> sage -t "4.3.1/devel/sage-combinat/sage/combinat/crystals/crystals.py"
> **********************************************************************
> File
> "/Applications/sage-4.3.1/devel/sage-combinat/sage/combinat/crystals/crystals.py",
> line 350:
> sage: f=T.crystal_morphism(g,acyclic = False)
> Exception raised:
> Traceback (most recent call last):
> File "/Applications/sage/local/bin/ncadoctest.py", line 1231, in
> run_one_test
> self.run_one_example(test, example, filename, compileflags)
> File "/Applications/sage/local/bin/sagedoctest.py", line 38, in
> run_one_example
> OrigDocTestRunner.run_one_example(self, test, example, filename,
> compileflags)
> File "/Applications/sage/local/bin/ncadoctest.py", line 1172, in
> run_one_example
> compileflags, 1) in test.globs
> File "<doctest __main__.example_9[26]>", line 1, in <module>
> f=T.crystal_morphism(g,acyclic = False)###line 350:
> sage: f=T.crystal_morphism(g,acyclic = False)
> File
> "/Applications/sage/local/lib/python/site-packages/sage/combinat/crystals/crystals.py",
> line 437, in crystal_morphism
> return CachedFunction(morphism)
> File
> "/Applications/sage/local/lib/python/site-packages/sage/misc/cachefunc.py",
> line 59, in __init__
> self._argumentfixer = ArgumentFixer(f,classmethod=classmethod)
> File
> "/Applications/sage/local/lib/python/site-packages/sage/misc/function_mangling.py",
> line 109, in __init__
> defaults = f.func_defaults
> AttributeError: 'builtin_function_or_method' object has no attribute
> 'func_defaults'
Ok, this is caused by a recent change in CachedFunction, which now
breaks for non standard Python function. Here the function that is
passed to CachedFunction is d.__getitem__ where d is a
dictionary. Anyway, there is no point in adding a cache to such a
function. So this is easy to fix. The non acyclic case, around line
432, should just finish with:
return morphism.__getitem__
Cherry on the cake, this will be simpler and quite faster.
> > Btw: most of the stuff in check(), is now handled in the generic tests
> > of FiniteEnumeratedSets. So we could strip them out. For classical
> > crystal we could keep a _test_fast_iter_ comparing the elements of
> > list(self) and Crystal.list(self), since the algorithms are different,
> > and we once had bug there.
>
> Feel free to do that if you think it is worth it.
More tests are always worth it. But I can't handle it right
now. Besides it would be good for others to learn how to write
TestSuite tests (don't be scared, it's easy!) :-)
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
