On Fri, Sep 8, 2017 at 11:54 AM, Ben Hutz <bn4...@gmail.com> wrote: > Adding coercion for scheme points is now #23805. This just address adding > coercion through _coerce_map_from_ and does *not* allow P(0) == 0. This > ticket does not address P(0) itself. >
Cool; I've added some comments there. Since the consensus is that P(0) etc. is too ambiguous a choice, that is > now #23806. > I don't think anyone was saying that we should change P(0), just that there should not be a coercion from QQ. A conversion is fine. See http://doc.sagemath.org/html/en/tutorial/tour_coercion.html#conversion-versus-coercion > The bug about different affine patches being the same in memory is #23807 > > > On Friday, September 8, 2017 at 8:21:15 AM UTC-5, Ben Hutz wrote: >> >> Thanks for the additional responses. >> >> The non-equality of the hash functions is enough to convince me that P(0) >> == 0 is not worth the "convenience" of this type of coercion. >> >> However, just to point out another inconsistency. It seems that coercion >> is currently violating this hash equality in other circumstances. >> >> {{{ >> sage: CC(3/2) == QQ(3/2) >> True >> sage: hash(CC(3/2)), hash(QQ(3/2)) >> (1610645504, 7461864723258187528) >> }}}ge >> > Yes, that's a problem that occurs throughout Sage when you try to hash elements of different parents. Sometimes we decide that we have to put up with it.... David >> >> -- >> >> For the other discussion: P(0) = (0:1). I don't have a strong preference >> either way. I have never personally run into any inconsistency issues >> making the assumption of which affine patch is 'default' in dimension 1. I >> find the convenience convenient ;), but do see the potential difficulty in >> tracking down issues this could cause. Actually, I don't find P1(0) = (0:1) >> to be particularly concerning, but P2(0,0) = (0:0:1) (and so one in higher >> dimensions) seems more concerning. >> >> If we were find all the places in Sage where this is used and change >> them, the only place I think a deprecation fits is where this is handled in >> point initialization. My rough feeling of the prevalence of this shorthand >> seems like we would be breaking enough existing code to be concerned about >> just making the behavior change without some kind of user warning through >> deprecation. >> >> Any further thoughts? >> > -- > 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.
