John Cremona on Wed, 16 Mar 2016 12:48:19 +0100

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Proposal to extend primes()

DIfferent people will want different abbreviations for their common
use case.  I can imagine wanting (for example) primes(1,4) to mean
primes congruent to 1 mod 4 (and then another parameter needed for a
bound).  I can also imagine a *very* common use for primes(pmax, N)
returning the primes up to pmax which do not divide N.

In view of this I think keeping primes([a,b]) for primes in an
interval makes sense.


On 16 March 2016 at 09:54, Jeroen Demeyer <> wrote:
> On 2016-03-16 10:32, Karim Belabas wrote:
>> To save two keystrokes (the [ and ]) at the expense of a (IMHO) more
>> cryptic
>> interface ?
> Well, I personally find primes([a,b]) more cryptic while primes(a,b) looks
> more natural for me. Also, I quite like the idea of being able to write
> primes(,n) for all primes <= n.
> But you are right that there no fundamental reason to prefer primes(a,b)
> over primes([a,b]).
>> Currently a single argument describes the interval (as in e.g.
>> polrealroots),
>> and I had thought about adding another optional one to specify an
>> arithmetic progression, e.g.
>>    primes([a,b], Mod(c,q))
> That would certainly be useful mathematically. But again, I would prefer to
> see primes(a, b, Mod(c,q)) instead of primes([a,b], Mod(c,q)).