Date: Sep 30, 2013 11:16 AM
Author: RGVickson@shaw.ca
Subject: Re: Is (t^2-9)/(t-3) defined at t=3?
On Saturday, September 28, 2013 2:20:58 PM UTC-7, Hetware wrote:

> On 9/28/2013 4:24 PM, Richard Tobin wrote:

>

> > In article <9cSdnYGhH7CMpNrPnZ2dnUVZ_sCdnZ2d@megapath.net>,

>

> > Hetware <hattons@speakyeasy.net> wrote:

>

> >

>

> >> So the answer is consensus among mathematicians holds that F(t) = (t^2 -

>

> >> 9)/(t - 3) is undefined at t=3?

>

> >

>

> > Yes.

>

> >

>

> >> Perhaps what I should have said at the

>

> >> outset is something along the lines of: on any given day, if I'm setting

>

> >> up an equation in physics, and produce an expression such as F(t) = (t^2

>

> >> - 9)/(t - 3), I treat it as t+3, and do not expect any adverse

>

> >> consequence from doing so.

>

> >

>

> > Your simplification is not valid for t=3. If there is a real

>

> > physical interpretation, perhaps you can derive the formula t+3

>

> > without going through the intermediate form (t^2-9)/(t-3). Or

>

> > consider the special case t=3 to show that the result is indeed

>

> > t+3 in that case too.

>

> >

>

> > In fact, I would be interested to see a physical problem where you

>

> > can't do that.

>

> >

>

> > -- Richard

>

> >

>

>

>

> I believe most mathematicians solving for x as a function of t given

>

>

>

> t^2 - 9 = x (t - 3)

>

>

>

> would not hesitate to factor the left hand side and divide both sides by

>

> t - 3 without treating t = 3 as a special case. Doing so repeats the

>

> sin of dividing by zero twice. We can certainly solve

>

>

>

> t^2 - 9 = 6 (t - 3)

>

>

>

> without dividing by zero which seems to justify our implied sin.

Your belief is incorrect: many beginning students would not hesitate to find the solution x = t+3, but no competent mathematician would do so without qualification. Being sloppy like that is exactly why some students get incorrect answers to perfectly well-defined questions in areas like constrained optimization, for example. Often one encounters such equations---not as the result of 'trickery' or for the sake of trying to construct artificial difficulties---but as a natural outcome during the analysis of certain types of problems. Good software developers build in safeguards against such exceptional cases, thus avoiding the so-called 'bugs' that another poster has falsely claimed applies here.