Call for vote: lrcalc as standard or optional spkg?

46 views
Skip to first unread message

Nicolas M. Thiery

unread,
Jun 28, 2011, 10:29:52 AM6/28/11
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Dear Sage and Sage-Combinat developers,

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/

Florent Hivert

unread,
Jun 28, 2011, 11:04:11 AM6/28/11
to sage-...@googlegroups.com, sage-comb...@googlegroups.com
Hi,

> 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 Schilling

unread,
Jun 28, 2011, 10:56:47 AM6/28/11
to sage-comb...@googlegroups.com
I vote for this to be a standard spkg.

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.

Benjamin Jones

unread,
Jun 28, 2011, 12:45:29 PM6/28/11
to sage-...@googlegroups.com
On Tue, Jun 28, 2011 at 9:29 AM, Nicolas M. Thiery
<Nicolas...@u-psud.fr> wrote:
>        Dear Sage and Sage-Combinat developers,
>
> With Mike and Anne we are about to finalize an interface with lrcalc:
>

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

Dr. David Kirkby

unread,
Jun 28, 2011, 2:11:35 PM6/28/11
to sage-...@googlegroups.com

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

Volker Braun

unread,
Jun 28, 2011, 3:18:30 PM6/28/11
to sage-...@googlegroups.com
gcc has always taken -On with n>3 to mean -O3. I'm pretty sure they won't break that anytime soon as its a pretty common (ab)use. Making first an optional package would be good for testing. If its quality code and obsoletes Symmetrica then go for it.




Franco Saliola

unread,
Jun 28, 2011, 4:57:36 PM6/28/11
to sage-comb...@googlegroups.com, sage-...@googlegroups.com

[X] A standard spkg

Franco

--

Florent Hivert

unread,
Jun 28, 2011, 6:06:44 PM6/28/11
to sage-...@googlegroups.com

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

Dima Pasechnik

unread,
Jun 29, 2011, 7:45:24 AM6/29/11
to sage-devel


On Jun 28, 4:29 pm, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
>         Dear Sage and Sage-Combinat developers,
>
> 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:
>

[X ] 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" <nthi...@users.sf.net>http://Nicolas.Thiery.name/

Nicolas M. Thiery

unread,
Jun 29, 2011, 6:05:52 PM6/29/11
to sage-...@googlegroups.com
Hi David,

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,

Florent Hivert

unread,
Jun 29, 2011, 6:49:28 PM6/29/11
to sage-...@googlegroups.com
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. 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

Nils Bruin

unread,
Jun 30, 2011, 10:19:17 AM6/30/11
to sage-devel
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?

I am not a fan of bureaucratic policies in general, but I can see some
value in this one. I am also not a fan of discussions on whether or
not to follow policies in particular cases, but those discussion might
just be a necessary evil.

Francois Bissey

unread,
Jun 30, 2011, 2:58:35 PM6/30/11
to sage-...@googlegroups.com

> 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.

Nicolas M. Thiery

unread,
Jul 1, 2011, 7:04:46 AM7/1/11
to sage-...@googlegroups.com, asbuch.math.rutgers.edu@zephyr
Dear all,

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,

Francois Bissey

unread,
Jul 1, 2011, 8:37:49 AM7/1/11
to sage-...@googlegroups.com

> #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 :)

Nicolas M. Thiery

unread,
Jan 20, 2012, 1:12:49 PM1/20/12
to sage-...@googlegroups.com, asbuch.math.rutgers.edu@zephyr
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
- 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.

Nils Bruin

unread,
Jan 20, 2012, 2:36:52 PM1/20/12
to sage-devel
On Jan 20, 10:12 am, "Nicolas M. Thiery" <Nicolas.Thi...@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?
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.

Nicolas M. Thiery

unread,
Jan 20, 2012, 6:24:22 PM1/20/12
to sage-...@googlegroups.com
On Fri, Jan 20, 2012 at 11:36:52AM -0800, Nils Bruin wrote:
> I don't think there is a requirement to have the documentation of an
> optional package installed in the general documentation?

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.

Dima Pasechnik

unread,
Jan 20, 2012, 10:07:59 PM1/20/12
to sage-...@googlegroups.com


On Saturday, 21 January 2012 03:36:52 UTC+8, Nils Bruin wrote:
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?

indeed, even standard packages sometimes don't get their docs installed, e.g. GAP doesn't.
(That's a shame, but this would need work...)

Nicolas M. Thiery

unread,
Jan 24, 2012, 11:26:47 AM1/24/12
to sage-...@googlegroups.com
On Fri, Jan 20, 2012 at 11:36:52AM -0800, Nils Bruin wrote:
> 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.

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.

Reply all
Reply to author
Forward
0 new messages