1. RE: Suggestion for 2.5
Hello there,
rforno at tutopia.com wrote:
> Rob:
> When crunching numbers, sometimes one gets a "division by zero" error.
> In
> such cases, perhaps the useful thing to do is assign "infinite" to the
> result (I mean the IEEE standard infinite), so that if you use he result
> as
> a divisor, the new result will be zero. The following are the results
> for
> zero division I propose:
> 1 / 0 = inf
> -1 / 0 = -inf
> 0 / 0 = 1
> inf / 0 = inf
> -inf / 0 = -inf
> inf / inf = 1
> -inf / inf = -1
> inf / -inf = -1
> -inf / -inf = 1
> 1 / inf = 0
> -1 / inf = 0
> 1 / -inf = 0
> -1 / -inf = 0
>
> and the logical results for addition, subtraction and multiplication.
> Please correct me if I'm wrong: I think you are checking for a zero
> divisor
> *before* you perform the actual division, and so this proposal wont add
> any
> overhead in the case of a divisor being zero. I don't know how are you
> handling the case of infinite IEEE numbers. In any case, I'd avoid
> getting a
> nan (not a number) result.
> In order to be alerted of an error as soon as possible, like Eu does
> now, it
> would be useful to enable or not this variation by means of a *with* or
> *without* option, lets say: without zero_division.
> Regards.
>
>
Usually your math package has to check for these forms because
sometimes you cant truely determine the value from a division
like this. A good example is in the math library i had posted
a while back, in the file "MathLib.e", function "Angle()"
which i'll repeat here for convenience:
global function Angle(sequence X)
--full range trig function!
atom x,y,Ang
CalculationEnumeration=CalculationEnumeration+1
x=X[1] y=X[2]
if x=0 then
if y=0 then
SetMathLibErrorMessage("Indeterminate Angle() domain {0,0}")
Ang=0
else
if y<0 then
Ang=-PPi/2
else
Ang=PPi/2
end if
end if
else
Ang=arctan(y/x)
if x<0 then
if y<0 then
Ang=Ang-PPi
else
Ang=Ang+PPi
end if
end if
end if
return Ang
end function
Good luck with it,
Al
2. RE: Suggestion for 2.5
Hello again,
Carl W. wrote:
> rforno at tutopia.com wrote:
>
> > following are the results for zero division I propose:
> > 1 / 0 = inf
> > -1 / 0 = -inf
> > 0 / 0 = 1
> > inf / 0 = inf
> > -inf / 0 = -inf
> > inf / inf = 1
> > -inf / inf = -1
> > inf / -inf = -1
> > -inf / -inf = 1
> > 1 / inf = 0
> > -1 / inf = 0
> > 1 / -inf = 0
> > -1 / -inf = 0
>
> There's some inconsistency here:
>
> What's inf * 0? By your axioms here the answer is 1, but Euphoria
> currently
> returns 0 - without causing an error - when this calculation is done.
>
> What's 2/0? If it's inf again then when you remultiply the zero you
> should
> get 2, but you'll get 1.
>
> Also what's (6/0)/(2/0)? Euphoria would return 1, but that's not right -
> surely the answer should be 3?
>
> I can't say I haven't wanted similar functionality in the past, but this
> could be the cause of some extremely difficult to trace bugs.
>
> --
> [ Carl R White == aka () = The Domain of Cyrek = ]
> [ Cyrek the Illogical /\ www.cyreksoft.yorks.com ]
>
>
Hello again,
I cant help but agree to a certain extent.
These indeterminate forms need to be handled by the program
that uses them because they have application specific answers.
Note also the following:
Pass #1:
1/0 returns inf
Pass#2:
1/0.0000000001 returns a large positive number
Pass#3:
1/-0.0000000001 returns a large negitive number
This means it's not possible to say if 1/0 equals
plus or minus inf.
When we look slightly to the right of zero
(in the denominator) we get one sign, when we look
slightly to the left of zero we get another sign.
To get a better idea what this is all about, see
Le Hopitals' Rule for indeterminate forms
(do a search for this if you care to look into it).
There are some limits that do exist,
like: lim{sin(x)/x} as x approaches zero = 1,
but some of those forms are called "indeterminate forms"
because they have no real answer that covers every
possible circumstance.
Deeming one of the true indeterminate forms as either plus
or minus inf (or anything else really) would cause
the program to sometimes return the
wrong answer for applications that calculate denominators
close to and including zero. The program would end up
'preferring' either plus or minus inf as the answer, at
the very least 
Good luck with it,
Al
3. RE: Suggestion for 2.5
- Posted by rforno at tutopia.com
Feb 19, 2003
I know that. When you allow operations with infinite, you get
inconsistencies. 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. 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. The final result, for example
after inverting a matrix, may be right or wrong or, more probably, off in
some proportion. The same can happen with the current specifications in the
absence of infinite quantities, when dealing with badly-behaved matrices,
and in such a case, no zero-division will ever be reported.
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.
Regards.
----- Original Message -----
From: Carl W. <euphoria at cyreksoft.yorks.com>
To: EUforum <EUforum at topica.com>
Sent: Tuesday, February 18, 2003 7:34 AM
Subject: Re: Suggestion for 2.5
>
> rforno at tutopia.com wrote:
>
> > following are the results for zero division I propose:
> > 1 / 0 = inf
> > -1 / 0 = -inf
> > 0 / 0 = 1
> > inf / 0 = inf
> > -inf / 0 = -inf
> > inf / inf = 1
> > -inf / inf = -1
> > inf / -inf = -1
> > -inf / -inf = 1
> > 1 / inf = 0
> > -1 / inf = 0
> > 1 / -inf = 0
> > -1 / -inf = 0
>
> There's some inconsistency here:
>
> What's inf * 0? By your axioms here the answer is 1, but Euphoria
currently
> returns 0 - without causing an error - when this calculation is done.
>
> What's 2/0? If it's inf again then when you remultiply the zero you should
> get 2, but you'll get 1.
>
> Also what's (6/0)/(2/0)? Euphoria would return 1, but that's not right -
> surely the answer should be 3?
>
> I can't say I haven't wanted similar functionality in the past, but this
> could be the cause of some extremely difficult to trace bugs.
>
> --
> [ Carl R White == aka () = The Domain of Cyrek = ]
> [ Cyrek the Illogical /\ www.cyreksoft.yorks.com ]
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
4. 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
5. 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!
>
6. RE: Suggestion for 2.5
In response to a previous post (rforno)that had said that L'H Rule isnt
really needed:
Your right, in that L'H Rule isnt in itself needed as long as
you can determine what an 'indeterminate form' is beforehand.
A better way of stating this is that the 'theory of limits'
helps in understanding what forms should return a value
and what forms you might want to have flag an error.
Ive jumped ahead and started to identify all the possible forms
that can be encountered in an attempt to cover all the bases.
This list should cover all the indeterminate forms as well
as forms that have a simple answer and can return a definite
result that will be true for any possible case that can
ever be encountered.
To help identify all the possible forms:
Specify three possible 'values': n, 0, or inf
with two possible signs: + or - (except zero, which has no sign)
with the restriction that n is never equal to zero or inf,
and n is always positive.
Each form is identified by generating all possible
combinations of the three possible values n, 0, and inf, and
their allowed signs for every built in function available such
as addition, subtraction, multiplication, etc.
Not shown are combinations for log and trig functions,
which would also have to be taken into consideration.
Also, perhaps it would be a good idea to identify every
possible order as well, because a program doesnt understand
that 0*n is the same as n*0 unless you program that in too.
--------------------------------
Division group
n/inf
n/-inf
-n/inf
-n/-inf
n/0
-n/0
0/inf
0/-inf
0/n
0/-n
inf/n
-inf/n
inf/-n
-inf/-n
inf/0
-inf/0
inf/inf
-inf/inf
inf/-inf
-inf/-inf
0/0
---------------------------------
Multiplicative group
n*inf
-n*inf
n*-inf
-n*-inf
0*inf
0*-inf
inf*inf
-inf*inf
--------------------------------
Exponential group
n^0
-n^0
n^inf
n^-inf
(-n)^inf
(-n)^-inf
0^inf
0^-inf
0^n
0^-n
inf^n
inf^-n
(-inf)^n
(-inf)^-n
inf^inf
inf^-inf
(-inf)^inf
(-inf)^-inf
inf^0
(-inf)^0
0^0
------------------------------
Additive group
n+inf
n+(-inf)
(-n)+inf
(-n)+inf
n+0
(-n)+0
0+inf
0+(-inf)
0+0
----------------------------------
Subtractive group
n-inf
n-(-inf)
(-n)-inf
(-n)-inf
n-0
(-n)-0
0-n
0-(-n)
0-inf
0-(-inf)
inf-0
-inf-0
0-0
--------------------------------------
The testing phase would have to determine what type of operands were
present (of the three: n, inf, or zero) and their signs, as well as
the operation being performed. From this it can be determined if it
is an indeterminate form, and if so, what to do about it. If it's not,
a result is returned. The only problem is all this testing is
going to slow down the basic math functions, and that's really not
a good idea at all.
Math operations on the Pentium class processor are quite fast, even
doing floating point operations. It's very easy to double the time
spent doing a math operation by introducing various pre-op tests.
Double the time spent in the fundamental math operations and you have
effectively sent your users computer back 2 years, or alternately
quartered the value of their computer.
Testing at the machine level would of course be faster then anything
else, but if it didnt accomplish what it set out to do for most of
the possible applications it would be a wasted effort.
Since it's not possible to determine what type of code will be run
on the users machine, the only way to go would be to present the
user with a host of presettable options that can also be changed
at any time by the users program.
One nice way around this might be to have an array of default values
poked into memory. If the users decide to change these, they can
alter the return values from indeterminate operations. If not, they
get the default values.
Another solution might be a built in call back function, that gets
called whenever an indeterminate form was reached by an operation.
The call back args could include the identification constant for
the type of operation (multiply, divide, etc).
The user can then branch on whatever function was encountered and
set the return value. This would probably be slower then the array
solution though.
I could have missed some forms also, can you find any more?
Note also that for some forms such as 0^0
the answer isnt that apparent without referring to the precise
mathematical definition of raising a number to a power...
It's not really true that "every number raised to the zero power
equals 1".
For
y=x^k
y=x*x*x*x... (k-1 multiplications)
but for
y=x^0
x cannot be equal to zero.
This means
0^0
has no answer, because it's undefined.
In other words, raising a number to the zero power equals 1, unless
that number is also equal to zero, in which case the answer is
undefined.
Another way of stating this is that if you were to graph the function
y=x^0
for x ranging over these seven values: {-3,-2,-1,0,1,2,3}
you cant put a dot on the "y" axis at a value of 1 because
this value isnt correct. For values of x very close to
zero (like 0.000001) you still get a value of y equal to
1, but exactly at x=0 the result is not defined.
There are lots of functions that are undefined at some
particular points so this shouldnt be that much of
a surprise to anybody.
Take care for now,
Al
