RE: Suggestion for 2.5
- Posted by Al Getz <Xaxo at aol.com> Feb 21, 2003
- 429 views
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