On Mon, Apr 9, 2018 at 8:12 PM saad khalid <saad1...@gmail.com> wrote:
> 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? > My favorite is to add a once per session warning to the the global is_prime function the first time it receives a field element. Absolutely no other changes at all. > > 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. > -- -- William Stein -- 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.
