User:Thenub314/Musings

According to Dennis DeTruck we should delay teaching students about fractions until perhaps after calculus. This leas to an interesting mathematical question. How do you teach how to add, subtract, multiply and divide decimal expansions. Of course for finite decimal expansions we do this all the time, nothing to say about that really. Of course the down side to this is that your talking about a very specific subset of the rational numbers. Specifically those where the denominator can be factored completely only using powers of 2 and 5. That seems a bit unfortunate somehow. 1/3 doesn't really exist in such a number system. Sure arbitrary approximations exist, but fairly dividing amongst three people will always short change someone.

And maybe life wouldn't be so bad in the case of 1/3=0.3333&hellip;. But I would find it concerning never to properly explain that 2/3=0.666&hellip; and not 0.6666666667. There is something palpably different between the way a calculator represents 2/3 and the mathematical representation. After a moment of long division my students are usually convinced the calculator is just rounding. It occurred to me the other day while proctoring my exam that it should be not to difficult to write down algorithms that correctly allow you to add, subtract, multiply and (divide?) arbitrary repeating decimal expansions. That is to recover the arithmetic of rational numbers without needing to convert them back to fractions. I should remember to write that down at some point, as a passing amusement.

That being said, I am not sure it does anything to sure up (or take down) DeTruck's position. I am sure he would explain that more complicated algorithms do things within infinite decimals are just as bad as complicate rules for manipulating fractions. I just found it amusing to realize that various passing comments I made to students about not being able to do this or that because there is no last decimal place is technically speaking incorrect. You can still do them, you just need to think a bit about what needs to happen.

A nice aspect of the algorithms is that it yields 1-1=0 and 1-0.999&hellip;=0, which of course is true so the algorithms must reproduce it. Which is a fact that would hopefully be covered before calculus, which means you'd need a proof before you introduce fractions. May of the standard proofs involve fractions in some way. (To be fair, I am not sure how DeTruck would want to explain 9x=9 implies x=1, I would personally at some point invoke 9/9, but you certainly could have cancellation properties.) May involve limits.

To be honest I feel you encounter 0.999... long before notions of convergence. It seems more or less standard (at least among my students) to not to really think of an infinite 0.999&hellip; as 9/10+9/100+9/1000+&hellip; but instead it seems to be a formal sequence of integers arrived at by long division.

Putting this together with the fact one can give a construction of the real numbers can be defined infinite decimals gives a nice intuitive explanation of the number system, even if somewhat clunky mathematically speaking. As pointed out in a monthly (find citation) article it is frequently assumed that the difficulty with constructing the real numbers this way showing the least upper bound axiom holds. I think that this is not the case. Sup's are the easy part. In honesty it is the definition of the arithmetic operations that is clunkier then more usual methods (Such as Dedekind cuts, equivalence classes of Cauchy sequences, fine and consistent families of rational intervals). There is a pretty clear reason for that, The other definitions involve sets of things that are not the real number, so when you add you don't need to produce the exact answer you only need to produce an element of the equivalence class. On the other hand decimal expansions are more or less unique, outside of repeating 9's, so the definition of the operations has to be more exact. To be fair, Dedekind cuts are also fairly exact, and likewise their definition of arithmetic is fairly clunky.