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

*To*: sebastian.egner@xxxxxxxxxxx*Subject*: LIMIT recommendations*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Thu, 16 Jun 2005 23:07:49 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <OF0CC71904.480D0773-ONC1257020.0026F3F1-C1257020.002AC54C@xxxxxxxxxxx> (message from Sebastian Egner on Tue, 14 Jun 2005 09:46:30 +0200)*References*: <OF0CC71904.480D0773-ONC1257020.0026F3F1-C1257020.002AC54C@xxxxxxxxxxx>

| 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 follow RATIONALIZE in section 6.2.5. 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?

**References**:**Re: [srfi-70] Limit***From:*Sebastian Egner

- Prev by Date:
**Re: infinities reformulated** - Next by Date:
**external representations** - Previous by thread:
**Re: [srfi-70] Limit** - Next by thread:
**Re: Re: [srfi-70] Limit** - Index(es):