With Mike and Anne we are about to finalize an interface with lrcalc:
------------------------------------------------------------------------------
#10333: An interface to Anders Buch's Littlewood-Richardson Calculator lrcalc
The "Littlewood-Richardson Calculator" is a C library for fast
computation of Littlewood-Richardson (LR) coefficients and products of
Schubert polynomials. It handles single LR coefficients, products of
and coproducts of Schur functions, skew Schur functions, and fusion
products. All of the above are achieved by counting LR (skew)-tableaux
of appropriate shape and content by iterating through
them. Additionally, lrcalc handles products of Schubert polynomials.
The web page of lrcalc is: http://math.rutgers.edu/~asbuch/lrcalc/
------------------------------------------------------------------------------
lrcalc will progressively become a key low-level component for Sage's
symmetric functions library. This evolution will be simpler if lrcalc
is always available.
I therefore would like to cast a vote. Should lrcalc become:
[ ] A standard spkg
[ ] An optional spkg
lrcalc weights 500Ko (100Ko of C code + administrative files +
mercurial repo). It's GLPV2+ with no dependencies. The code is quite
clean and so far proved to be portable: we used it in MuPAD-Combinat,
under MacOS, various flavors of Linux, and CYGWIN; tests on solaris
are welcome!
Thanks for your votes!
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
> With Mike and Anne we are about to finalize an interface with lrcalc:
>
> ------------------------------------------------------------------------------
> #10333: An interface to Anders Buch's Littlewood-Richardson Calculator lrcalc
>
> The "Littlewood-Richardson Calculator" is a C library for fast
> computation of Littlewood-Richardson (LR) coefficients and products of
> Schubert polynomials. It handles single LR coefficients, products of
> and coproducts of Schur functions, skew Schur functions, and fusion
> products. All of the above are achieved by counting LR (skew)-tableaux
> of appropriate shape and content by iterating through
> them. Additionally, lrcalc handles products of Schubert polynomials.
>
> The web page of lrcalc is: http://math.rutgers.edu/~asbuch/lrcalc/
> ------------------------------------------------------------------------------
> lrcalc weights 500Ko (100Ko of C code + administrative files +
> mercurial repo). It's GLPV2+ with no dependencies. The code is quite
> clean and so far proved to be portable: we used it in MuPAD-Combinat,
> under MacOS, various flavors of Linux, and CYGWIN; tests on solaris
> are welcome!
One more argument for using it. Having it in standard Sage is a good step
toward getting rid of Symmetrica which often causes problems and is no more
maintained.
> lrcalc will progressively become a key low-level component for Sage's
> symmetric functions library. This evolution will be simpler if lrcalc
> is always available.
>
> I therefore would like to cast a vote. Should lrcalc become:
Therefore:
> [X] A standard spkg
> [ ] An optional spkg
Cheers,
Florent
Anne
> Nicolas M. Thiéry "Isil"<nth...@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-comb...@googlegroups.com.
To unsubscribe from this group, send email to sage-combinat-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
I've used lrcalc extensively in the past and I am very impressed with
it. I vote:
[ X ] A standard spkg
[ ] An optional spkg
--
Benjamin Jones
I thought it had been agreed no package would be standard unless it is first
optional.
I tried compiling this on OpenSolaris. It builds with a couple of warnings about
variables set but never used. There's no test code in the source code, but I
tried a few of the examples in the README file and they gave the same output.
The authors are using the compiler flag -O6, with an obvious intension of
getting maximum optimisation. I'm not sure what happens in a case like that. It
is not a gcc supported option
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#Optimize-Options
so it might break on future release of gcc if the GCC developers tighten up on
the compiler options, which they have done recently. Until gcc 4.6.0, the
compiler option -KPIC was ignored by gcc, as it's an option used by the Sun
compiler. But now gcc 4.6 actually exits with an error if that option is given.
It would certainly be worth discussing with the developers of the package why
they use -O6, when it's not supported by gcc.
Dave
[X] A standard spkg
Franco
--
Unfortunately, it won't obsolete the whole Symmetrica, but certainly one of
the most used part. However a large part of Symmetrica is being rewriten in
sage (Schubert polynomials, symmetric function basis changes). So probably at
some point, we will realize that we don't use Symmetrica anymore.
Cheers,
Florent
On Tue, Jun 28, 2011 at 07:11:35PM +0100, Dr. David Kirkby wrote:
> I thought it had been agreed no package would be standard unless it
> is first optional.
Could someone confirm? At the price of one more ticket, we could
possibly go for optional for one release and then switch to standard
if this seems safer to get feedback.
> I tried compiling this on OpenSolaris.
Thanks!
> It builds with a couple of warnings about variables set but never
> used. There's no test code in the source code, but I tried a few of
> the examples in the README file and they gave the same output.
>
> The authors are using the compiler flag -O6, with an obvious
> intension of getting maximum optimisation. I'm not sure what happens
> in a case like that. It is not a gcc supported option
>
> http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#Optimize-Options
>
> so it might break on future release of gcc if the GCC developers
> tighten up on the compiler options, which they have done recently.
> Until gcc 4.6.0, the compiler option -KPIC was ignored by gcc, as
> it's an option used by the Sun compiler. But now gcc 4.6 actually
> exits with an error if that option is given.
>
> It would certainly be worth discussing with the developers of the
> package why they use -O6, when it's not supported by gcc.
Which version of lrcalc did you use?
Anders has not yet released officially the one included in the
lrcalc-1.1.5b.spkg I posted on #10333. This lastest version uses a
standard autotools 'configure / make / make install' which does not
specify compilation flags. It also contains (admittedly minimal) tests
which you can run with ``make check`` (or, from the spkg, using
spkg-check).
Cheers,
> I thought it had been agreed no package would be standard unless it
> is first optional.
There were indeed such an agreement. However, I'd rather following the idea of
the rule rather than the letter. As far as I remember (I can't manage to find
back the discussion), the goals of delaying inclusion was:
- testing the quality and the stability of the package;
- more important: check for long term maintenance.
I'd say that in MuPAD we used quite often this package for nearly 7 years, so
I'm pretty confident on both point. Therefore except for technical detail and
testing the interface with Sage, I don't see the point of delaying inclusion
in Sage.
Cheers,
Florent
> On Jun 29, 3:49 pm, Florent Hivert <florent.hiv...@univ-rouen.fr>
>
> wrote:
> > Hi David,
> >
> > > I thought it had been agreed no package would be standard unless it
> > > is first optional.
> >
> > There were indeed such an agreement. However, I'd rather following the
> > idea of the rule rather than the letter.
>
> [...]
>
> > I don't see the point of delaying inclusion in Sage.
>
> One reason to follow the letter anyway is setting precedent. If you do
> this now, then chances are pretty good that there will be someone in
> the future championing inclusion of package X. He/she might well point
> to this discussion and argue immediate adoption as a standard package
> by claiming similarity in situation. This may or may not be justified
> and whether it is may depend on your point of view. Now you find
> yourself having to argue for or against that. By sticking to the
> policy you avoid (or at least reduce) having that unproductive
> discussion. Is standard inclusion of lrcarc now worth increased
> chatter about immediate standard inclusion vs. first-optional-then-
> standard-inclusion in the future?
>
Well there is a precedent already: ppl
This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information.
Ok, let's not waste more time discussing this. Unless someone
complains loud immediately, I consider that there is a consensus on
making lrcalc a standard spkg, after a one-release period as an
optional spkg in order to satisfy the official rule. I created #11563
accordingly.
If someone could review shortly the configuration files of the spkg on
#10333, we might have a chance to get the optional spkg into 7.4.1,
and the standard spkg in 7.4.2.
Cheers,
> #10333, we might have a chance to get the optional spkg into 7.4.1,
> and the standard spkg in 7.4.2.
lol! With a long time plan like that one it should work :)
#10333 (interface to lrcalc as optional spkg) got almost merged, but
finally there is a little documentation issue: I am not sure we
currently have support for conditionally defined documentation for
conditionally compiled Python modules (see #10333 for details).
Unless:
- Someone knows how to achieve this simply
- Someone complains loud in the upcoming two days
I propose to go for the simple and time saving solution: to make
lrcalc right away a standard package, skipping the one release
probation period.
I guess not though this is ugly.
> It looks like the warning mentioned in
>
> http://trac.sagemath.org/sage_trac/ticket/10333#comment:25
>
> should go away if you delete
>
> " sage/libs/lrcalc/lrcalc"
>
> (doc/en/reference/libs.rst, line 28)
>
> Once your package goes standard, you can put that line in. The
> administrative burden of this pales in comparison to all the
> "#optional - lrcalc" comments that you got to put in and remove upon
> standard inclusion.
Oh well; that would have saved the time to do a ticket on top of a
ticket, etc. But arguing over it would take even more time :-) I
stripped the patch from this hunk and reposted it.
On Jan 20, 10:12 am, "Nicolas M. Thiery" <Nicolas...@u-psud.fr>
wrote:
> On Fri, Jul 01, 2011 at 01:04:46PM +0200, Nicolas M. Thiery wrote:
> > Ok, let's not waste more time discussing this. Unless someone
> > complains loud immediately, I consider that there is a consensus on
> > making lrcalc a standard spkg, after a one-release period as an
> > optional spkg in order to satisfy the official rule. I created #11563
> > accordingly.
>
> #10333 (interface to lrcalc as optional spkg) got almost merged, but
> finally there is a little documentation issue: I am not sure we
> currently have support for conditionally defined documentation for
> conditionally compiled Python modules (see #10333 for details).
>
> Unless:
> - Someone knows how to achieve this simply
I don't think there is a requirement to have the documentation of an
optional package installed in the general documentation?
Apparently, that is not enough; see #10333. Help is very welcome, for
I don't understand why the problem shows up here and not for other
optional modules.