#16976: Conjugacy classes and rational period functions for Hecke triangle
groups
-------------------------------------+-------------------------------------
Reporter: jj | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.5
Component: modular forms | Resolution:
Keywords: hecke triangle | Merged in:
group conjugacy class rational | Reviewers:
period function | Work issues:
Authors: Jonas Jermann | Commit:
Report Upstream: N/A | 616b0486776cdff54d8653c7bbc52269bd6df44c
Branch: public/16976 | Stopgaps:
Dependencies: #16936 |
-------------------------------------+-------------------------------------
Comment (by jj):
Hey Vincent,
1) I don't mind at all.
2) Thanks a lot. I checked all the changes very closely. They look great!
:-)
I made some small adjustments:
- For Hecke triangle groups k is usually a rational number,
so k = ZZ(k) quite often fails and we want to provide the same
exception message
- I pulled the factor ZZ(-1) factor out of (-Q) again. It produces
better looking numerators/denominators and it emphasizes the
form resp. sign of the factor.
- I used "u = sum((v[0]-1) for v in L)", some authors use "v[0]-1"
instead of "v[0]" in their definitions, so it feels more natural
to me that way.
- For now I added 2 cached_methods back (and ideally I would like to
add
_block_data too).
3) Thanks for the test, I didn't write mine down unfortunately.
"but I would say that removing 3 cached_method is much more!":
Can you maybe elaborate a bit more on the drawbacks/overheads with
(unused)
cached_methods? How large is the overhead? The tests (in particular
interactive usages) seem to only indicate positive effects from caching.
I would prefer to keep the cached methods in:
- primitive_power: I would really prefer to keep this a cached_method.
It only stores one integer and the calculation of it can be long:
Basically the method compares powers of the primitive part against
the
original matrix until it finds a match. Also that method is reused to
e.g. determine if a matrix is primitive. Which is again reused by
other
functions. Moreover the primitive_power is a number of interest for a
given matrix. Caching only occurs if the method is used.
In my opinion this is a perfect example of something worthwhile to
cache.
Also note that most doctests involve only small powers of matrices
and there
are much slower functions which have more influence on the total time
in doctests...
- _basic_data: This method is a candidate to be removed. It is the only
cached
method which is always called, so disabled caching would reduce the
overhead.
The calculation of it basically involves determening a representative
of a
number/matrix in the fundamental domain, which can take very long if
the number
lies close to "1". So why not cache the result? It is also beeing
used for
calculations of automorphy factors for modular forms. So if matrices
are beeing
reused there in modular operations caching could give a big speed up.
It's also
used for "basic" string representations which is a very good
candidate for the
default representation of matrices (just saying). So it seems like a
waste to
compute _basic_data repeatedly (and having to wait for the output).
The user
experience is improved a lot if he has fast response time to his
commands.
Without caching "basic" representation might be too "laggy" to use
comfortably.
Note that when doing calculations one usually uses "basic", "conj" or
"block"
for representations (so the results can immediately be interpreted).
Caching
has a large (positive) effect for such calculations.
I would keep it in, but yes it's definitely a candidate for removal.
- _block_data: I don't think there are many test cases which reuse
block data.
If matrices and their block data are beeing reused several times
caching might
be a big issue. As for _basic_data the user experience with string
representations
("conj" or "block") should at least be considered. Again: I would
keep it in,
but yes it's a candidate for removal.
All in all I also wouldn't neglect the impact on user experience from
fast/slow representations.
If you insist on removing the cached methods I will accept it however.
4) I tried to improve the wording slightly. "Block length" is a term used
in papers.
5) I added more remarks (see is_primitive and is_simple). The terms
basically relate
1-1 to the corresponding terms for the associated fixed points
respectively the
associated binary quadratic form (at least in the hyperbolic case). The
methods
reduced_elements resp. simple_elements return all corresponding elements
in the
conjugacy class of the given element. Ideally those should be member
functions
for conjugacy classes. But those aren't implemented yet (and probably
will
never be). :(
Best
Jonas
--
Ticket URL: <http://trac.sagemath.org/ticket/16976#comment:29>
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.
