Marcin 'Qrczak' Kowalczyk <xxxxxx@knm.org.pl> writes:

> It would lead to a way too complex interface. There are too many
> interacting features to specify.

Good grief, you seem to be approaching this as if we didn't have
computers handy to help out.

(with-ieee-floating-point ...) can just be syntactic sugar for a
specification of whatever options is the right set.

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

Oh, I think it's already agreed that Scheme should not be mandated to
support floating point arithmetic.  At least, I can see no advantage
to such a mandate.  Do you think that mandating it will somehow change
anyone's behavior materially?  Standards are not sticks with which to
beat implementors into doing what you want.

> The R5RS knobs are very limited. It's basically one button for all
> numbers: exact/inexact. Everything else is supposed to be automatic.

No, rather everything else is not standardized.

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

You must stop thinking of "inexact" as a synonym for "floating
point".  Please.

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

I think that they (or something like these) should all be understood
by all Scheme systems.  I do not object to that.  I do not think that
any particular combination should be mandated, much less mandating all
possible combinations.  Those which do not support them (or some
combination of them) should be required to document their behavior and
behave sensibly when the cannot implement something.

> b) Or the programmer should have no portable way to control them,
>    as everything (besides the exactness bit) should depend on the
>    implementation?

The programmer should be able to specify clearly what he wants (where
*implementation* is not "what he wants", but only *sets of features*).

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

Certainly not.

The "features" you list aren't really features, they are questions.

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

Trig functions most certainly can be computed exactly if you have a
clever enough implementation.  You aren't thinking correctly here,
because you are wedded to implementation issues.  It is perfectly
possible to implement exacts reals, and make the trig functions
compute exact answers.  (Have you ever played with maxima?)

So the starting point of that question is ill-phrased.  I can think of
several different rephrasings for it, however, which have different
answers.  So I can't guess at which is the correct rephrased question
to answer.

> 2. In case of functions like trigonometric, do we insist on specifying
>    the precision - perhaps quite large - or any reasonable hardware
>    default will do?

Perhaps we could insist on neither, and give programmers the option of
specifying the precision, and then implementations which can comply
will do so, and the others will either signal an error or (at user
preference) do the best they can.

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

Once more, why do we need to answer such questions?  Just provide all
of those.  They all seem useful.

How to print a number is an entirely separate question from its
representation.  For example, on a system with exact reals, the system
might know that the value of some computation is 2π; what should
happen when it's printed?  Sometimes I might want to print 6.28,
sometimes 6.2831 (truncated), sometimes 6.2832 (rounded), sometimes
2π, and perhaps sometimes 6!

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

As Alan Watson pointed out, this is simply a normal case of memory
exhaustion and does not need to be discussed separately.

But I would not object to optional features which signal errors if an
exact number is too big, or if the storage size of a number grows
beyond some bound.  Those are the same sorts of features I might want
if a hash table or an array grows "too big", and should be treated the
same way.

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

If the user wants exact results, and the system is unable to compute
one, the result is normally said to be undefined.  I don't mind more
specific answers to those questions.

If the user doesn't care about exactness, then I don't mind giving the
user options here.

> 6. What should happen if not-a-number is compared by eqv? = < > <= >=
>    with other numbers and itself? Return #t/#f? Signal an error?

Give the user options; in this case, by different functions or
optional arguments on the functions.

> 7. Should there be a distinguished -0.0 which determines the side
>    of a branch cut of a multivalued complex function?

Give the user options; in this case, by different functions or by
optional arguments.

> 8. Do we need exact complex numbers?

Who is "we"?

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

This is an ongoing difficulty for some people.  The answer is
certainly "no", it should not be tracked differently, but that's
because I think of complex numbers as numbers, not as pairs of
numbers.  But I'm not inflexible on this point; I just don't see the
need to track it separately, and it seems to confuse the notion of
what "exact" means.

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

Perhaps we need two functions!

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

It's like you didn't read what I wrote.

As I said, if you do an operation which exceeds the limitation of such
a function using exact numbers, you need to be able to specify what
the resulting behavior is (for example, clamping, error, and modular
arithmetic are all sensible possibilities).

>> I don't know what you mean by "safe";
>
> That they don't cause undefined behavior.

Sure, I'm all for that.  I think we should let the programmer define
the behavior he wants.

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

If you are right that all general-purpose implementations will want to
provide IEEE floating point arithmetic (and I certainly agree), then
what's wrong with the user saying (with ieee-floating-point-behavior
...) and having done with it?

Thomas