# Re: comparison operators and *typos

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.

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

| Thereby hypothetically: (presuming sufficient numerical precision)
|
| (tan pi/2) => 0

An exact zero?  That is just wrong.

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