Have we come to any conclusions on what steps should be taken after this topic? What seems to be the concensus? Or, at the very least, could someone give a listing of the options we have so that we can give it a poll or something similar?
On Monday, April 2, 2018 at 2:58:36 AM UTC-5, Sebastian Oehms wrote: > > 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.
