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: comparison operators and *typos Paul Schlie 07 Jul 2005 14:46 UTC

>  | Date: Wed, 06 Jul 2005 13:55:40 -0400
>  | From: Paul Schlie <xxxxxx@comcast.net>
>  |
>  | As one last thought:
>  |
>  | If the default value of a function were defined as the average value of
>  | it's limits, then it may be reasonable to define a number system like:
>  |
>  |  -1.0 -10. -1/0   +1/0 +10. +1.0      -1.0 -10. -Inf   Inf 10. 1.0
>  |  -------------- 0 --------------  ::  -------------- 0 -----------
>  |  -1.0 -0.1 -0/1   +0/1 +0.1 +1.0      -1.0 -0.1 -0.0   0.0 0.1 1.0
>  |
>  | Where absolute zero is designated as 0, and who's reciprocal is 0, as
>  | the average value of it's -1/0 and +1/0 limits would be 0; as would 0/0,
>
> Then the FINITE? predicate becomes useless.

- so?

>  | and the difference of any two equivalent values, thereby eliminating the
>  | otherwise complexity and arguably negligible value of an inexact 0. i.e.:
>  |
>  | (= -0.0 0 +0.0) => #t, (< -0.0 0 +0.0) => #t, and (< -1/0 0 +1/0) => #t
>  |
>  | 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.
>
> Why do you feel compelled to turn LIMIT into a macro?

- no good reason, I was first thinking that explicitly wrapping an
  expression in a lambda wasn't necessary, then thought/agreed otherwise.

>  | Thereby hypothetically: (presuming sufficient numerical precision)
>  |
>  | (tan pi/2) => 0
>
> An exact zero?  That is just wrong.

- either one accepts that an inexact 0 represents the region inclusive of
  -0.0 and +0.0, or defines it as the region in between (which implies an
  inexact 0 is equivalent to an exact 0, thereby both represent a pure 0,
  where correspondingly infinities and their reciprocals may be expressed
  as ratio's of 0, thereby enabling a direct correspondence between exact
  and inexact values.

  and no more wrong than returning a completely useless value? (as it would
  at least represent the value at the intermediate point between it's
  limits, as opposed to nothing particularly useful)

>  | (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? Thereby
  it becomes unnecessary to know exactly the precision limit that a
  particular implementation is. (in fact it may even be simpler to
  define left-limit, and right-limit, and eliminate the specification
  of a delta value.)