#17792: Word problem for FareySymbol
-------------------------------------+-------------------------------------
Reporter: mmasdeu | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.7
Component: modular forms | Resolution:
Keywords: farey symbol, | Merged in:
SL2Z, word problem | Reviewers:
Authors: Marc Masdeu | Work issues:
Report Upstream: N/A | Commit:
Branch: | 18e034409e8b62c81821e93132a11dd15d7fd432
public/ticket/17792 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by vdelecroix):
Replying to [comment:9 mmasdeu]:
> Replying to [comment:8 vdelecroix]:
Definitely, it would be good to have several output forms available.
Though I do not agree on the way it has to be. First of all, I think that
any function that is accessible by user (i.e. not starting with a `_` and
with default options) should be 0-based. Moreover, if you want something
useful to program morphisms, it would be better if 0-based, isn't it?
From the name `word_problem` I would expect a function that gives me
precisely the Factorization that I proposed. If you want a more raw level
function, which is useful, it would better be `.word_problem(raw=True)` or
`._as_prod_of_gens()`. The name `factor` is not common (or please give a
reference) and is moreover used for elements not parents
{{{
sage: 18.factor()
2 * 3^2
sage: ZZ.factor(18)
...
AttributeError
}}}
I would keep `factor` for factorization over PID or possibly as an alias
for `.word_problem`.
Answering your remark for 0-based to 1-based, I know that these are one
liners and I know how to do. But
- it is additional code
- the code is ugly
- it can be avoided
Note that we interface both pari (the library) and libgap which are
1-based... but
{{{
sage: p = pari("[1,2,3]")
sage: p[1]
2
sage: p = libgap.eval("[1,2,3]")
sage: p[1]
2
}}}
versus
{{{
GP/PARI CALCULATOR Version 2.8.0
? l = [1,2,3];
? l[1]
%4 = 1
}}}
and
{{{
GAP, Version 4.7.7
gap> l := [1,2,3];;
gap> l[1];
1
}}}
Why is that? Because it is natural as we are using Python (and sometimes
C)!
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/17792#comment:10>
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.
