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

Handling of invalid arguments

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.



The specification for flexpt is strange:

procedure: flexpt fl1 fl2
Returns fl1 raised to the power fl2. For nonzero fl1

fl1 ^ fl2 = e ^ (z2 log z1)

0 ^ fl is 1 if z = 0, and 0 if fl is positive. Otherwise, the result may be a NaN, or may be some meaningless flonum.
I assume the specification really is

   fl1 ^ fl2 = e ^ (fl2 log fl1)

and

   0 ^ fl is 1 if fl = 0 ...

This specification is not closed on flonums, i.e. (flexpt -1.0 0.5) => +1.0i . The specification should restrict fl1 to be non-negative.

I have noticed that the specification of flexpt, flsqrt, flatan and many other procedures may return a meaningless result for certain ranges of arguments. It would be better to say "it is an error", so that Scheme systems that wish to do so can signal an error in these cases to improve debugging. Scheme implementations would still be allowed to return a meaningless result, if that simplifies implementation or improves performance.

The same treatment should apply to:

procedure: flfloor fl
procedure: flceiling fl
procedure: fltruncate fl
procedure: flround fl
These procedures return integral flonums for flonum arguments that are not infinities or NaNs. ... Although infinities and NaNs are not integers, these procedures return an infinity when given an infinity as an argument, and a NaN when given a NaN:
that is, "it is an error" for fl to not be finite.

What is the rationale for flodd? and fleven? . I don't see a need for these operations. In any case, they should also be restricted to finite arguments (i.e. "it is an error" for the argument to not be a finite flonum).

These changes would allow a Scheme implementation to treat the flonum- specific operations as pure specializations of the generic operations. That is, if the flonum-specific operations are given arguments that do not lead to "an error", then the result is the same as the corresponding generic operation applied to those arguments. This is a desirable property because a program developed with flonum- specific operations in a R6RS Scheme system can be ported to an R5RS Scheme system which supports inexact numbers by simply removing the "fl" prefixes. Moreover, the changes I propose would simplify the porting of "scientific" R5RS programs to an R6RS system. The procedure would be:

1) replace the generic operators by their corresponding flonum- specific operator,
2) run the program on several tests,
3) for any error reported for a flonum-specific operation, find why invalid arguments where passed to that operation, fix the code, and return to step 2, 4) when the developer is confident that the code is correct, they can compile it in unsafe mode to get maximum performance.

Note that a small specification change for fl+ and fl* would be required because when applied to no arguments they return inexact 0 and 1 respectively, whereas + and * return exact 0 and 1 respectively. Either the specification for fl+ and fl* in this case should be changed to return exact 0 and 1, or these operations should require at least one argument (this would mean that to compute the flonum sum of a list of flonums, this code would work even if the list is empty: (apply fl+ 0.0 list-of-flonums)).

Marc