-
-
Notifications
You must be signed in to change notification settings - Fork 568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replace gap.eval with libgap calls in combinat/combinat.py #16719
Comments
Changed keywords from gap, bignum, expect, pexpect to gap, bignum, expect, pexpect, libgap |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Changed keywords from gap, bignum, expect, pexpect, libgap to gap, bignum, expect, pexpect, libgap, stirling |
This comment has been minimized.
This comment has been minimized.
Dependencies: #16380 |
comment:4
Also with #16380 (which I've added as a dependency because it's not been put into a release yet), we don't have to worry about the startup time of libgap anymore (which was really annoying). +1 to doing this. |
comment:5
This is blocked by:
See #16750 |
New commits:
|
Commit: |
comment:9
OK, now that strings get to GAP, back they get as
Shouldn't lists of chars be converted to strings? |
Author: Ralf Stephan |
Merged: #16750 |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:13
It felt more natural to give tuples of chars as string, but tuples of char+string as list of strings. If the latter had been the original behaviour the GAP T_CHAR hassle wouldn't have been necessary. Please review. |
comment:17
Note that this will conflict with #13982 for |
Changed merged from #16750 to none |
Dependencies: #16750 |
comment:19
I wouldn't mind removing the unordered tuples bit from this patch, especially for speed reasons, and choice of algorithm. It's just that I don't like it that you simply remove that doctest that results in |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:21
For |
Changed branch from u/rws/replace_gap_eval_with_libgap_eval_in_combinat_combinat_py to u/jdemeyer/ticket/16719 |
Reviewer: Jeroen Demeyer |
Changed branch from u/jdemeyer/ticket/16719 to u/vbraun/ticket/16719 |
comment:25
The reviewer commits look good to me. I've added a patch to make the calls to my beautiful library interface less ugly ;-) New commits:
|
Changed reviewer from Jeroen Demeyer to Jeroen Demeyer, Volker Braun |
Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. Last 10 new commits:
|
Changed branch from u/vbraun/ticket/16719 to |
As first reported in #15625 (comment:7) with
lucas_number1
, the same problem is encountered with gap evaluation of Stirling numbers:The way to go would be to replace
gap.eval
withlibgap.eval
and it's faster, too:Addendum: even faster would be to use
(n-1)!*H(n-1)
forstirling(n,2)
, dependent on #16671:Depends on #17157
CC: @vbraun
Component: combinatorics
Keywords: gap, bignum, expect, pexpect, libgap, stirling
Author: Ralf Stephan
Branch/Commit:
d6698e2
Reviewer: Jeroen Demeyer, Volker Braun
Issue created by migration from https://trac.sagemath.org/ticket/16719
The text was updated successfully, but these errors were encountered: