Calculators: The Bad

As compelling as using calculators and math technology is, there are lots of reasons why people don't like them. Some problems come from the imperfect nature of the tool itself, some problems come from how the user interprets the results and there are some problems caused by how using technology effects the user. I've seen a lot of negative effects from students using calculators without the proper mathematical foundation so I'm aware of the "dark side" of using technology. However, I came across an interesting paper posted on the internet: "Impacts of Using Calculators in Learning Mathematics", Tingyao Zheng. The PDF is posted here. It makes some nice observations I hadn't thought of. So here are some problems in using technology in math; the list is posted on the Calculator page.

  1. All technology uses a finite number of numbers to represent an infinite number of
    numbers. This means they are all subject to various problems such as overflow and underflow.
  2. Some calculations/graphs can’t be performed on a calculator.
  3. Some calculations are wrong on purpose.
  4. Results from a calculator can be misleading/deceptive.
  5. Graphing calculators have bugs like software.
  6. Calculators are great for checking conjectures but can’t prove many of them.
  7. The repetoire of problem solving approaches declines because students go to the
    calculator first. It becomes a crutch. [Tingyao Zheng]
  8. The efficiency of getting an answer from a calculator may cover a lack of conceptual
    understanding of a subject matter. [Tingyao Zheng]
  9. It’s difficult to debug the mistakes a student makes when a calculator is used.
    [Tingyao Zheng]
  10. Technology may furnish very different meanings and functions to the notations used
    in conventional mathematics. [Tingyao Zheng]

A natural consequence of the problems using technology even shows up in two calculators giving different results for the same problem: a surprising result for students who look to technology to provide all the answers. Being aware of the problems introduced from using technology can help guide a teacher in using technology more effectively.

Sage Interact: Pythagorean Tree

The Pythagorean Tree is the last of the fractal manipulatives I've created with Sage Interact. The code is posted on the Python/Sage page. There are 2 versions, the main version is a "balanced" tree and the second (B) version is unbalanced. Let me apologize for the code up front: I'm no programmer. I'm just learning Python and Sage to create resources for math. If it works I'm happy regardless of whether the code is ugly and inefficient.

The code is rough and needs some explaining for those of you might want to modify the mess. Looking at the B version code, the Rotate(A,P,degrees) function  rotates the point A around P by degrees as was mentioned in the post on the Koch Snowflake.

Most of the work, though, is done in the Pythagorean Tree function. It uses the fact that there are always 2 branches: the left branch is a square with sides .8 times the previous square and the right branch is .6 times that square. This means given the topleft of the previous branch the point plbranch can be calculated. The other 2 points of the square can be calculated by rotating topleft -90 degrees and plbranch 90 degrees. Likewise, knowing the point topright and the length of the side of the square for the right branch, prbranch can be calculated. Next, the other 2 points of the square can be determined. The diagram shows how the 4 points making up each square are calculated.

After all that work, the squares are sitting on top of our branch. Now each square has to be rotated. Since rotating the squares results in a 3x-4x-5x right triangle formed by their edges, the degree of rotation can be calculated as 36.87 degrees. The topleft point doesn't rotate, but the other 3 points do. The new (final) position of the points for the left branch is:

rotatelnewtopleft = Rotate(lnewtopleft, topleft, 36.87)
rotatelnewtopright = Rotate(lnewtopright, topleft, 36.87)
rotateplbranch = Rotate(plbranch, topleft, 36.87)

Now that the square for a new branch has been calculated, it can be colored based on how big the length of the side is:

if Llength > .2:
G1 += polygon([topleft, rotatelnewtopleft, rotatelnewtopright, rotateplbranch],rgbcolor=(.502,.333,.086))
else:
CRed = 1/(2-1/iterations)*.27
CGreen = 1/(2-1/iterations)*.72
CBlue = 1/(2-1/iterations)*.05
G1 += polygon([topleft, rotatelnewtopleft, rotatelnewtopright, rotateplbranch],rgbcolor=(CRed,CGreen,CBlue))

The right branch goes through a similar process. Ugly, yes, but it works. A screenshot is posted on the Sage Interact: Fractals page. Unfortunately, on my computer at least, the unbalanced version is a lot slower. I was only able to get 6 iterations (and that took some time) whereas the balance version could create Pythagorean trees to 10 iterations.

 

Graphics: Pythagorean Tree

The last fractal I have is the Pythagorean Tree. The version shown on the Wikipedia page has the left and right sides of the tree "balanced". Compare this to the example shown here at the top of the page. I created a Sage Interact manipulative to create the Pythagorean Tree; today I've posted the output on the Graphics page. For some reason, the unbalanced Pythagorean trees take much longer to produce; the 7th iteration has taken so long I might have to give up on it. For balanced trees I made it up to 10 iterations, though. Strange. I'll post the code for the manipulative in a couple of days.

Interact Essentials: titles

If you're creating a Sage Interact manipulative for your class then you might want it to look more presentable. A little HTML will do the job so there isn't a need to go into much depth. I've picked up just enough HTML "facts", as you will, to make things look just a little bit nicer. A few examples will give you the basic information you need and if, for example, you want to see if HTML has that special font you love then you can dig a little deeper on your own. This site and this site are good places to go for basic information.

I've posted some simple code on the Sage Interact Essentials page. Remember that the pound symbol, #, designates the beginning of a comment that Sage doesn't process. Copy and paste the text into Sage to see the effects.

Interesting!

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 0^0; 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.

  1. using the normal plotting method, nth roots are plotted incorrectly by Sage
  2. to plot them correctly, use the method given above
  3. I've added links on the sidebar to sage-support and sage-newbie
  4. 0^0 is a wrong result which Sage and other famous software give on purpose (and sometimes inconsistently).
  5. 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 0^0 another way but you could say that about all the other indeterminate forms. Let's make \frac{0}{0} = 1 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 0^0 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 0^0 = 1. Teachers be warned. Interesting!

Sage Interact Essentials (1)

For all of its merits, learning Sage has some rough spots. For one, it's a lot more difficult to learn than it should be--just take a look at the 6,408 page Sage Reference Manual and you'll know exactly what I mean. Although the reference manual indicates that, as a longterm goal, Sage's intended audience is (page 4), "mathematics students (from high school to graduate school) teachers, and research mathematicians." and (page 5) Sage should be, "User friendly: It should be easy to understand what functionality is provided for a given object and to view documentation and source code." the documentation is more appropriate for a computer programmer.

I first looked into using Sage in high school classroom about 4 or 5 years ago but couldn't recommend it. The situation, especially for high school students, hasn't improved all that much since. If you want to work with matrices you're going to have to deal with documentation involving rings such as ZZ or QQ. What's a high school students supposed to make of that? Sage also has problems with basic calculations that might be used in high school. How do you explain the output of:

show(plot(x^(1/3), (x,-5,6)))

to your students? It's wrong. Likewise, Sage 4.7 (I haven't upgraded to 4.8 yet) even calculates 0^0 as 1 when, in fact, the correct answer is undefined. I like to use these typical mistakes to justify my teaching point that calculators are imperfect tools and they need a good math background to verify that computer output is correct but really, why should one of the most powerful math software programs generate wrong output on such a basic, well known problem ( 0^0) on version 4.7? It makes you wonder about the output on the complicated stuff.... From what I've read, 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? Why should it even be a special case?

I could use Sage in class to demonstrate a concept but I wouldn't dare require students use such a complicated tool. I doubt that 1 in 10,000 high school students would be capable of working with Sage. Besides, there are just too many simpler programs, such as Geogebra, that can be used to do what you want and are much more appropriate for their level. But there have been improvements! The fact that Sage has support for \LaTeX, and even has a sagetex package for \LaTeX are compelling features for me. A lot of great work is being done and I have enough faith that now is a good time to start learning about Sage. It's long term future is bright in spite of some of the rough edges which are still there.

So now that I've had my rant you can perhaps understand why I have a page for Sage Interact Essentials. I wanted something more user friendly for someone who wants to use Sage as a tool without having to become a programmer. It will, I hope, save you from having to struggle like I continue to. The first essential information to cover are the various options and it is on the Sage Interact Essentials page. Note how, without this page, a beginner is forced to dig into the documentation to get essential information.

Problems: Spiral of Theodorus

The diagram below is known as the Spiral of Theodorus.

Although 6 rectangles are given here, more triangles can be added. If you're studying sequences, two natural questions involve finding the hypotenuse of each triangle and finding each angle using inverse tangents. I've posted the problems here. Since finding the angles might be beyond the ability of your class, you can get the .tex file here SpTheodorus to adjust the output. Here are 2 PDF versions: one (SpTheodorus2) like the diagram above and one (SpTheodorus1) in which where the \theta are gone. I created the diagram by modifying the code from the tkz-euclide guide (page 144). In order to compile the tex file successfully you'll need to download the style files for the package from the archive of the Altermundus site.

If you've never been to the Altermundus site then you're in for a treat: check out the beautiful diagrams created on his site using the various LaTeX packages he authored. I especially like the graph theory examples here.

Sage Interact: fractal fern

It's easy to find fractal ferns on the internet, but since Wikipedia is offline today I'll send you to this page. I built a Sage Interact manipulative to create a fractal fern, sometimes called the Barnsley Fern, up to 100,000 points. Unfortunately, I ran up against the 10 MB barrier, so I've posted the results up to 40,000 points (an 8.8 MB file). Sorry! You'll have to create your own graphics for ferns with more points. The graphical output is posted on the Graphics page, the code is on the Python/Sage page and a screenshot is posted on the Sage Interact: Fractals page.

Be warned that it took a long time to print out 100,000 points. It's best to try creating smaller versions to see how long your computer takes.