Re: [PATCH] First batch of numerics changes

[Andy Wingo]

On Sat 29 Jan 2011 01:05, Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> 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/