On 28 March 2018 at 09:34, TB <mathze...@gmail.com> wrote: > On 28/03/18 10:33, Ralf Stephan wrote: > >> Ask yourself, are these arguments you give for current is_prime(x) >> behaviour not just the inertia of your thinking. >> >> Wolfram tells me plainly "1/3 (2^23 + 1) is a prime number"---no >> ambiguity, no attempt to show a glimpse of algebraic truth. >> >> Pari gives >> ? isprime((2^23+1)/3) >> %1 = 1 >> >> Giac: >> >> is_prime((2^23+1)/3) >> 1 >> >> SymPy however: >> In [7]: isprime((2**23+1)/3) >> Out[7]: False >> >> But then it's clear that the value is not integer: >> In [8]: (2**23+1)/3 >> Out[8]: 2796203.0 >> >> Why not improve mathematics? Why not define the primality term you apply >> in the element is_prime() as having a different name than "prime"? Why not >> introduce 123/1 as notation to avoid ambiguities in mathematics? I'm quite >> astonished that mathematicians allow these fuzziness in their language, it >> is unusual. >> >> > The documentation of RingElement.is_prime [1], which most people will > never read, does give the example of fields, where an element is never > prime. > > I am not sure what will be the impact of changing the global is_prime > function (I used it for rings other than ZZ), but updating its > documentation [2] not to say "Return True if n is a prime *number*", and > saying something about rings which are not the integers, is surely better > than the current situation. >
I think this is the best solution for the problem originally raised. is_prime(x) will be true if x is *mathematically* an integer -- whatever its type -- and that integer is a positive prime number. The documentation would make this very clear. No change to any x.is_prime() methods would be needed. The actual origin of the original problem is not any argument of what the definition of a prime element of a ring is at all, it is the fact that the / operator between two integers (parent ZZ) is rational (parent QQ) regardless of the result, as follows from the policy that the type of the result should only depend on the type of the arguments not on their values. If (and I am not proposing this) the result of x/y for x, y integers or rationals returned an object with type Integer where possible and only Rational where not, then this entire thread would not have started. > > Regarding SymPy, I think this is something more general to Python. Even > unrelated to mathematics, if one wants for example to iterate over the > first half of some list, they might use range(n/2) where n is an integer > which raises: > TypeError: range() integer end argument expected, got float. > > In such scenarios, the programmer will soon learn about floor division. > The difference with is_prime is that a non-integer is expected... > > Regards, > TB > > [1] https://doc.sagemath.org/html/en/reference/structure/sage/st > ructure/element.html#sage.structure.element.RingElement.is_prime > [2] https://doc.sagemath.org/html/en/reference/rings_standard/sa > ge/arith/misc.html#sage.arith.misc.is_prime > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
