# LIMIT recommendations

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.

``` | From: Sebastian Egner <sebastian.egner@xxxxxxxxxxx>
| Date: Tue, 14 Jun 2005 09:46:30 +0200
|
| Aubrey Jaffer wrote:
|
| > Function: limit proc x1 x2 k
| > Function: limit proc x1 x2
| >
| >     ...
|
| The specification and implementation of LIMIT has really improved a
| lot.  Good work!  So LIMIT is now specified as a certain extrapolation
| algorithm using the points (x, f(x1 + x2/k)), k in {1..d}.
|
| Although I still have doubts that this functionality should go into
| the core of a general purpose programming language (for many programs
| it might not be relevant and it's also not essential for portability)
| this operation is certainly a reasonably well-defined numerical
| algorithm.

In the current version of SRFI-70 I removed the requirement for the
LIMIT procedure; changing it to a "library procedure".  As LIMIT has
developed, it no longer has platform dependencies.  It is most similar
to RATIONALIZE among Scheme procedures; so I moved its description to

Choices for its disposition are:

[a] LIMIT is a library procedure
[b] LIMIT is an optional procedure
[c] LIMIT is removed from SRFI-70

Choices for infinity notation are:

[d] 1/0, -1/0, 0/0
[e] 1/0., -1/0., 0/0.
[f] #i1/0, #i-1/0, #i0/0

Choices for (/ 0 0) are:

[g] (/ 0 0) is an error (implementations are not constrained)
[h] (/ 0 0) behavior is unspecified (must not signal error)
[i] (/ 0 0) returns 0/0 or signals an error

Choices for (expt 0 0) are:

[j] (expt 0 0) returns 1
[k] (expt 0 0) is an error (implementations are not constrained)
[l] (expt 0 0) behavior is unspecified (must not signal error)
[m] (expt 0 0) returns 0/0 or signals an error

What do you (all) recommend on these 4 issues?

```