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. John On 16 March 2016 at 09:54, Jeroen Demeyer <jdemeyer@cage.ugent.be> 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)). >