Re: Arithmetic issues

[bear <bear@xxxxxxxxx>]

On Mon, 17 Oct 2005, Michael Sperber wrote:


> 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.  You don't
> have to bother with a rationale.  (But of course rationales are
> always appreciated.)

Okay.  now I can do the rest...

> 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?

I wouldn't have a problem with that, but I guess the questions are how
much to provide natively and how much to leave to libraries, and how
to treat or signal errors.  Those are tough questions.

If we intend for scheme systems to maintain the ability to be small
and simple, then basic fixnum/flonum operations seem like the right
thing to leave in the core language.  But that will give errors
(either signalled errors, or "returned errors" like infinities, or
"silent" errors like wraparounds) for a lot of operations that are no
longer errors when the various math libraries (cf. bignums,
extended-floats) get loaded.  How exactly should we treat those errors
in the base language?

Similarly, a series expansion in the base language that uses flonums
could easily give an "out-of-memory" error or make the system
cripplingly slow when math libraries (cf. infinite-precision
rationals) are loaded.

> 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

It is more important that R6RS pick something than it is what exactly
they pick.  Seriously, just make a decision that's not grotesquely
verbose (nothing over, say, ten characters long) and doesn't get
confused with an identifier, and I won't object.

> 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?

No need for that, but they should be placed in libraries as extensions.

> The R5RS says this:
> Rationale: Magnitude is the same as abs for a real argument, but abs
> must be present in all implementations, whereas magnitude need only
> be present in implementations that support general complex numbers.

> Given that this SRFI suggests requiring all implementations to
> support the general complex numbers, should abs (and exabs and
> inabs) be removed?

I don't think that is reasonable.  I'd move them (and magnitude) to
libraries, but not remove them.

> 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.)

If something can be coerced to real, rational, or integer without loss
of information, I think those predicates should return true.  A
complex number with an inexact part is simply an inexact number, and
if its imaginary part is zero, can be coerced to an inexact number of
some other type without loss of information.

> 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 think branch cuts can be meaningfully discussed without mandating
the presence of a cartesian representation.  Or, to the point
considering the most common alternative, polar representation would
facilitate the discussion of branch cuts just as much.  So I don't
agree with the proposed rationale for mandating the presence of a
cartesian representation.

That's not to say it's a bad idea; but if we want a solid rationale
for cartesian as opposed to polar representation we should be talking
to a number theorist about the propagation of errors through
complex-number calculations and see if there's a reason to believe
that cartesian (or polar) representation generally gives more accurate
results.

> The x|53 default for the mantissa width discriminates against
> implementations that default to unusually good representations, such
> as IEEE extended precision. Are there any such implementations? Do
> we expect such implementations in the near future?

I think that it is *always* a bad idea to standardize in a way that
discriminates against the best thing you can imagine an implementor
doing.  I recall that Chicken and a few other schemata can be compiled
with support for extended floating-point formats for people who want,
eg, 512-bit mantissas and 128-bit exponents.  And I think that's a
good thing, and the standard certainly should not forbid or
discriminate against it.

> Should `(floor +inf.0)' return +inf.0 or signal an error instead?
> (Similarly for ceiling, flfloor, infloor, etc.)

Hmmm.  Intuitively, I'd make an analogy from the result of 'floor' to
the result of the subtraction of some fraction less than one.  If we
don't return an error from the latter, we shouldn't return an error
from the former.  So I'd treat infinities as an identity element for
floor, ceiling, round, truncate, etc.  You would probably want to
signal an error if some function tries to coerce an infinity to an
exact number, though, and this usually happens with the results of
these operations.

> 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?

I would say that having them operate on exact integers in the first
place is questionable; These are operations on bit vectors, not
operations on numbers, and their semantics require information (the
vector length) which is not expressed by the numbers.  To say that
they are defined on numbers is to confuse the number with a particular
representation.

I'd put them in a separate library for bitfield operations, and If
possible I'd have them operate on bit vectors, datums distinct from
integers entirely (but with their own external syntax and easy
conversion).  If that's too radical, I'd at least require someone to
specify the bit vector length s/he intends to use when that library of
bit vector operations on "integers" is loaded.

				Bear