[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: limit function*From*: Paul Schlie <schlie@xxxxxxxxxxx>*Date*: Sun, 10 Jul 2005 12:17:06 -0400*Cc*: <srfi-70@xxxxxxxxxxxxxxxxx>*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050709022515.C74C61B77B4@xxxxxxxxxxxxxxxx>*User-agent*: Microsoft-Entourage/11.1.0.040913

> | > | 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..

**References**:**Re: comparison operators and *typos***From:*Aubrey Jaffer

- Prev by Date:
**Revision of SRFI 70 available** - Next by Date:
**Re: Nitpick with FLOOR etc.** - Previous by thread:
**Re: comparison operators and *typos** - Next by thread:
**Re: comparison operators and *typos** - Index(es):