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

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

Thank you, Marc, for your comments and for your correction
to the specification of flexpt.  When such corrections are
reported, I have been making the changes and committing them
to the R6RS version control system.

Marc Feeley wrote:
> 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.

Another reason for returning a meaningless result (usually
a NaN) is that this is standard practice in most languages
that use IEEE floating point.  If you identify some of the
fl operations with the corresponding operations of IEEE-754,
then the IEEE standard could be interpreted (in some cases)
as requiring the procedure to return a NaN without raising
an exception.

The problem with saying "it is an error" is that this
phrase has often been misinterpreted to mean that an
error *should* be signalled.  As you may recall, the R6RS
editors once considered the possibility of requiring all
"is an error" situations of the R5RS to signal an error,
which would have been a huge mistake IMO.  I agree that
the fl procedures should be allowed to raise an exception
whenever they are allowed to return a NaN or meaningless
value, but they should not be required to raise an exception
in those cases.

> What is the rationale for flodd? and fleven? . I don't
> see a need for these operations.

One rationale is to simplify construction of generic
arithmetic and the full numeric tower from the fixnum
and fl procedures.  This is not a compelling rationale,
because flodd? and fleven? can be written pretty easily
using the other fl procedures.

A more compelling rationale is that parallelism between
the fl and generic primitives simplifies the porting
process you described.

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

Good point.

> Either the specification for fl+ and fl* in this case
> should be changed to return exact 0 and 1,

That would change the type of these procedures in a way
that interferes with flow analysis, so I would oppose
this change.

> or these operations should require at least one argument

That wouldn't break their closure property, but it would
break the porting process you described: changing (+) to
(fl+) would not be allowed.  In my opinion, using (+) in
an inexact computation is probably a performance bug
anyway.  Changing (fl+) to (+) when porting from R6RS to
R5RS would introduce that performance bug.  In either
direction, the code would probably continue to work.
I think it might be better to allow that performance
bug than to complicate the porting process.