Re: [sage-devel] Re: GiNaC and Python disagree on arithmetic
I uniformized the behavior of 0^0 a long time ago (though I make no claim about what has happened between then and now -- just that it was uniform for a few precious minutes). The decision back then (which I still stand behind) is that while it is mathematically unjustifiable, it's Python's convention so we should stick with it. On Mon, Sep 12, 2011 at 10:28 AM, kcrisman kcris...@gmail.com wrote: On Sep 12, 12:45 pm, Keshav Kini keshav.k...@gmail.com wrote: Hey Burcin, I guess that means you think that pynac should return 1 for 0^0, then? As opposed to making Sage throw a ValueError or something at Integer(0)^Integer(0) ? I think that Sage has had 0^0 return 1 for quite some time now? On the other hand, Wolfram Alpha doesn't like it, and Maxima raises an error. I assume the BDFL has some input on this issue. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: GiNaC and Python disagree on arithmetic
On Mon, Sep 12, 2011 at 10:18 PM, Dima Pasechnik dimp...@gmail.com wrote: I guess this all boils down to the point made by William - that _pow_ needs to be integrated into the coersion framework (currently it is not). +1. Also, I should point out that I didn't make the decision myself back then; I was sitting next to William at the time and we had quite the lengthy discussion about it with some others in IRC. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
On Sep 12, 2:50 pm, Maarten Derickx m.derickx.stud...@gmail.com wrote: sage: a=GF(7)(0) sage: a^a ... ArithmeticError: 0^0 is undefined. sage: a=Integers(7)(0) sage: a^a ... ArithmeticError: 0^0 is undefined. I think something else is going wrong here. It's not so much that the exponent is 0, it's that the exponent is a finite field element! Sage seems frighteningly unconcerned with that, though: sage: k=GF(7) sage: a=k(2) sage: a^a 4 sage: a^(k(-1)) #would Fermat find this amusing? 1 This should be raising an error. Finite fields do no act on themselves via exponentiation. One could have Integers(6) act on it but it's probably not worth the effort. Checking a little further: sage: parent(2^a) Integer Ring sage: cm = sage.structure.element.get_coercion_model() sage: cm.explain(2,a,operator.pow) Coercion on left operand via Natural morphism: From: Integer Ring To: Finite Field of size 7 Arithmetic performed after coercions. Result lives in Finite Field of size 7 Finite Field of size 7 I guess the last examples show that the coercion framework is indeed not used for pow (explain expects an answer in k, but in actuality it lives in ZZ). Apparently, GF(7) is silently lifted to ZZ prior to exponentiation? Doesn't the coercion framework support actions (such as scalar multiplication etc.)? Exponentiation is probably most cleanly handled via that, because it very rarely is a binary operation in the usual sense. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
I'd say we should stick with Python's convention 0^0 = 1. Some additional information: on sage-nt http://groups.google.com/group/sage-nt/browse_thread/thread/67e53f8e5d5061d2/ we chose to follow Python's convention 0^0 = 1 through a bit further. As for Maarten's examples, there are some more in Example 1 of: http://trac.sagemath.org/sage_trac/ticket/10772 At that ticket, only the ArithmeticError was fixed, the infinite recursions and NaNs are still there. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
Since python is merely a programming language and not an authority on
all of mathematics, I don't see why its choice should be given special
consideration. I suppose Ginac has a broader view, but not especially
as broad as Sage is supposed to have.
It is possible to come to some conclusions of what is most likely to
be
useful in conventional programming languages with integers and floats,
e.g. 0.0^0, 0^0.0. This is important for languages in which the
result
of the operation MUST fit in a single word. In Sage, one has the
opportunity
to compute a result that is not so constrained and can be more
informative.
It seems to me you have choices for your values or coercions.
0
1
undefined, NaN, Interval[0,1], Or[0,1], {0,1},
zero_to_zero_power, ...
0^0 (leave it alone)
trap: present issue to consumer and ask for resolution.
Error exit.
Consistency with the choices of the designers of python
when you are dealing with data types that they never considered,
does not seem compelling.
RJF
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
Hi Keshav, On 12 Sep., 11:30, Keshav Kini keshav.k...@gmail.com wrote: RuntimeError: power::eval(): pow(0,0) is undefined That error message is an interesting statement, because it is wrong, even in pure Python: pow(0,0) 1 The error message mentions eval, but it doesn't seem to be eval's fault either: eval(pow(0,0)) 1 Sage yields the same result for pow(0,0) and eval(pow(0,0)). So, to the very least, the error message is misleading. Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
Hi Simon, I believe that error message is propagated from GiNaC. See line 523 of src/ginac/power.cpp in the pynac spkg. The error message is hard-coded and doesn't refer to python's eval() function. -Keshav -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
On 12 sep, 12:16, Keshav Kini keshav.k...@gmail.com wrote: Hi Simon, I believe that error message is propagated from GiNaC. See line 523 of src/ginac/power.cpp in the pynac spkg. The error message is hard-coded and doesn't refer to python's eval() function. You're definitely right. -Keshav -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: GiNaC and Python disagree on arithmetic
Hi Keshav, On Mon, 12 Sep 2011 03:16:27 -0700 (PDT) Keshav Kini keshav.k...@gmail.com wrote: I believe that error message is propagated from GiNaC. See line 523 of src/ginac/power.cpp in the pynac spkg. The error message is hard-coded and doesn't refer to python's eval() function. This should be fixed in pynac. Since you already spent the time to identify the problem, do you want to submit a patch with the fix? https://bitbucket.org/burcin/pynac/src Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: GiNaC and Python disagree on arithmetic
Hey Burcin, I guess that means you think that pynac should return 1 for 0^0, then? As opposed to making Sage throw a ValueError or something at Integer(0)^Integer(0) ? I'll poke around :) -Keshav -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
On Sep 12, 12:45 pm, Keshav Kini keshav.k...@gmail.com wrote: Hey Burcin, I guess that means you think that pynac should return 1 for 0^0, then? As opposed to making Sage throw a ValueError or something at Integer(0)^Integer(0) ? I think that Sage has had 0^0 return 1 for quite some time now? On the other hand, Wolfram Alpha doesn't like it, and Maxima raises an error. I assume the BDFL has some input on this issue. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
If one puts it this way: sage: 0^0 1 sage: RDF(0)^RDF(0) #this one is the most dubious 1.0 sage: SR(0^0) 1 sage: SR(0)^SR(0) RuntimeError: power::eval(): pow(0,0) is undefined I think it's pretty clear that the error should go away unless there are very convincing technical reasons. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
sage: SR(0^0) 1 Well, this is a red herring since 0^0 will evaluate, and SR(1) should be 1. What about CDF or other more bizarre rings? But I agree with you in principle. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
Here some random examples of wich I find the first one the strangest sage: CC(0)^CC(0) NaN - NaN*I sage: a=GF(7)(0) sage: a^a ... ArithmeticError: 0^0 is undefined. sage: a=Integers(7)(0) sage: a^a ... ArithmeticError: 0^0 is undefined. sage: K.x=QQ[] sage: K(0)^K(0) 1 sage: K.x=QQ[sqrt(2)] sage: K Number Field in sqrt2 with defining polynomial x^2 - 2 sage: K(0)^K(0) 1 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: GiNaC and Python disagree on arithmetic
I guess this all boils down to the point made by William - that _pow_ needs to be integrated into the coersion framework (currently it is not). -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
