RE: Suggestion for 2.5

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu