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