Re: [PATCH] First batch of numerics changes

[Andy Wingo <wingo@pobox.com>]

On Sat 29 Jan 2011 01:05, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
>> I think that certainly when it comes to numbers, strictness is good.  In
>> particular the r6rs says:
>>
>>     (zero? z)     procedure
>>     (positive? x) procedure
>>     (negative? x) procedure
>>     (odd? n)      procedure
>>     (even? n)     procedure
>>     (finite? x)   procedure
>>     (infinite? x) procedure
>>     (nan? x)      procedure
>>
>> The name of the argument indicates the type, as noted earlier in the
>> report.  `z' is a complex number, `x' is a real, and `n' is an integer.
>> It is an error to pass a non-integer to even?.  It is also an error to
>> pass a non-real to infinite?.
>
> Are you reading the final version of R6RS, or a draft?  The above
> paragraph is not present at:
>
>   http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html

It is hidden here:

  http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-9.html#node_sec_6.2

    For succinctness, the report follows the convention that if a parameter
    name is also the name of a type, then the corresponding argument must be
    of the named type. For example, the header line for vector-ref given
    above dictates that the first argument to vector-ref must be a
    vector. The following naming conventions imply type restrictions: 

    obj	any object
    z	complex number object
    x	real number object
    y	real number object
    q	rational number object
    n	integer object
    k	exact non-negative integer object
    bool	boolean (#f or #t)
    octet	exact integer object in {0, ..., 255}
    byte	exact integer object in { - 128, ..., 127}
    char	character (see section 11.11)
    pair	pair (see section 11.9)
    vector	vector (see section 11.13)
    string	string (see section 11.12)
    condition	condition (see library section on “Conditions”)
    bytevector	bytevector (see library chapter on “Bytevectors”)
    proc	procedure (see section 1.6)

    Other type restrictions are expressed through parameter-naming
    conventions that are described in specific chapters. For example,
    library chapter on “Arithmetic” uses a number of special parameter
    variables for the various subsets of the numbers. 

    With the listed type restrictions, it is the programmer’s responsibility
    to ensure that the corresponding argument is of the specified type. It
    is the implementation’s responsibility to check for that type. 

> However, I strongly believe that finite?, infinite?, and nan? should be
> applicable to non-real complex numbers.  They would clearly be useful as
> such, otherwise those working with complex numbers will have to
> reimplement them.

Dunno.  Is inf? true if either of the components of a complex number are
inf?  If that is the case, as you had it, shouldn't finite? be true if
either component is finite?

Users of complex numbers have to choose what they mean when they ask
inf? of a number.  I think that's the intention of the report.

Andy
-- 
http://wingolog.org/