Aubrey Jaffer wrote:
> I am open to mandating bignums.

I agree. The core has to provide "small" integers and normal arithmetic
operators so that you can do thinks like iterate through a vector
without having to convert it to a list. Once you have done that, you
have to deal with "small" integers not being closed under normal
arithmetic operations. There are many options, and if this were another
language we would signal an error or define "normal" to be "modular" or
use some other hack. However, we are designing Scheme, and the Right
Thing is to mandate unlimited size integers.

Yes, I know you can run out of memory with unlimited size integers, but
that is no different to other resource exhaution scenarios.

> Flonums often are the most difficult feature to port to new
> architectures.  But computer science is a half-centry old already --
> tiny implementations can say they implement a subset of R6RS.

Why do you say that? IEEE singles and doubles (although unfortunately
not extended doubles) are part of all modern architectures and are
implemented transparently (i.e., in hardware or in software by the OS)
almost everywhere. Denorms can be tricky, but it's normally just a case
of finding the right global flags.

IEEE singles and double are not difficult for an implementation, but
they are often not necessary for an application. I would vote to move
them out of the core and into the library.

That is, I would mandate only unlimited size integers in the core. The
rest of the tower should be moved to the library.

> Both Common-Lisp and SLIB implement MOST-POSITIVE-FIXNUM and
> MOST-NEGATIVE-FIXNUM, which would be good additions to R6RS.

If unlimited size integers are not mandated, these constants are useful.
If they are, these constants are not useful.

> In well-written interpreted implementations, fixnum operations would
> provide no speed increase.  SCM's type dispatch for immediate numbers
> is just 3 instructions: mask, test, and conditional jump.  With modern
> processors executing scores of instructions in the time it takes for a
> single cache line to be retrieved from memory, most data type
> dispatches use time which would otherwise be spent waiting for program
> or data caches.

What you write is correct as far as it goes, but imagine having two
number types (say fixnums and flonums) and comparing specific operators
for each type with a generic operator. On at least some processors, the
generic operator will mispredict the branch for one type or the other.
Mispredicted branches are often more painful than L1 cache misses.
Specific operators can almost always manage to avoid misdirected branches.

> SCM has real-only operations like $log and $sin, which I never use;
> even though I do substantial floating point computing.  In most
> nontrivial computations, a couple percent speed improvement from
> fiddling with the minutia of low-level procedures is dwarfed by the
> speed improvements netted by memoizing the results of certain
> sub-calculations or vectorizing computations in SRFI-63 uniform
> arrays.

Yes and no. I can imaging writing Lisp-style macros to walk code and
replace generic operations with specific ones.

> -0.0 is insufficiently specified by SRFI-77; it will be a portability
> killer.

It is perfectly specified by the IEEE standard.

> quotient+remainder introduces a new procedure naming convention which
> doesn't play well with -.
>
> The mathematical term for quotient with remainder is division; the
> verb form being divide.  How about changing QUOTIENT+REMAINDER to
> DIVIDE.

Or quotient-and-remainder. Isn't "+" sufficiently overloaded as it is
without having it stand for "and" :-)

> Mathematically, mixed exactness complex numbers makes no sense.
> Twisting the whole numeric tower around this artifice is wrong.

Maybe, but a cheap way to get an inexact imaginary is an number with an
exact zero for its real part and an inexact real for its imaginary part.

Regards,

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