Exposing more math functionality

Exposing more math functionality

[No Itisnt]

I'd like to patch Guile's math functionality to expose M_PI, modf, and
probably other things as well. Before I started I thought I'd ask --
would such a patch be accepted? And is there any policy on where they
should go? It seems a little crass to clutter up the (guile) namespace
any more, but I don't see anywhere else those could go.

Re: Exposing more math functionality

[Andy Wingo]

Heya,

On Fri 23 Jul 2010 20:46, No Itisnt <theseaisinhere@gmail.com> writes:

> I'd like to patch Guile's math functionality to expose M_PI, modf, and
> probably other things as well. Before I started I thought I'd ask --
> would such a patch be accepted? And is there any policy on where they
> should go? It seems a little crass to clutter up the (guile) namespace
> any more, but I don't see anywhere else those could go.

Hum, I think the right thing is to talk about these one by one.

For pi, I think I'd like to avoid adding it to the namespace, partly
because I can't think of a good name. M_PI is ugly :) You can always
define it as (define pi (* 4 (atan 1))) or something.

Actually my schooling was in engineering, so I'd say (define pi 3). ;-)

Regarding modf -- it seems that the R6RS extends the definition of
`modulo' (called `mod') to be defined over the real numbers.

  (mod 10 3) => 1
  (mod 10 3.0) => 1.0
  (mod 10 3.1) => 0.7

This appears to be a compatible extension of the R5RS' `modulo', so we
should just extend our definition. That way we can avoid adding another
symbol.

Let me know if you're interested in doing this, otherwise I'll get
around to it eventually. But perhaps someone who is less fast-and-loose
with accuracy should do it ;-)

Cheers,

Andy
-- 
http://wingolog.org/

Re: Exposing more math functionality

[Phil]

On Thu, Aug 19, 2010 at 11:04 AM, Andy Wingo <wingo@pobox.com> wrote:
> Heya,
>
> On Fri 23 Jul 2010 20:46, No Itisnt <theseaisinhere@gmail.com> writes:
>
>> I'd like to patch Guile's math functionality to expose M_PI, modf, and
>> probably other things as well. Before I started I thought I'd ask --
>> would such a patch be accepted? And is there any policy on where they
>> should go? It seems a little crass to clutter up the (guile) namespace
>> any more, but I don't see anywhere else those could go.
>
> Hum, I think the right thing is to talk about these one by one.
>
> For pi, I think I'd like to avoid adding it to the namespace, partly
> because I can't think of a good name. M_PI is ugly :) You can always
> define it as (define pi (* 4 (atan 1))) or something.
>
> Actually my schooling was in engineering, so I'd say (define pi 3). ;-)
>
> Regarding modf -- it seems that the R6RS extends the definition of
> `modulo' (called `mod') to be defined over the real numbers.
>
>  (mod 10 3) => 1
>  (mod 10 3.0) => 1.0
>  (mod 10 3.1) => 0.7
>
> This appears to be a compatible extension of the R5RS' `modulo', so we
> should just extend our definition. That way we can avoid adding another
> symbol.
>
> Let me know if you're interested in doing this, otherwise I'll get
> around to it eventually. But perhaps someone who is less fast-and-loose
> with accuracy should do it ;-)
>
> Cheers,
>
> Andy
> --
> http://wingolog.org/

I managed to phone it in on these, except for modf, so I don't have
any need for them, although exposing pi might not be a bad idea
anyway.

Re: Exposing more math functionality

[Andy Wingo]

On Thu 19 Aug 2010 09:04, Andy Wingo <wingo@pobox.com> writes:

> Regarding modf -- it seems that the R6RS extends the definition of
> `modulo' (called `mod') to be defined over the real numbers.
>
>   (mod 10 3) => 1
>   (mod 10 3.0) => 1.0
>   (mod 10 3.1) => 0.7
>
> This appears to be a compatible extension of the R5RS' `modulo', so we
> should just extend our definition. That way we can avoid adding another
> symbol.

This was a mistaken impression, something I realized while trying to
implement this. From the R6RS rationale, section 11.6.6:

    div and mod

    Given arithmetic on exact integer objects of arbitrary precision, it
    is a trivial matter to derive signed and unsigned integer types of
    finite range from it by modular reduction.  For example 32-bit
    signed two-complement arithmetic behaves like computing with the
    residue classes “mod 232 ”, where the set {−231 , . . . , 231 − 1}
    has been chosen to represent the residue classes. Likewise, unsigned
    32-bit arithmetic also behaves like computing “mod 232 ”, but with a
    different set of representatives {0, . . . , 232 − 1}.

    Unfortunately, the R5 RS operations quotient, remainder, and modulo
    are not ideal for this purpose. In the following example, remainder
    fails to transport the additive group structure of the integers over
    to the residues modulo 3.
                                                                        
                                         
          (remainder (+ -2 3) 3) =⇒ 1
                                                                        
          (remainder (+ (remainder -2 3)
                        (remainder 3 3))
                     3) =⇒ -2
                                                                   
    In fact, modulo should have been used, producing residues in {0, 1,
    2}.  For modular reduction with symmetric residues, i.e., in {−1, 0,
    1} in the example, it is necessary to define a more complicated
    reduction altogether.
                                                                   
    Therefore, quotient, remainder, and modulo have been replaced in R6
    RS by the div, mod, div0, and mod0 procedures, which are more useful
    when implementing modular reduction. The underlying mathematical
    functions div, mod, div0 , and mod0 (see report section 11.7.3) have
    been adapted from the div and mod operations by Egner et
    al. [11]. They differ in the representatives from the residue
    classes they return: div and mod always compute a nonnegative
    residue, whereas div0 and mod0 compute a residue from a set centered
    on 0. The former can be used, for example, to implement unsigned
    fixed-width arithmetic, whereas the latter correspond to
    two’s-complement arithmetic.
                                                                   
    These operations differ slightly from the div and mod operations
    from Egner et al. The latter make both operations available through
    a single pair of operations that distinguish between the two cases
    for residues by the sign of the divisor (as well as returning 0 for
    a zero divisor). Splitting the operations into two sets of
    procedures avoids potential confusion.
                                                                   
    The procedures modulo, remainder, and quotient from R5RS can easily
    be defined in terms of div and mod.
                                                               
So I'm not sure what to do exactly. If Scheme people are happy with div
and mod, as in the R6RS, then we should implement them and make them the
default, implementing quotient, modulo, and remainder in terms of
them. Hmm.

Andy
-- 
http://wingolog.org/

Re: Exposing more math functionality

[Andy Wingo]

On Fri 27 Aug 2010 08:44, Andy Wingo <wingo@pobox.com> writes:

> On Thu 19 Aug 2010 09:04, Andy Wingo <wingo@pobox.com> writes:
>
>> Regarding modf -- it seems that the R6RS extends the definition of
>> `modulo' (called `mod') to be defined over the real numbers.
>>
>>   (mod 10 3) => 1
>>   (mod 10 3.0) => 1.0
>>   (mod 10 3.1) => 0.7
>>
>> This appears to be a compatible extension of the R5RS' `modulo', so we
>> should just extend our definition. That way we can avoid adding another
>> symbol.
>
> This was a mistaken impression, something I realized while trying to
> implement this. From the R6RS rationale, section 11.6.6:
>
>     div and mod [...]

I was pointed to http://mumble.net/~campbell/tmp/division.txt today,
which is enlightening. I don't know what to do with it yet. I like the
snarky take on div0 and mod0 though ;)

Andy
-- 
http://wingolog.org/