I thank the authors of this proposal for their work. I'm not entirely sure that I understand the the thrust of this proposal, or fully comprehend what this proposal encompasses, but I would like to go through it carefully and propose certain questions and comments. > Should the R5RS procedures for generic arithmetic (e.g. +) remain in R6RS? Here are five possible answers, phrased in terms of the + procedure: > > 1. + is not defined in R6RS. > 2. + is defined to be a synonym for the ex+, so its domain is restricted to exact arguments, and always returns an exact result. > 3. + is defined as the union of the ex+ and in+ procedures, so all of its arguments are required to have the same exactness, and the exactness of its result is the same as the exactness of its arguments. > 4. + is defined as in R5RS, but with the increased portability provided by requiring the full numeric tower. This alternative is described in the section R5RS-style Generic Arithmetic. > 5. + is defined to return an exact result in all cases, even if one or more of its arguments is inexact. This alternative is described in the section Generic Exact Arithmetic. > > Will Clinger prefers the 4th possibility, Mike Sperber the 5th. I have real difficulties with 5, which I hope to expand on at a later time. Part of the problem is that 5 assumes that inexact->exact gives reasonable results on inexact arguments, and I can't see how this can be true if, for example, inexacts are implemented as the computable reals. > The real?, rational?, and integer? predicates must return false for complex numbers with an imaginary part of inexact zero, as non- realness is now contagious. This causes possibly unexpected behavior: `(zero? 0+0.0i)' returns true despite `(integer? 0+0.0i)' returning false. Possibly, new predicates realistic?, rationalistic?, and integral? should be added to say that a number can be coerced to the specified type (and back) without loss. (See the Design Rationale.) I don't like the word contagious; I cannot think of a rigorous definition in many contexts (including this one). > Most Scheme implementations represent an inexact complex number as a pair of two inexact reals, representing the real and imaginary parts of the number, respectively. Should R6RS mandate the presence of such a representation (while allowing additional alternative representations), thus allowing it to more meaningfully discuss semantic issues such as branch cuts? Yes. > Should `(floor +inf.0)' return +inf.0 or signal an error instead? (Similarly for ceiling, flfloor, infloor, etc.) It should *be* an error, whether it should *signal* an error is another matter. > The bitwise operations operate on exact integers only. Should they live in the section on exact arithmetic? I don't see this as an important issue? > Should they carry ex prefixes? no. > Or should they be extended to work on inexact integers as well? Just exact integers. > +nan.0 represents the result of (/ 0.0 0.0), and may represent other NaNs as well. (This SRFI does not require read/write invariance for NaNs.) OK, but writing a NaN should give whatever info is in the significand. There seems to be no way to get that information using Scheme procedures described in this document. Basically, I believe that the programming languages "Scheme", which we can specify, should "play well with others", where "others" include hardware and OS runtime libraries, which are specified either by hardware companies, or by other standards bodies. The hardware and runtime libraries of different systems generate different NaNs, and if we're going to go to this amount of trouble to add what I hope will be useful flonum arithmetic to Scheme, some way should be provided in Scheme to distinguish NaNs that are different (in their precision, range, or mantissa, i.e., according to the IEEE standard) and to determine whether two are the same. > Implementations that use binary floating point representations of real numbers should represent x|p using a p-bit significand if practical, or by a greater precision if a p-bit significand is not practical, or by the largest available precision if p or more bits of significand is not practical within the implementation. > > Note: The precision of a significand should not be confused with the number of bits used to represent the significand. In the IEEE floating point standards, for example, the significand's most significant bit is implicit in single and double precision but is explicit in extended precision. Whether that bit is implicit or explicit does not affect the mathematical precision. In implementations that use binary floating point, the default precision can be calculated by calling the following procedure: > > (define (precision) > (do ((n 0 (+ n 1)) > (x 1.0 (/ x 2.0))) > ((= 1.0 (+ 1.0 x)) n))) > > Note: When the underlying floating-point representation is IEEE double precision, the |p suffix should not be omitted for all cases: Denormalized numbers have diminished precision, and therefore should carry a |p suffix with the actual width of the signficand. It seems ironic to me that this program itself assumes generic arithmetic. It is not clear to me how, under this proposal, a Scheme will implement floating-point arithmetic with more than one precision. This is an important part of some numerical algorithms (iterative refinement in solving linear systems, for example). The first paragraph seems to make the |p notation meaningless; it seems to specify nothing about the relationship between p and the precision of the resulting flonum. > Implementations are not required to use floating-point representations, but every implementation is required to designate a subset of its inexact reals as flonums, and to convert certain external representations into flonums. What does this mean? In particular, can this subset be empty? Is that what "Implementations are not required to use floating-point representations" means? > If a <decimal 10> does not contain a non-empty <mantissa width> and does not contain one of the exponent markers s, f, d, or l, but does contain a decimal point or the exponent marker e, then it is an external representation for a flonum. Furthermore inf.0, +inf. 0, -inf.0, nan.0, +nan.0, and -nan.0 are external representations for flonums. Some or all of the other external representations for inexact reals may also represent flonums, but that is not required by this SRFI. > > If a <decimal 10> contains a non-empty <mantissa width> or one of the exponent markers s, f, d, or l, then it represents an inexact number, but does not necessarily represent a flonum. Wow; what does this mean? The difference between flonums and inexacts is confusing to me. (Sorry for "surfer dude" mode here.) > Safe and Unsafe Mode > This SRFI allows a Scheme implementation to run code in one of two global modes: "safe" and "unsafe" mode. These affect the fixnum and the flonum operations. In safe mode, these operations must check that their arguments are actually fixnums or flonums respectively, or perform possible additional checking as required by the specifications of the operations. In unsafe mode, these operations must provide no such checking. This distinction allows an implementation to generate efficient numerical code at the cost of avoiding run-time checking. The R6RS should require a Scheme implementation to provide the safe mode. I presume a Scheme "implementation" may include a compiler. I can't imagine that the requirement that "In unsafe mode, these operations must provide no such checking" means that a compiler cannot use dataflow and control flow information to signal an error in code, rather than compiling it to nonsense and deliberately crashing a program. > Equivalence of Objects > > The R6RS specification of eqv? for numbers should be changed as follows. > > The eqv? procedure returns #t if: > > * obj1 and obj2 are both exact numbers, and are numerically equal (see =, section see section 6.2 Numbers). > * obj1 and obj2 are both inexact numbers, are numerically equal (see =, section see section 6.2 Numbers), and yield the same results (in the sense of eqv?) when passed as arguments to any other procedure that can be defined as a finite composition of Scheme's standard arithmetic procedures. > > The eqv? procedure returns #f if: > > * one of obj1 and obj2 is an exact number but the other is an inexact number. > * obj1 and obj2 are numbers for which the = procedure returns #f. > * obj1 and obj2 yield different results (in the sense of eqv?) when passed as arguments to any other procedure that can be defined as a finite composition of Scheme's standard arithmetic procedures. First, I presume that ", or" should be added to the end of the first item of the first list and to the ends of the first and second items of the second list. OK, I just went through the whole document and checked for every instance of = and could not find out whether (let ((x (/ 0. 0.))) (= x x)) returns #t or #f. It is not useful for it to return #t if IEEE arithmetic is the underlying inexact representation and "=" means "IEEE arithmetic =". So a definition of eqv? in terms of = seems incomplete. (Or does = mean fl= here?) The definition of eqv? is recursive for inexact numbers, and I don't see where the recursion is based. If we're going to go to all this trouble to insert flonums (and I presume the main motivation is to have IEEE flonums) into Scheme, we should add the inquiry functions of the IEEE standard (which I can't look up at the moment, because it's not online) that return various properties of the part of an IEEE flonum. > Numerical Type Predicates > ... > Note: The behavior of these type predicates on inexact numbers is unreliable, because any inaccuracy may affect the result. Couldy you explain this statement? Or give an example? > Integer Division > ... Why div+mod for reals and quotient+remainder for exact integers? I'm losing it a bit; are the procedures in this section defined for inexact numbers? If so, then the requirement for div+mod that x1 = nd * x2 + xm. may not be realizable due to precision issues; perhaps a proof is needed here? The requirement that the sign of the second argument acts as a selector to decide what function div+mod computes seems to give extra meaning to (negate y) that should not be there. > Fixnums > ... > Every implementation must define its fixnum range as a closed interval [lo, hi] such that lo and hi are (mathematical) integers with lo <= 0 < 1 <= hi. Every mathematical integer within an implementation's fixnum range must correspond to an exact integer that is representable within the implementation. The fixnum operations of an implementation will perform arithmetic modulo hi-lo+1. In mathematics, "arithmetic modulo hi-lo+1" means that results go from 0 to hi-lo; I can't imagine that this is what is wanted here. As a practical matter, signed integer arithmetic on all modern processors wraps, so that hardware-signed-+ (2^31-1) 1 => - 2^31, yet the C standard says that such behavior is undefined. The C standard does require that *unsigned* arithmetic wraps hardware-unsigned-+ (2^32-1) 1 => 0 which is probably the reason why hardware signed arithemtic wraps the way it does (so the processor can use a single + operation for both signed and unsigned arithmetic). > <definition of many operations that naturally can take multiple arguments to take only two arguments> Let's let the interpreter or compiler worry about doing the folding of these operations; I don't see any reason to require the programmer to do it by hand. > library procedure: fxabs fx > This procedure returns `(fx- 0 fx)' if fx is negative, fx otherwise. So, do you want (fxabs least-fixnum) ==> least-fixnum which is what this specifies? > procedure: fxdiv+mod fx1 fx2 > library procedure: fxdiv fx1 fx2 > library procedure: fxmod fx1 fx2 > library procedure: fxquotient fx1 fx2 > library procedure: fxmodulo+remainder fx1 fx2 > library procedure: fxmodulo fx1 fx2 > library procedure: fxremainder fx1 fx2 > > These procedures implement number-theoretic integer division modulo hi-lo+1. See the section on Integer Division. This seems to be a laundry list of ad-hoc, incompletely specified procedures. I really don't know what you mean by these. > procedure: fxbitwise-not fx > Returns the fixnum which is the one's-complement of its argument. congruent mod hi-lo+1. I believe it should be "ones-complement" and that the "congruent mod hi-lo+1" is unnecessary. > procedure: fxarithmetic-shift fx1 fx2 > This procedure conceptually shifts the two's complement representation of fx1 fx2 bits left when fx2 > 0, and -fx2 bits right when fx2 < 0, extending the sign. (It returns fx1 when fx2 = 0.) It returns the result of that shift congruent mod hi-lo+1. Do you mean "(eq? fx1 (fxarithmetic-shift fx1 0))"? > procedure: fl= fl1 fl2 > procedure: fl< fl1 fl2 > procedure: fl<= fl1 fl2 > procedure: fl> fl1 fl2 > procedure: fl>= fl1 fl2 > > These procedures return #t if their arguments are (respectively): equal, monotonically increasing, monotonically decreasing, monotonically nondecreasing, or monotonically nonincreasing, #f otherwise. These predicates are required to be transitive. > > (fl= +inf.0 +inf.0) ==> #t > (fl= -inf.0 +inf.0) ==> #f > (fl= -inf.0 -inf.0) ==> #t > (fl= 0.0 -0.0) ==> unspecified > (fl< 0.0 -0.0) ==> unspecified > (fl= +nan.0 fl) ==> unspecified > (fl= +nan.0 fl) ==> unspecified > (fl< +nan.0 fl) ==> unspecified > > The following behavior is strongly recommended but not required by R6RS: > (fl= 0.0 -0.0) ==> #t > (fl< -0.0 0.0) ==> #f > (fl= +nan.0 +nan.0) ==> #f > > procedure: flinteger? fl > procedure: flzero? fl > procedure: flpositive? fl > procedure: flnegative? fl > procedure: flodd? ifl > procedure: fleven? ifl > procedure: flnan? fl > These numerical predicates test a flonum for a particular property, returning #t or #f. Flinteger? tests it if the number is an integer, flzero? tests if it is fl= to zero, flpositive? tests if it is greater than zero, flnegative? tests if it is less than zero, flodd? tests if it is odd, fleven? tests if it is even, flnan? tests if it is a NaN. > > (flnegative? -0.0) ==> #f > > Note: `(flnegative? -0.0)' must return #f, else it would lose the correspondence with (fl< -0.0 0.0), which is #f according to the IEEE standards. > > procedure: flmax fl1 fl2 > procedure: flmin fl1 fl2 > > These procedures return the maximum or minimum of their arguments. > > procedure: fl+ fl1 fl2 procedure: fl- fl1 fl2 > procedure: fl* fl1 fl2 procedure: fl/ fl1 fl2 > > These procedures return the flonum sum, difference, product, or quotient of their flonum arguments. In general, they should return the flonum that best approximates the mathematical sum, difference, or quotient of their arguments. (For implementations that represent flonums as IEEE binary floating point numbers, the meaning of "best" is reasonably well-defined by the IEEE standards.) > > For undefined quotients, fl/ behaves as specified by the IEEE standards: > > (fl/ 1.0 0.0) ==> +inf.0 > (fl/ -1.0 0.0) ==> -inf.0 > (fl/ 0.0 0.0) ==> +nan.0 I realize that "A foolish consistency is the hobgoblin of little minds", but why in heaven's name do you justify some requirement by saying "we must follow IEEE arithmetic" and at the same time totally disregard other IEEE arithmetic requirments? Either implement the IEEE spec for floating point arithmetic in Scheme flonum arithmetic or forget it. > library procedure: flnumerator fl > library procedure: fldenominator fl > > These procedures return the numerator or denominator of their argument as a flonum; the result is computed as if the argument was represented as a fraction in lowest terms. The denominator is always positive. The denominator of 0 is defined to be 1. > > (flnumerator +inf.0) ==> +inf.0 > (flnumerator -inf.0) ==> -inf.0 > (fldenominator +inf.0) ==> 1.0 > (fldenominator -inf.0) ==> 1.0 > (flnumerator 0.75) ==> 3.0 ; example > (fldenominator 0.75) ==> 4.0 ; example > > The following behavior is strongly recommended but not required by R6RS: > > (flnumerator -0.0) ==> -0.0 If +inf.0 and +nan.o are not rational, I don't think it is reasonable for them to be in the domain of flnumerator and fldenominator. > procedure: flsqrt fl > > Returns the principal square root of z. For a negative argument, the result may be +nan.0, or may be some meaningless flonum. With flexp and fllog defined as above, the value of `(flsqrt fl)' is defined as `(flexp (fl/ (fllog fl) 2.0))'. Aren't the last two statements contradictory? As a general question---why define the flonum versions of the elementary functions to possibly return complex arguments rather than to have restricted ranges or to return NaNs for arguments that would not give a real result? If the goal of adding flonum arithmetic is speed, why define these functions in such a way that the built-in hardware or OS runtime library routines cannot be used directly? > procedure: flexpt fl1 fl2 > > Returns fl1 raised to the power fl2. For nonzero fl1 > > fl1^fl2 = e^(z2 log z1) > > 0^fl is 1 if z = 0, and 0 if fl is positive. Otherwise, the result may be +nan.0, or may be some meaningless flonum. I take it z2 should be fl2 and z1 should be fl1, and z should be f1. Does the "0" here mean "0.0"? Does the "1" here refer to "1.0"? (Similar questions arise for insqrt.) Enough for now. The paper [Egner et al. 2004] Sebastian Egner, Richard Kelsey, Michael Sperber. Cleaning up the tower: Numbers in Scheme. In Proceedings of the Fifth ACM SIGPLAN Workshop on Scheme and Functional Programming, pages 109--120, September 22, 2004, Snowbird, Utah. Technical report TR600, Computer Science Department, Indiana University is cited as justification for several parts of this proposal. Unfortunately, I believe this paper to be seriously flawed. I'm bringing this up for the following reason: I don't believe that this paper can be used, by itself, as justification for any aspect of this proposal. It may be used as an *argument* for certain aspects of the proposal, but as there has been no general discussion of the merits of the paper, either in this forum or in others, I don't believe that it can be used as "settled decisions". Thus, if the authors of this SRFI wish to use arguments from that paper as justification for certain aspects of *this* proposal, they should repeat those arguments here for them to be discussed and debated as usual. Brad
