[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exposing more math functionality
From: |
Phil |
Subject: |
Re: Exposing more math functionality |
Date: |
Thu, 19 Aug 2010 15:37:05 -0500 |
On Thu, Aug 19, 2010 at 11:04 AM, Andy Wingo <address@hidden> wrote:
> Heya,
>
> On Fri 23 Jul 2010 20:46, No Itisnt <address@hidden> 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.