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

Re: Arithmetic issues

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.

There is much I disagree with in this proposal, but I thank the SRFI authors for their excellent work in framing these issues and writing up a straw-man solution.

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

Exact integers (fixnums and bignums in the core). Flonums and the rest of the tower in the library.

If you have a small implementation and don't want to implement full bignums, then implement fixnums, check for overflow, and signal an error on overflow.

Under no circumstances specify modular arithmetic as the behaviour of the standard operators on exact numbers. Either they should give the right answer or they signal an error.

Basically, I think the solution to the type analyis problem is putting type information into the language and allowing procedures to be declared or inferred to be constant.

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

Okay, but there are solutions. For example, define a potential number, like CL, define "string->number" and "number->string" in the core and in the library, and have read and write use the current definitions of these procedures.

* Should a minimum precision be required for fixnums or flonums?

In an implementation written in C (i.e., without access to the carry flag) running on a 32-bit processor, it might make sense to use 16-bit fixnums to make it easy to check for overflow and the need for bignums.

Of course, in a sense, you have access to the carry flag because "long long" is at least 64-bits. However, using long longs to check for overlow may be less efficient.

On the other hand, if bignums are part of the core, there is less need to force a decent range for fixnums, provided bignums can be used as indices and sizes.

* Should the range of a fixnum be restricted to a power of two? To a
two's complement range?

If you have bignums, then the range of a fixnum becomes less important. However, I see no problem with restricting it to a two's complement range.

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

One of the primary motivations for this disappears if bignums must be part of the core.

* Should the binary fixnum/flonum operations allow other than two


* What are the semantics of "safe mode" and "unsafe mode"?

Perhaps leave the semantics of "unsafe mode" to the implementation?

* Should R6RS allow other inexact reals beside the flonums?

At the very least, it must allow for different types of flonums.

* Should the R5RS procedures for generic arithmetic (e.g. +) remain in
R6RS? 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?

Yes. It doesn't matter much to me whether the generic arithmetic is part of the core or the library.

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


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

Okay. If I understand this correctly, real? would be (and (number? z) (exact? (imag-part z)) (zero? (imag-part z))) and realistic? would be just (and (number? z) (zero? (imag-part z)). I am not sure that the new predicates are needed, but would not object to them.

Maybe call them realish? rationalish? and integralish? :-)

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

How can fxabs be abused?

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


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

Others have said yes. I have nothing to add.

* Should `(floor +inf.0)' return +inf.0 or signal an error instead?

The former.

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

No. No. How/why?

* The division between regular procedures and library procedures is
somewhat arbitrary.

And appears does not appear to constrain implementations in any way. It's just a hint to implementors, yes? Why not just make everything a regular procedure?


Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México