Skip to content
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

Universal Cyclotomic Field implementation using libgap #18152

Closed
videlec opened this issue Apr 9, 2015 · 65 comments
Closed

Universal Cyclotomic Field implementation using libgap #18152

videlec opened this issue Apr 9, 2015 · 65 comments

Comments

@videlec
Copy link
Contributor

videlec commented Apr 9, 2015

Sage ships an implementation of the Universal Cyclotomic Field (in sage.rings.universal_cyclotomic_field.*) that is slower and less reliable than what is in gap. We propose in this ticket an implementation based on libgap.

It fixes some issues about the old implementation:

And is about 10x faster (see comment:10) except for operations on very sparse elements with very large conductors (see e.g. comment:23, comment:27 and comment:28).

Possible follow up:

Depends on #18153

CC: @nthiery @stumpc5 @tscrim @vbraun

Component: number fields

Author: Vincent Delecroix

Branch/Commit: b818c83

Reviewer: Jean-Philippe Labbé

Issue created by migration from https://trac.sagemath.org/ticket/18152

@videlec videlec added this to the sage-6.6 milestone Apr 9, 2015
@videlec

This comment has been minimized.

@videlec
Copy link
Contributor Author

videlec commented Apr 9, 2015

Dependencies: #18153

@videlec
Copy link
Contributor Author

videlec commented Apr 9, 2015

Branch: u/vdelecroix/18152

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 9, 2015

Commit: 7d95734

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 9, 2015

Branch pushed to git repo; I updated commit sha1. New commits:

31385f3Trac 18153: int and infinity from libgap
23eb30cTrac 18152: implementation of UCF using libgap
99c8d80Trac 18152: remove the old implementation
7d95734Trac 18152: Fix coxeter group import

@videlec
Copy link
Contributor Author

videlec commented Apr 9, 2015

New commits:

31385f3Trac 18153: int and infinity from libgap
23eb30cTrac 18152: implementation of UCF using libgap
99c8d80Trac 18152: remove the old implementation
7d95734Trac 18152: Fix coxeter group import

@videlec

This comment has been minimized.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Branch pushed to git repo; I updated commit sha1. New commits:

36fb6e5Trac 18153: better `__int__` and add support for -infinity
e34e9caTrac 18152: fix documentation

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Changed commit from 7d95734 to e34e9ca

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Changed commit from e34e9ca to 376bcc2

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Branch pushed to git repo; I updated commit sha1. New commits:

376bcc2Trac 18152: fix constructor in rings.number_field.number_field

@videlec
Copy link
Contributor Author

videlec commented Apr 10, 2015

comment:8

Now all test pass!

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Branch pushed to git repo; I updated commit sha1. New commits:

e968468Trac 18152: better cmp + 32 vs 64 bits in doctest

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Changed commit from 376bcc2 to e968468

@videlec
Copy link
Contributor Author

videlec commented Apr 10, 2015

A test file to compare timings

@videlec
Copy link
Contributor Author

videlec commented Apr 10, 2015

comment:10

Attachment: ucf_test.py.gz

I did some concrete timings and the conclusion is that in all cases the new implementation is faster by a factor of at least x8 (and it can be up to x20).

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Branch pushed to git repo; I updated commit sha1. New commits:

9dd7433Trac 12158: add a `_sub_` method

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Changed commit from e968468 to 9dd7433

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Changed commit from 9dd7433 to e58f755

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

e58f755Trac 18152: add a `_sub_` method

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Branch pushed to git repo; I updated commit sha1. New commits:

e4a3524Trac 18152: speedup (use X._add_(Y) instead of X+Y)

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 10, 2015

Changed commit from e58f755 to e4a3524

@jplab
Copy link

jplab commented Apr 11, 2015

comment:14

Hi!

Did you have a look at #16116? Does it improve also the multiplication of generic cyclotomic matrices?

Jean-Philippe

@videlec
Copy link
Contributor Author

videlec commented Apr 11, 2015

comment:15

Hello Jean-Philippe,

Replying to @jplab:

Did you have a look at #16116? Does it improve also the multiplication of generic cyclotomic matrices?

I guess so. Should be ten times faster. But I copied-pasted the GAP documentation in the top of the file:

Arithmetical operations are quite expensive, so the use of
internally represented cyclotomics is not recommended for doing
arithmetic over number fields, such as calculations with matrices
of cyclotomics.

Best,
Vincent

@videlec

This comment has been minimized.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Apr 21, 2015

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

ccfc26eTrac 18152: universal cyclotomic field using libgap
1b2d04aTrac 18152: remove the old implementation
f3ef31aTrac 18152: Fix coxeter group import
bb42614Corrected some blank lines and trailing spaces
e3f714eTrac 18152: add a minpoly method to UCF elements
8149677Trac 18152: field_order as a deprecated alias of conductor
28c23ceTrac 18152: `__neg__` for UCF elements

@videlec
Copy link
Contributor Author

videlec commented Apr 21, 2015

comment:38

All right. Updated on the very last 6.7.beta2!

@tscrim
Copy link
Collaborator

tscrim commented Apr 21, 2015

comment:39

Replying to @videlec:

But there is still the most important question: do we keep both versions (one being sparse the other being dense)?

IMO, we should keep both with the default being the dense.

@videlec
Copy link
Contributor Author

videlec commented Apr 21, 2015

comment:40

Replying to @tscrim:

Replying to @videlec:

But there is still the most important question: do we keep both versions (one being sparse the other being dense)?

IMO, we should keep both with the default being the dense.

I was implictely requiring arguments. We will not keep it just because you think it has to ;-) I do have arguments for both sides, but as I am the ticket author I better not participate.

@nthiery
Copy link
Contributor

nthiery commented Apr 22, 2015

comment:41

The main argument I could see for keeping the code around is as follow: The speed balance may evolve in the future, typically if free modules in Sage get optimized, or if new use cases emerge. Of course we could always revive the code then, but it would probably have rotten in the mean time, and we may have completely forgotten about it. It also can be used for testing purposes for comparing two independent implementations of UCF.

Those are not super strong arguments.

The main argument for not keeping it is that we would not want is wasting time maintaining it.

A sensible approach might be to write a brief comment at the beginning of the file / class stating something like: "at this point this code is not used much (see ...). If maintaining it becomes a bother in the future, it's ok to discard it".

@jplab
Copy link

jplab commented Apr 29, 2015

comment:42

Perhaps one could add a comment/warning in the beginning of the file also to mention that GAP uses a dense representation and a link to the current ticket.

If there is a use case popping up in the future we could revive the code as Nicolas mentioned.

@Christian: In your actual usage (not tests), is sparse faster than the current dense representation of GAP?

Also: I just updated to 6.7.beta3 on my computer and pulled the ticket. There was a small conflict in the file

src/doc/en/reference/rings_standard/index.rst

Should I push the resolution of the conflict here?

@videlec
Copy link
Contributor Author

videlec commented Apr 29, 2015

comment:43

Replying to @jplab:

Also: I just updated to 6.7.beta3 on my computer and pulled the ticket. There was a small conflict in the file

src/doc/en/reference/rings_standard/index.rst

Should I push the resolution of the conflict here?

Yes please.

@jplab
Copy link

jplab commented Apr 29, 2015

Changed branch from u/vdelecroix/18152 to u/jipilab/18152

@jplab
Copy link

jplab commented Apr 29, 2015

Changed commit from 28c23ce to dc3de84

@jplab
Copy link

jplab commented Apr 29, 2015

comment:45

Et voilà!


New commits:

dc3de84Merge branch 'u/vdelecroix/18152' of trac.sagemath.org:sage into SageMath6.7.b3

@jplab
Copy link

jplab commented Apr 30, 2015

comment:46

Hi,

All test passed on 6.7.beta3!

Could you add a comment/warning at the beginning of the file mentioning the old implementation and a link to the ticket?

Perhaps it would be good to mention this in the documentation as well?

@videlec
Copy link
Contributor Author

videlec commented Apr 30, 2015

Changed commit from dc3de84 to b818c83

@videlec
Copy link
Contributor Author

videlec commented Apr 30, 2015

Changed branch from u/jipilab/18152 to u/vdelecroix/18152

@videlec
Copy link
Contributor Author

videlec commented Apr 30, 2015

comment:47

Done. I also simplified some imports.


New commits:

ba5ed57Trac 18152: add a note about the change of implementation
b818c83Trac 18152: remove and simplify some imports

@jplab
Copy link

jplab commented May 6, 2015

comment:48

Hi,

This looks good to go as I see it.

I set it to positive review.

@vbraun
Copy link
Member

vbraun commented May 6, 2015

Changed branch from u/vdelecroix/18152 to b818c83

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants