RE: Suggestion for 2.5
- Posted by rforno at tutopia.com
Feb 20, 2003
Al:
L'Hôpital rule doesn't say inf/inf or 0/0 is indeterminate; this is an "a
priori" condition *previous* to applying l'Hôpital rule. This rule states
that, when you get an indeterminacy of this type, you can replace the
numerator and the denominator by their *derivatives* ("derivadas" in
Spanish. I don't know if it is the right word in English). The problem, when
crunching numbers, is that you usually don't know what the symbolic
derivatives of the terms are, nor how to compute them in case you knew the
symbolic form, nor how to otherwise compute their numeric value from the
data you have. If you have a method of doing this that can be applied to the
general case, it would be good for all of us that you explain how to perform
it.
To give an example, you might have Y/Z where both Y and Z are 0. Maybe you
have no other information about Y and Z, in which case you are stuck.
Maybe you know Y= X^2 and Z=X. Then, applying l'Hôpital rule, the derivative
of Y respect to X is 2*X, and the same for Z is 1, so 2*X/1 at X=0 gives 0,
which is the result you are seeking. But what to do if Y=T*X^2 and Z=T^2*X?
Should you take the derivative respect to T or respect to X? Each one gives
a different result, one infinite and the other 0, assuming you take them at
T=0 and X=0.
So, what I think is that applying l'Hôpital rule to number crunching is
usually beyond our possibilities. If you have the symbolic information, all
good and well (and even in this case you will have a lot of trouble
programming it), but if not, God save our souls...
Best regards.
----- Original Message -----
From: Al Getz <Xaxo at aol.com>
To: EUforum <EUforum at topica.com>
Sent: Wednesday, February 19, 2003 9:45 AM
Subject: RE: Suggestion for 2.5
>
> To Flag or Not to Flag
>
>
> Hello there rforno,
>
> I was sort of agreeing with you 
>
>
> >For example, (6/0)/(2/0) might be defined to give 1 as well
> >as 3, or any other number. You get an indisputable result only when the
> >zeroes are obtained by approximating to a limit, using L'hopital rule,
> >for
> >example. But this is calculus.
> Le Hopitals' Rule is *studied* in calculus, but that doesnt mean
> it's not applicable to programming. Lots of things studied in
> mathematics are used in programming including some not even
> directly involved in math crunching operations.
> One way of looking at it is that since the numbers in the
> denominator are always changing (as the program makes several
> passes) this whole system can be viewed as a limit problem,
> in which case Le Hopitals' Rule comes into great assistance in
> understanding how to handle the various numerical situations.
>
>
> >If you are merely crunching numbers and not
> >performing symbolic algebra, then (6/0)/(2/0) is the same as
> >(1/0)/(1/0),
> >since you cannot trace back the origins of the operands.
> >Some of these operations are completely reasonable, say 1/inf = 0. Some
> >others are questionable, say inf/inf = 1.
> Isnt it interesting that Le Hopitals' Rule shows that:
> 1/inf=0
> always, and:
> inf/inf
> as an indeterminate form? Hint, hint
> In other words, the ones that 'make sense' are not indeterminate forms,
> and the ones that do not 'make sense' are. By looking at this
> rule we can find out which ones are and which ones arent and
> build a good error handler.
>
> >However, if this suggestion is implemented as an option, when you have a
> >hard to find bug, you could revert to the current state of things in
> >order
> >to trace the bug. So, this would be only a convenience for certain type
> >of
> >processes. In a program I am writing, I use random numbers to a great
> >extent. I would prefer the computation to continue rather than stop,
> >since
> >the result is not very important: it is a game or something similar.
> "with halt_on_zero_division_error"
> sounds good to me
>
>
> Im sure you are well informed about this issue and after i've
> re-read my other post i can see it didnt really make the point
> clear...
>
> What i was suggesting is that Le Hopitals' Rule for indeterminate
> forms be used as a basis for deciding which errors get flagged and
> which errors return a value (even if that value is "inf")
> in order to obtain the most mathematically concise math handler
> possible.
> This means forms that ALWAYS 'make sense' will return a value, and
> forms that DONT ALWAYS 'make sense' will flag an error.
>
> In the longer haul, i can see that most of my programs will
> have to check for division by zero regardless of which
> method is used, including options to flag or not to flag.
> I dont see any way around it especially if an erroneous
> value was returned because it would make subsequent functions
> return utterly senseless and useless values anyway
>
>
> I hope this sheds some light on division by zero issues.
>
> Take care,
> Al
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
|
Not Categorized, Please Help
|
|
