Closed edd8e884-f507-429a-b577-5d554626c0fe closed 2 years ago
Changed author from Antonio Rojas to Antonio Rojas, Matthias Koeppe
Changed reviewer from Matthias Koeppe to Matthias Koeppe, ...
Some comments:
Shouldn't the doc for def _lrcalc_dict_to_sage(result):
go after the implementation?
I think the extra dict
call here is unnecessary:
-return dict({_Partitions(i):Integer(k) for i,k in result.items()})
+return {_Partitions(la): Integer(k) for la,k in result.items()}
(I changed the variable to make it more clear that it is a partition being returned.)
-return dict({tuple(_Partitions(j) for j in i):Integer(k) for i,k in result.items()})
+return {tuple(_Partitions(mu) for mu in la): Integer(k) for la,k in result.items()}
Also, is the list
call necessary here?
-return dict({Permutation(list(i)):Integer(k) for i,k in result.items()})
+return {Permutation(list(la)): Integer(k) for la,k in result.items()}
For speed and memory usage (1 object instead of 2):
for i,k in result.items():
- output[_Partitions(i[0])] = output.get(_Partitions(i[0]), P.zero()) + k*quantum**(i[1])
+ la = _Partitions(i[0])
+ output[la] = output.get(la, P.zero()) + k*quantum**(i[1])
I believe this could be simplified:
- while True:
- try:
- word = Word([i+1 for i in next(iterator)])
- yield SkewTableaux().from_shape_and_word(shape, word)
- except StopIteration:
- break
+ ST = SkewTableaux()
+ for data in iterator:
+ yield ST.from_shape_and_word(shape, Word([i+1 for i in data]))
and similarly if weight
is given. However, I think it would make sense to make wt = tuple(weight)
and then get the weight of the word (perhaps before even constructing Word
) first to avoid creating transient objects. We also don't need word
to be a subclass of Word
; a list
is sufficient.
Changed branch from u/mkoeppe/upgrade_lrcalc_to_2_0 to u/arojas/upgrade_lrcalc_to_2_0
Replying to @tscrim:
Some comments:
Thanks for the suggestions, all implemented now.
Also, is the
list
call necessary here?-return dict({Permutation(list(i)):Integer(k) for i,k in result.items()}) +return {Permutation(list(la)): Integer(k) for la,k in result.items()}
Yes, otherwise the Permutation constructor will interpret the tuple input as cycle notation.
New commits:
2cb4511 | Implement tscrim's suggestions, fix test output |
Branch pushed to git repo; I updated commit sha1. New commits:
e4f4e1b | Simplify |
Branch pushed to git repo; I updated commit sha1. New commits:
f24ff71 | Merge remote-tracking branch 'origin/develop' into t/31355/upgrade_lrcalc_to_2_0 |
Branch pushed to git repo; I updated commit sha1. New commits:
42ecd9a | Merge remote-tracking branch 'origin' into t/31355/upgrade_lrcalc_to_2_0 |
Ping. Anything else needed here?
What is the minimum lrcalc version required by lrcalc_python?
lrcalc and lrcalc_python come from the same repo, so I suppose the versions need to match.
A number of distrbutions have system-wide lrcalc installations, some still version 1.*, and those can be picked up by Sage.
If these are not compatible they should not be used.
1.* will not be picked up, the ivector.h
header was introduced in 2.0. Don't know about 2.0, according to repology only gentoo is shipping that. @kiwifb, any reason it hasn't been updated to 2.1?
I just have been quite busy. And since @orlitzky has migrated a lot of packages to the main tree, I feel less personal pressure to update. We have 2.0 in the main tree but not 2.1 yet. I will have to see what needs to be done.
lrcalc_python/SPKG.rst
claims it is GPL2+ but https://bitbucket.org/asbuch/lrcalc/src/master/python/ and https://bitbucket.org/asbuch/lrcalc/src/master/python/setup.py make it pretty clear that it is GPL3.
Replying to @dimpase:
A number of distrbutions have system-wide lrcalc installations, some still version 1.*, and those can be picked up by Sage.
If these are not compatible they should not be used.
Actually spkg-configure
didn't work at all because it was using C++ instead of C. Fixed it now and added a check for a header only present in 2.1 so it will fail with older versions.
Fixed the license too, should be ready to go now.
I have opened a PR for getting 2.1 in Gentoo and I have an ebuild ready for the python bindings for the sage-on-gentoo overlay just waiting for the PR inclusion before going live [because of dependencies requirements, cannot go in until lrcalc-2.1 is present].
Branch pushed to git repo; I updated commit sha1. New commits:
5d443b9 | Merge remote-tracking branch 'origin/develop' into t/31355/upgrade_lrcalc_to_2_0 |
Branch pushed to git repo; I updated commit sha1. New commits:
ffb08d8 | Merge remote-tracking branch 'origin' into t/31355/upgrade_lrcalc_to_2_0 |
Ping, hope to get this in 9.6
Changed branch from u/arojas/upgrade_lrcalc_to_2_0 to u/tscrim/upgrade_lrcalc_2_1-31355
Description changed:
---
+++
@@ -1,3 +1,8 @@
lrcalc 2.1 is out https://bitbucket.org/asbuch/lrcalc/src/master/ChangeLog
Instead of rewriting Sage's Python bindings to support the new API, we replace them with a wrapper around the new upstream provided bindings
+
+Upstream:
+
+lrcalclib-2.1.tar.gz (lrcalc): https://sites.math.rutgers.edu/~asbuch/lrcalc/lrcalc-2.1.tar.gz
+lrcalc-2.1.tar.gz (lrcalc_python): https://pypi.io/packages/source/l/lrcalc/lrcalc-2.1.tar.gz
Does Sage's auto-download mechanism automatically rename the tarballs to their appropriate values. I am worried that both tarballs (lib and python) are called lrcalc-2.1.tar.gz
on their respective upstream locations.
I made a few other little tweaks and checked the tests. If my changes are good, then it is a positive review.
New commits:
e8d0b5b | Merge branch 'u/arojas/upgrade_lrcalc_to_2_0' of git://trac.sagemath.org/sage into u/arojas/upgrade_lrcalc_to_2_0 |
de4fe09 | Some improvements to lrcalc.py. |
Changed reviewer from Matthias Koeppe, ... to Matthias Koeppe, Travis Scrimshaw
Replying to @tscrim:
Does Sage's auto-download mechanism automatically rename the tarballs to their appropriate values. I am worried that both tarballs (lib and python) are called
lrcalc-2.1.tar.gz
on their respective upstream locations.
Yes, it is renamed to the value given in the tarball
field of checksums.ini
. See comment:80.
Thanks
Changed branch from u/tscrim/upgrade_lrcalc_2_1-31355 to de4fe09
lrcalc 2.1 is out https://bitbucket.org/asbuch/lrcalc/src/master/ChangeLog
Instead of rewriting Sage's Python bindings to support the new API, we replace them with a wrapper around the new upstream provided bindings
Upstream:
lrcalclib-2.1.tar.gz (lrcalc): https://sites.math.rutgers.edu/~asbuch/lrcalc/lrcalc-2.1.tar.gz lrcalc-2.1.tar.gz (lrcalc_python): https://pypi.io/packages/source/l/lrcalc/lrcalc-2.1.tar.gz
CC: @antonio-rojas @anneschilling @fchapoton @tscrim @thierry-FreeBSD @orlitzky @mkoeppe @kiwifb @asbuch @slel
Component: packages: optional
Keywords: upgrade, lrcalc
Author: Antonio Rojas, Matthias Koeppe
Branch/Commit:
de4fe09
Reviewer: Matthias Koeppe, Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/31355