[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exactness

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.

Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx> writes:

> A. The programmer could use exact numbers here, hoping that some day
>    someone will invent a Scheme implementation which would compile
>    this program into efficient code. The decision was also supported
>    by the fear that some weird Scheme implementation could choose the
>    default format of inexact real numbers such that the version with
>    inexact numbers would accumulate increasing precision eating more
>    and more memory.
> B. The programmer knows that ratnums are inappropriate here, and
>    at the same time knows that flonums are appropriate. He chooses
>    flonums by writing a number with a decimal point, and all existing
>    Scheme implementations run this code fine.

How abouc C:

C.  The Scheme language be augmented with functions that guarantee
    that the memory used by the results will not be greater than that
    used by the operands, and that even if the arguments are exact,
    the results may be inexact as necessary to conform to this space
    usage requirement.  Such functions could also have optional or
    default arguments that specify the exact behavior in "overflow"

>> Do you care whether they are called "portable flonums"?
>> Can we call them something else and you will be happy?
> I care that they are fast, that they are used by default for numbers
> entered with a decimal point, that I don't have to check whether
> exp(x) will overflow before applying exp, that a number which has
> overflowed can be printed and read by other implementations, that
> arctangent of a number which has overflowed is close to pi/2, and that
> if I need to interface to C in order to compute erf(x), then the only
> portability issues will be with linking with C - not with passing the
> numeric value.

Great, so we can keep the existing types, the existing exact/inexact
distinction, and provide space-constant functions as I suggest.  All
that seems to be fine.