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

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: comparison operators and *typos*From*: Paul Schlie <schlie@xxxxxxxxxxx>*Date*: Thu, 07 Jul 2005 10:46:31 -0400*Cc*: <srfi-70@xxxxxxxxxxxxxxxxx>*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050707031950.459A31B77B4@xxxxxxxxxxxxxxxx>*User-agent*: Microsoft-Entourage/11.1.0.040913

> | Date: Wed, 06 Jul 2005 13:55:40 -0400 > | From: Paul Schlie <schlie@xxxxxxxxxxx> > | > | 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.)

**Follow-Ups**:**Re: comparison operators and *typos***From:*Aubrey Jaffer

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

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