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.
Thomas Bushnell BSG <tb@xxxxxxxxxx> writes:
> Much better is to think about what *features* specifically you want,
> and have programmers ask for *those*.
It would lead to a way too complex interface. There are too many
interacting features to specify.
The purpose of the IEEE standard for floating point arithmetic
is that we don't have to describe features from scratch each time,
design what kinds of special numbers should be supported and how.
It comes prepackaged. It's a set of sane defaults for certain purposes.
And it's usually implemented in hardware, i.e. it's fast.
Actually IEEE does provide various knobs for tuning the behavior:
rounding mode, the precision, or setting which unusual conditions
should be signalled as catchable errors. I would be glad if they
were standarized in more programming languages.
But how can we agree on the way of specifying these details if we
can't agree whether Scheme should be mandated to support any kind
of floating point at all?
The R5RS knobs are very limited. It's basically one button for all
numbers: exact/inexact. Everything else is supposed to be automatic.
The user must even be prepared that the implementation itself will
sometimes switch the button to "inexact". This is too inflexible.
How do you propose to specify more?
> So far you've mentioned one feature: constant size arithmetic.
> I've suggested one way of having programmers ask for that feature
> (though there are surely others).
Below are some other features which matter.
a) Do you think they should be independently settable, and the
implementation would be required to produce a numeric format
which fulfills any self-consistent combination of them?
b) Or the programmer should have no portable way to control them,
as everything (besides the exactness bit) should depend on the
implementation?
c) Or a few prepackaged sets of choices should be provided (ratnums,
flonums etc., less standard representations used explicitly -
not taking over the default reader formats)?
My answer is c) for most of them, a) to some others (e.g. textual
formatting).
1. In case of functions which in general can't be computed exactly
(e.g. trigonometric), do we want an assurance about the interval
that the true result sits in (interval arithmetic), facing the
possibility that < can't be determined, or perhaps we will be happy
with a single approximate result?
2. In case of functions like trigonometric, do we insist on specifying
the precision - perhaps quite large - or any reasonable hardware
default will do?
3. How to format a number into text? Use a decimal point or vulgar
fraction? Do we want to get a decimal point in case of an inexact
number which looks like it's an integer? How many digits after the
point to display? Is the scientific (exponential) notation accepted?
Pad with leading and trailing zeros to some widths? Use "." or ","?
Do we accept "#" in place of trailing insignificant digits?
4. What should happen when the number being computed is getting too
large to be conveniently represented? Return "infinity"? Signal an
error? How an infinity is formatted into text?
5. What should happen when the inherent inaccuracy of the operation
would make the implementation unable to sensibly compute the
result, e.g. (sin (exp 1000))? Return special not-a-number marker?
Signal an error?
6. What should happen if not-a-number is compared by eqv? = < > <= >=
with other numbers and itself? Return #t/#f? Signal an error?
7. Should there be a distinguished -0.0 which determines the side
of a branch cut of a multivalued complex function?
8. Do we need exact complex numbers?
9. Should the implementation try to track inexactness of real and
imaginary part separately, or we don't care? If the imaginary part
comes very close to 0, should the result be indistinguishable from
a real number, or we care about being sure whether it's real or not?
10. When we ask whether the number is even, and it happens to be
inexact, should the implementation try to answer hoping that
inexactness did not change the value, or we prefer an error to be
signalled?
>> What do you mean by constant-width addition?
>
> I mean "addition in which the space use of the output is no larger
> than the input". This is a feature which you said was needed for
> reals (I agree) and it's a feature that is useful for integers too.
This description is meaningful for inexact numbers (cut less
significant digits which are over the limit, with proper rounding),
but meaningless for exact ones: there are no digits to cut if the
number should remain exact.
> I don't know what you mean by "safe";
That they don't cause undefined behavior.
>> Letting (+ 1.2 3.4) perform fixed-size binary floating point arithmetic
>> is compatible with both the existing standard and common practice.
>
> What exactly are you asking for?
In general I'm asking to make the behavior of Scheme arithmetic
defined in more details, to give less choice for implementations and
more confidence for users about what to expect.
For example I believe that IEEE or at least IEEE-like floating point
arithmetic should be the default choice of inexact real numbers.
I wish that if the given implementation supports IEEE at all, it
should do it in the same way as others e.g. with respect to the
behavior of eqv? and = on NaN and the textual notation of special
numbers.
I don't have a complete plan. I only comment on issues related to
SRFI-77, which was not my initiative.
> By "letting" do you mean "requiring"?
Yes.
> (Because then, you're wrong.)
Why?
--
__("< Marcin Kowalczyk
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/