#18152: Universal Cyclotomic Field implementation using libgap
-------------------------------------+-------------------------------------
Reporter: vdelecroix | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.7
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: Vincent Delecroix | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/vdelecroix/18152 | e4a352468cf9c018b9bdf148a3de03793a111b9e
Dependencies: #18153 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by vdelecroix):
Hello Christian,
Thanks for having a look!
Replying to [comment:18 stumpc5]:
> I kind of feel bad that you plan to remove that much code I wrote in
weeks of work -- but I guess that's the way it goes if there is something
better...
Me too. I wondered if something were better with your code. But except the
documentation I did not find any case were it was faster.
> Anyway my first question would be whether it is really desired to remove
an algorithm from Sage and instead use the same algorithm from Gap?
Sage should not reinvent the wheel. Gap is now interfaced as a fairly good
level and we should try to maximize its usage at what it is good for.
That being said, it would makes sense to keep your implementation
somewhere with more comparisons to the libgap implementation. Especially
if you found that the Gap implementation has some bug! But I did not find
any relevant example since all tests pass with my branch applied.
> Don't you think that working on the cython part of my implementation
(maybe even moving to plain C of some core functionality) could get it
beyond the speed of the black box (from a Sage point of view) Gap
implementation?
No idea. And I will not try. It is much more work than proposing what I
did. And if you ask me what I would do if I want even more speed, I would
link to Gap at an even lower level.
> Secondly, I remember that I did quite some tests back when I implemented
the UCF. And that in the end, the Sage implementation was slower on some
parts, while faster on others (one I remember were Sage was quicker was
the computation of the Galois conjugates of big elements, in case you want
to test, one example might be {{{E( 2^11 * 3^4 )}}}). I would really like
to redo these tests, but haven't yet been able to get your branch running
on my computer. I will get back once that worked out.
Great! I will add this to the `ucf_test.py` that I wrote. If you have
other examples in mind, please propose. I am not sure it will make a
difference now since big numbers with pexpect implies a lot of parsing and
computation. With libgap it is not the case anymore.
> I also remember to have found a few bugs in the Gap implementation while
implementing UCFs in Sage. That would also not be possible anymore when
only relying on the implementation in Gap.
You do not remember what they are? Did you report them to Gap?
Cheers
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/18152#comment:19>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
