> | > | Thereby all functions will be legitimately valued at all points
> | > | with no need of ambiguous value representation, however who's
> | > | value may be more precisely determined at a specific limit through
> | > | the use of a limit macro as desired.
> | > |
> | > | Thereby hypothetically: (presuming sufficient numerical precision)
> | > |
> | > | (tan pi/2) => 0
> | > | (limit (lambda (x) (tan x)) (pi/2 -0/1)) => +1/0
> | > | (limit (lambda (x) (tan x)) (pi/2 +0/1)) => -1/0
> | > |
> | > | (+ 4. (/ (abs 0) 0)) => 4.0
> | > | (limit (lambda (x) (+ 4. (/ (abs x) x))) (0 -0/1)) => 3.0
> | > | (limit (lambda (x) (+ 4. (/ (abs x) x))) (0 +0/1)) => 5.0
> | >
> | > LIMIT already handles these cases correctly. But I am unconvinced
> | > that a procedure can automatically pick the evaluation points given
> | > no information about the test function.
> |
> | - it seems fairly straight foreword to for +-0/1 to imply the use
> | of the smallest value representable by an implementation as the
> | delta value in it's calculation of a limit value its argument's
> | value?
>
> That doesn't work in general. Intermediate quantities in a
> calculation can overflow or underflow if the delta is too small.
>
> (define (func x) (expt (+ (/ x) (exp (/ x)) (exp (/ 2 x))) x))
>
> ;;The mathematically correct answer is e^2 = 7.3890560989306504:
>
> (limit func 0 1/40) ==> 7.3890560989306504
> (limit func 0 1/41) ==> #i0/0
> (limit func 0 1/42) ==> #f
> (limit func 0 1/43) ==> #i+/0
> (limit func 0 1/444) ==> #i+/0
> (limit func 0 1e-323) ==> #i+/0
- Yup. However, I don't believe attempting to guess haphazardly, as
implied is required using the proposed limit function, is reasonable.
Given that the precision about any value is known in a given inexact
implementation, and correspondingly so is the resolvable domain of all
primitive functions; it seems reasonable to define a macro that is able
to determine the delta about an arbitrary point given an arbitrary
composite function, which represents the minimum deviation about that
point which should not corrupt the result due to a intermediate overflow
if possible.
Possibly something along the line of [using macro's as the expression
argument needs to be parsed to determine it's reverse operation order]:
(delta <expression> (<variable> <value>)) => <min-delta-value>
Such that hypothetically:
(delta- a (b c)) :: (- c (delta a (b c))
(delta+ a (b c)) :: (+ c (delta a (b c))
(delta x (x 0)) :: (* (+ (abs x) 1e-290) 1e-10)) => 1e-300
(delta (exp (/ x)) (x 0)) :: (/ (abs (log (delta x (x 0)))) => 0.00145..
...
Where then:
(limit <expression> (<variable> <value>)) => <mean-limit>
(limit- <expression> (<variable> <value>)) => <lower-limit>
(limit+ <expression> (<variable> <value>)) => <upper-limit>
may compute the limit by automatically deriving a delta based upon
the composite expression directly. Where if given for example:
(expt (exp (/ x)) x) ; which otherwise yields +inf at 0, due to overflow.
It's lower (and/or upper or mean) limit may then be accurately computed:
(limit- (expt (exp (/ x)) x) (x 0)) ::
(let ((x (delta- (expt (exp (/ x)) x) (x 0))))) (expt (exp (/ x)) x)) ::
(let ((x -0.00145..)) (expt (exp (/ x)) x)) => 2.718..