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

*To*: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*Subject*: Re: Arithmetic issues*From*: "John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>*Date*: Tue, 18 Oct 2005 13:36:39 -0400*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9lzmp775oz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*References*: <y9lzmp775oz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>*User-agent*: Mutt/1.4.2.1i

Michael Sperber scripsit: > Now, the Issues section in the SRFI is pretty long. We were hoping to > get some feedback on where people stand on these issues, so it'd be > great if you could see it as some kind of questionnaire and just fire > off your position on the issues where you have one. Aaaaaaas you wiiiiiish. > Instead of requiring the full numeric tower, R6RS could require > only the fixnum/flonum base, and make the full tower available as > modules in the standard library. I agree with this. > The main problem with banishing the full tower to a library is > that read, write, and several other procedures must know about > the external representations of all numbers. I don't see this as a significant problem. Chicken, for example, works exactly this way: by default you get only fixnums and flonums, and inputs that can't be interpreted as one or the other signal an error. If you (use number), you get the full tower; this redefines only the predicates of R5RS section 2.2 plus eqv? and equal?. Read and write are written to make use of the numeric procedures as appropriate. > Should a minimum precision be required for fixnums or flonums? I think that it would be safe and suitable to require the largest fixnum to be at least 2^23 - 1 and the most negative fixnum to be at most -(2^23). Flonums should be allowed to follow the hardware architecture, with appropriate standard procedures provided to determine what that architecture may be. > Should the range of a fixnum be restricted to a power of two? To > a two's complement range? Yes. All other machine architectures are dead. > The fixnum operations provide efficient fixnums that "wrap." However, > they do not give efficient access to the hardware facilities for carry > and overflow. This would be desirable to implement efficient generic > arithmetic on fixnums portably. On the other hand, there isn't much > experience with formulating a portable interface to these facilities. I'm neutral on this point. > The fixnum operators wrap on overflow, i.e., they perform modular > arithmetic. For many purposes, it would be better for them to signal > an error in safe mode. [...] They should signal an error rather than wrap; wrapping is not useful in portable code. > Should the binary fixnum/flonum operations allow other than two > arguments? No. Since neither fixnum nor flonum operations are associative, we shouldn't pretend that they are by enforcing left-associativity. > What are the semantics of "safe mode" and "unsafe mode"? (This is > a much larger question that R6RS should address.) I agree with other posters that a global mode is a bad idea. > Should R6RS allow other inexact reals beside the flonums? This > draft does allow them, at the cost of some complications and > additions such as real->flonum. (See the Design Rationale.) Yes. IEEE is in the process of defining representations and operations on arbitrary-precision base-10 floating-point numbers. Scheme should not exclude them, particularly if they are someday provided in hardware as IEEE fixed-precision floats now are. > 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 don't see how we can split the difference between contagious inexactness (option 4) and contagious exactness (option 5). Both lead to unexpected results on occasion. I therefore favor option 3. > If R6RS does not adopt a R5RS-style model for the generic arithmetic, > should it still provide more R5RS-compatible generic arithmetic as > a library? Maybe. > The external representations of 0.0, -0.0, infinities and NaNs must be > specified. The notations used here are used by several other languages, > and have been adopted by several implementations of Scheme, but other > notations are possible. I'm happy with them. > The fixnum, flonum, and inexact arithmetic come with a full deck of > operations, including some that are defined in terms of integers (such > as quotient+remainder, gcd and lcm), and others that are easily abused > (such as fxabs). Should these be pruned? Yes, absolutely. (I'm not clear what the problem with fxabs might be.) > Given that this SRFI suggests requiring all implementations to > support the general complex numbers, should abs (and exabs and > inabs) be removed? At least abs should be retained for backward compatibility. > 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.) Does this problem go away if complex numbers of mixed exactness are disallowed? I think that in effect a mixed-exactness complex number is inexact, and so 0+0.0i should be treated as a synonym for 0.0+0.0i. > 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? I don't see a need to mandate the representation; R6RS can talk *as if* such a representation existed, while allowing other representations if they do not affect the user-visible behavior (other than performance) of any standard procedures. I think we should adopt the CL branch cuts as-is. They may not be perfect, but there are no obvious competitors. > Should `(floor +inf.0)' return +inf.0 or signal an error > instead? (Similarly for ceiling, flfloor, infloor, etc.) I'm neutral on this one. > The bitwise operations operate on exact integers only. Should they live > in the section on exact arithmetic? Should they carry ex prefixes? Or > should they be extended to work on inexact integers as well? They should live in the section on exact arithmetic; no prefixes are required; they should *not* be extended to inexact integers. > The division between regular procedures and library procedures is > somewhat arbitrary. It is no worse than R5RS on that score. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall http://www.reutershealth.com buy a piece of the rope for a keepsake. jcowan@xxxxxxxxxxxxxxxxx

**Follow-Ups**:**Re: Arithmetic issues***From:*Aubrey Jaffer

**Re: Arithmetic issues***From:*Per Bothner

**References**:**Arithmetic issues***From:*Michael Sperber

- Prev by Date:
**Re: Arithmetic issues - feedback** - Next by Date:
**Re: Arithmetic issues - feedback** - Previous by thread:
**Re: Arithmetic issues** - Next by thread:
**Re: Arithmetic issues** - Index(es):