After almost every post I end up thinking a little bit about what I've said. I'll think about another (better?) way to make my point or something in the post I've written gets me thinking about other topics. After yesterday's rant I went out to enjoy a little bit of the weekend and during the quiet moments decided I really should follow up on the cube root function. I had said in the post that show(plot(x^(1/3), (x,-5,6))) generates wrong output and "...there is a way you can get Sage to plot nth roots correctly, but how is a beginner to know this is a special case?".
I spent some time searching on the topic and came up with this. The post is from a Google groups on sage-support. The question was from a teacher back in February 2008 who noticed the problem with plotting x^(1/3). The basic answer is to plot it correctly, type: show(plot(lambda x : RR(x).nth_root(3), -10, 10), figsize=[5,5], ymin=-10, ymax=10) (Why have your eyes glazed over, high school student?) so now, if you weren't already aware, there is a right way and a wrong way to graph things on Sage. Interesting. What am I graphing incorrectly that I'm not aware of?
That success led me to look for the problem with
; surely others must be aware of such a basic problem. With a little more searching I found the answer here. Go to the question on February 5, 2008: "I'm probably exposing my ignorance here, but should 0^0 be really defined? I understand that it might be helpful sometimes in Taylor/Laurent series, but couldn't it give some other problems? E.g.,
sage: lim(x^(1/log(x)),x=0,dir='above')
_2 = e
If one actually defines a function and sage tries to compute, can't it
spill out 1 if it gets 0^0, when it might not be the case.... "
The response enabled me to find the sage-newbie group and one of the relevant posts appears to be this. I think the most interesting part is the response from William Stein, the guru who is the driving force behind Sage, "...change this behavior in Sage so that 0^0 does yield 1. This is consistent with PARI, Magma, Maple, GMP, MPFR, Python,
etc., so makes sense for Sage to do. "
The second thread is here where it is noted: "I believe that for floats, a NaN response is required for IEEE 754 compliance, no?
For purposes of comparison, I can attest that Maple is inconsistent as
a consequence of deliberate design on this issue. For integers, 0^0
is 1; on the other hand, 0.0^0.0 is Float(undefined), that is
essentially NaN. My understanding is that 0^0=1 was the originally
desired outcome (for the usual reasons), but the NaN result was
retained for float input in order to retain IEEE 754 compliance. "
So, let me summarize some points.
- using the normal plotting method, nth roots are plotted incorrectly by Sage
- to plot them correctly, use the method given above
- I've added links on the sidebar to sage-support and sage-newbie
is a wrong result which Sage and other famous software give on purpose (and sometimes inconsistently).
- For IEEE 754 compliance on floats, should Sage give NaN (not a number)?
I'm definitely in WAY over my head. The math part of me is disturbed by the fact that wrong answers are given to the most likely questions (on purpose and without warning) because it's more convenient for dealing with less likely exceptions. And yes, other software program might do the same thing but why does that justify giving wrong answers? There might be times where it's convenient to redefine
another way but you could say that about all the other indeterminate forms. Let's make
because sometimes it will be convenient. As one of the writers mentioned, how do you know that other problems don't occur because the limit is is
and, although it should be undefined, Sage calls it 1? The answer seems to be related to the fact that the float result should give NaN for IEEE 754 compliance, so the limit would be correct. So I tried 0.00000^0.000000 and got an answer of
1.00000000000000
My head hurts! Have compliance rules changed or is it no longer important to follow or was the writer mistaken or...? We're into technical details that I'll never fathom. The one thing I take away from this is that I will have to change one of my teaching points from "Sometimes calculators give the wrong answer" to "Sometimes calculators give the wrong answer on purpose".
The point I still don't get is why not concentrate on giving the correct answer and worry about a work around for the exceptions where you want
. Teachers be warned. Interesting!