Hello, This topic is a good example, that wrong names can be worse than wrong code.
Only the user knows what he has in mind using the adjective "prime": 1) prime in a "narrower sense": being a prime number 2) prime in a "broader sense": being a prime element of a unital commutative ring Therefore, the user must have the possibility to solve this ambiguity. If we will do that by an optional argument (as suggested by Erik Bray), then we have to fix a default! Taking the default to be 1) would prefer the casual user and keep track with popular CAS. WolframAlpha answers the question "is 3/1 prime?" in the sense of 1) with "true". If you have 2) in mind this seems to be a bug. But to be fair: The result "true" matches the explanation WolframAlpha gives for the adjective "prime" (namely according to 1)). If you ask "is 3/1 a prime element?" then it shows you the definition of "prime element" but does not calculate any thing. Now, Sage can calculate this, and accordingly gives the answer in the sense of 2) like mathematicians would expect. Does it so, always? sage: is_prime(I) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) ............ TypeError: Unable to coerce I to an integer This looks as if even Sage is trying to give the answer according to 1), as well! Nevertheless, taking 2) as default would raise less compatibility problems (and seems to be the favorite in most of the contributions of this thread). But anyway, IMHO the best thing would be to follow the suggestion of Eric Gourgoulhon, solving the ambiguity by separated function names. But if the name "is_prime" should survive, you will have to make a "default"-decision, as well. As a newcomer to sage-devel I cannot really say, how painful the most transparent solution would be, but I think it should be taken into account, too: Deprecation of "is_prime" as function (not as method!!! since there is no ambiguity here) and replace it by two new functions "is_prime_number" and "is_prime_element" (according to the corresponding Wikipedia articles). The first function should try to coerce the input into ZZ and raise an error if this it not possible or not positive. The second one should raise an error if the input is not an element of a unital commutative ring and a warning in the case the ring is a field (according to https://trac.sagemath.org/ticket/25046). In cases as for the SymbolicRing above a NotImplementedError should be raised. If you think deprecation of "is_prime()" would be to painful, then which of both ("is_prime_number" or "is_prime_element") should keep the name "is_prime"? I found contributions for both possibilities! Best, Sebastian -- 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.
