This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
> | 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.)