Re: comparison operators and *typos Paul Schlie (06 Jul 2005 17:55 UTC)
Re: comparison operators and *typos Aubrey Jaffer (07 Jul 2005 03:19 UTC)
Re: comparison operators and *typos Paul Schlie (07 Jul 2005 14:46 UTC)
Re: comparison operators and *typos Aubrey Jaffer (09 Jul 2005 02:24 UTC)
Re: limit function Paul Schlie (10 Jul 2005 16:17 UTC)
Re: comparison operators and *typos bear (07 Jul 2005 15:35 UTC)

Re: limit function Paul Schlie 10 Jul 2005 16:17 UTC

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