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

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

*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):