Re: Arithmetic issues

["John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>]

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