#18299: upgrade prime_powers
---------------------------------+------------------------
Reporter: vdelecroix | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.7
Component: number theory | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #16880 | Stopgaps:
---------------------------------+------------------------
Comment (by vdelecroix):
Replying to [comment:5 leif]:
> W.r.t. generators:
>
> I guess Karl-Dieter refers to displaying `generator object at ...`
instead of a list of numbers in interactive mode, which might be annoying
to (Python) newbies.
>
> In general (or most cases), generators are "better", so we'd IMHO just
have to educate new users somehow, telling them they can simply use
`list(foo(...))`. ;-)
And in Python 3 almost everything becomes an iterator (map, range, etc).
> Or we could let the "default" functions wrap generator versions, but
then we'd have to revert the behaviour of `primes()` etc. again, which is
a bit odd as well.
Changing `primes` is not an option, see
[https://groups.google.com/forum/#!searchin/sage-
devel/primes$20prime_range/sage-devel/zYgAgilY5bY/dcVaEDOGmc8J this
thread].
> IIRC Cython meanwhile supports generators, so e.g. `primes()` could be
sped up, at least for "small" numbers (exceeding PARI's stored primes),
but that's a bit off-topic.
Yes, that would be good.
Replying to [comment:6 leif]:
> P.S.: For convenience, we could also add generators like
`n.next_primes()`, `n.next_prime_powers()` etc.
>
> [[BR]]
>
> Another way to avoid the `generator object at ...` would be to wrap the
generators in classes, similar to `n.factor()` (although the latter
doesn't do ''lazy'' factoring). (We do have a `Primes` class, but e.g.
not `PrimeRange` or the like.)
Wrapping might be a reasonable option, but then what should we do when
sombedy does `len(l)`? Expand the list? Just run the iterator? Use
`prime_pi`? And with `l[4]`? Should we use `next_prime`? Use `nth_prime`?
The best solution depends on the usage and this is why I do prefer
avoiding wrappers. But this is what has been proposed in the above
thread... I would be happy if there is enough documentation mentioning the
other ways of accessing the information. So let me do that.
Concrete proposition:
- make `Primes` and `PrimePowers` behave like `IntegerRange`
{{{
sage: Primes(100, 1000)
Set of prime numbers in the range 101 <= p < 998: 101, 103, 107, 109, ...
sage: Primes(2**30)
Set of prime numbers in the range 2 <= p < 1073741790: 2, 3, 5, 7, ...
}}}
(note that the bounds are computed accurately to have a simple equality
test)
- make `primes` a deprecated alias of `Primes` (but keep it in
`sage.rings.arith` as it is)
- change `sage.rings.arith.prime_powers` to an iterator
- in the global namespace make `prime_powers` a deprecated alias of
`PrimePowers`
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/18299#comment:7>
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.
