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
|
Not Categorized, Please Help
|
|
