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/