Thomas Bushnell BSG <xxxxxx@becket.net> writes:

> It's not.  There may actually be programs out there that depend on
> exact division doing the mathematically right thing.  You want to
> break them all?

There must have been some misunderstanding. I don't want to change /
from performing exact division if given exact arguments (rational
or complex-rational).

I want to make more predictable when the programmer will obtain a
ratnum and when a flonum. And I want him to be sure that he will not
obtain some weird representation like "a ratnum with inexactness bit"
or "fixed-size decimal fraction" without explicitly asking for it.

>> (The difference between fixnums and bignums should not be exposed
>> except perhaps by some weird functions used as an efficiency hack.
>> Other representations are important though.)
>
> See, this is where you're wrong.  Constant-width addition is valuable
> for integers too, not just floats.  But when people doing integer
> arithmetic want that, it's an "efficiency hack", and when you want it
> for floating point, it's Absolutely Essential.

What do you mean by constant-width addition?

a) Addition modulo 2^N, where N is a well-defined number like 32.

b) Addition of integers which the given implementation can represent
   more efficiently than others, where the programmer hopes that the
   range will be sufficient for his needs (e.g. they are indices into
   a vector), and he values efficiency very much.

My answers:

a) is a legitimate need which should be fulfilled by other operations
than the standard + (because + is already agreed on to do a different
thing for integers), or at most by other type than standard integers.
I'm not convinced that Scheme should provide this in the standard
though, because the need is quite rare, and Scheme aims to be
minimalistic. There are other unstandarized features which are much
more important, like read-line and hash tables.

b) is an efficiency hack, because the wanted behavior is a subset of
the standard + and because it's unsafe (i.e. has either undefined
behavior or a clearly wrong outcome when misused). It makes sense only
when it's unsafe; checking types and checking for overflow is about as
costly as switching to bignums when needed.

Fixed-size floating point arithmetic differs in that it's safe, that
people expect it to be slightly inexact (or should be taught to expect
this), and that often the performance difference between fixed size
floating point and exact ratios is huge, while the difference in the
answer is small.

Of course the programmer can use exact ratios instead if he chooses.
It should be his choice, not the Scheme implementor's choice.

> I think the best way to provide it is by functions that cleary specify
> which behavior they get, preserving backward compatibility with the
> existing standard.

Letting (+ 1.2 3.4) perform fixed-size binary floating point arithmetic
is compatible with both the existing standard and common practice.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/