[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Arithmetic issues
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
> Should the binary fixnum/flonum operations allow other than two
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?
> 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
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