pure-lang-users

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> Oh shame shame.

No sweat. With all that administrative crap on your schedule right now, 
I wonder how you can still think at all. ;-)

> Still mortified over that last one but mzscheme gives the following:
> For x < 0,
>   > (expt -4.0 -inf.0)
>   0.0
>   > (expt -4.0 +inf.0)
>   +inf.0

Yes, in fact that's what the C pow() function gives you (or c_pow in 
Pure). The first result actually makes sense, but not the second. :)

However, Pure's (^) operator deals with negative bases by returning a 
complex result (nan+:nan in this case); other function like sqrt work 
analogously.

> For complex x,
>   > (expt 1+2i -inf.0)
>   +nan.0+nan.0i
>   > (expt 1+2i +inf.0)
>   +nan.0+nan.0i

Pure behaviour is the same here.

I'm beginning to think that Scheme makes more sense in that it returns 
complex results for complex inputs, and real results (possibly nan for 
undefined cases) for real inputs. The necessary changes to do it the 
Scheme way in Pure should in fact be straightforward. Is that what 
everybody wants?

I also have to do something about (0+:0)^0; it returns nan+:nan now, 
which isn't appropriate.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Fri, 2008-08-22 at 15:55 +0200, Albert Graef wrote:

> >   > (expt -4.0 +inf.0)
> >   +inf.0

> Pure). The first result actually makes sense, but not the second. :)

Yea, that's an indeterminate result there. I guess they determined one
for us there :-?

> I'm beginning to think that Scheme makes more sense in that it returns 
> complex results for complex inputs, and real results (possibly nan for 
> undefined cases) for real inputs. The necessary changes to do it the 
> Scheme way in Pure should in fact be straightforward. Is that what 
> everybody wants?

+1 

> I also have to do something about (0+:0)^0; it returns nan+:nan now, 
> which isn't appropriate.

Back to scheme:
  > (expt 0+0i 0)
  1
  > (expt 0.0+0.0i 0)
  1
  > (expt 0.0+0.0i 0.0)
  +nan.0+nan.0i

e.r.

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> Yea, that's an indeterminate result there. I guess they determined one
> for us there :-?

Bah, who needs more than one accumulation point anyway? :)

>> I'm beginning to think that Scheme makes more sense in that it returns 
>> complex results for complex inputs, and real results (possibly nan for 
>> undefined cases) for real inputs. The necessary changes to do it the 
>> Scheme way in Pure should in fact be straightforward. Is that what 
>> everybody wants?
> 
> +1 

Done (r575). Actually this makes things much easier since I can just 
leave away all those messy special case rules for the real->complex 
cases, so this seems to be the right thing to do. It's also in line with 
the philosophy of *not* promoting return values automagically. OTOH, 
it's also a bit less convenient, since e.g. you have to write sqrt 
(-1+:0) to get the imaginary root now.

>> I also have to do something about (0+:0)^0; it returns nan+:nan now, 
>> which isn't appropriate.

In fact this seems to be consistent with how the POSIX cpow() function 
behaves, so I'm going to leave it that way for now. But there are other 
cases I have to look at, such as (0+:0)^1. I really need to work on the 
formulas for complex (^) in math.pure, they're just broken in the corner 
cases. If you have any suggestions on how we should implement that 
beast, please let me know.

> Back to scheme:
>   > (expt 0+0i 0)
>   1
>   > (expt 0.0+0.0i 0)
>   1
>   > (expt 0.0+0.0i 0.0)
>   +nan.0+nan.0i

It doesn't make sense to distinguish these cases in Pure since, by 
design, (^) always returns inexact results. That's not negotiable. ;-)

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> I got tired of importing math functions from the C library so I made a
> wrapper for them.

Well, if you're subscribed to the svn logs, then you might have noticed
that I just checked in my own math.pure. Coincidence. ;-) I still have
to add complex and rational numbers, but the basic (read: real) math
stuff should already be there. Could you maybe review that and let me
know if anything's missing?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> However, instead of log x being the log base 10 how about
> 
> log b::int x::double | log b::bigint x::double = ln x / ln b;

Seems useful. Well, log is customary for base 10 logarithms, at least on
this side of the Atlantic. I could rename that function to log10, though
(that's also how it's called in Python). Or we could use log (x,b) or
log (b,x) for a logarithm with given base (but that would take away the
possibility to curry, which is pretty useful with your definition).
Opinions?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Sat, 2008-06-28 at 22:13 +0200, Albert Graef wrote:
> Eddie Rucker wrote:
> > However, instead of log x being the log base 10 how about
> > 
> > log b::int x::double | log b::bigint x::double = ln x / ln b;
> 
> Seems useful. Well, log is customary for base 10 logarithms, at least on
> this side of the Atlantic. I could rename that function to log10, though

Yes, it's that way here too. log x is really log_b 10 x . How about:

logb b::int x::double | logb b::bigint x::double = ln x / ln b;

e.r.

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Albert Graef wrote:
> Well, if you're subscribed to the svn logs, then you might have noticed
> that I just checked in my own math.pure.

BTW, that's basically the same stuff as in math.q, with some things
added that are built-in in Q, and making use of POSIX C math routines
where possible. (Some of these have special cases where the result
becomes complex; I'll deal with those after I added the complex type.)

My idea for the complex type is to provide both rectangular (x+:y) and
polar (r<:a) representations, with all the necessary machinery to make
the arithmetic and other functions work with either, as well as explicit
conversions between the two. Does that sound useful? I really like that
feature on my HP calc.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

> My idea for the complex type is to provide both rectangular (x+:y) and
> polar (r<:a) representations, with all the necessary machinery to make
> the arithmetic and other functions work with either, as well as explicit
> conversions between the two. Does that sound useful? I really like that
> feature on my HP calc.

+1 

Conversion between the two is a must.

e.r.

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Sat, 2008-06-28 at 21:03 +0200, Albert Graef wrote:
> Eddie Rucker wrote:
> > I got tired of importing math functions from the C library so I made a
> > wrapper for them.
> 
> Well, if you're subscribed to the svn logs, then you might have noticed
> that I just checked in my own math.pure. Coincidence. ;-) I still have
> to add complex and rational numbers, but the basic (read: real) math
> stuff should already be there. Could you maybe review that and let me
> know if anything's missing?

It just showed up 19 minutes ago on my side of the world. Your's is
better than mine ;)

However, instead of log x being the log base 10 how about

log b::int x::double | log b::bigint x::double = ln x / ln b;

I use this definition more often.

Oh yea, how about going a head and defining the constant PI?
def PI = 3.14159265358979;
That is as many digits as I can get Pure to represent.

e.r.

Re: [pure-lang-users] math.pure

[me22 <me...@gm...>]

On Sat, Jun 28, 2008 at 16:13, Albert Graef <Dr....@t-...> wrote:
> Eddie Rucker wrote:
>> However, instead of log x being the log base 10 how about
>>
>> log b::int x::double | log b::bigint x::double = ln x / ln b;
>
> Seems useful. Well, log is customary for base 10 logarithms, at least on
> this side of the Atlantic. I could rename that function to log10, though
> (that's also how it's called in Python). Or we could use log (x,b) or
> log (b,x) for a logarithm with given base (but that would take away the
> possibility to curry, which is pretty useful with your definition).
> Opinions?
>

I'd say "customary" depends greatly on context.  Without a base, I
think it should be natural, for consistency with C and my math profs.

I really like the curried version, though.

Re: [pure-lang-users] math.pure

[Libor S. <li...@gm...>]

Probably having just the natural logarithm would avoid the potential confusion.
Anyone wanting any "unnatural" base ought to understand enough to do ln x / ln b themselves.
L.

On Sat, 28 Jun 2008 21:29:05 +0100, me22 <me...@gm...> wrote:

> On Sat, Jun 28, 2008 at 16:13, Albert Graef <Dr....@t-...> wrote:
>> Eddie Rucker wrote:
>>> However, instead of log x being the log base 10 how about
>>>
>>> log b::int x::double | log b::bigint x::double = ln x / ln b;
>>
>> Seems useful. Well, log is customary for base 10 logarithms, at least on
>> this side of the Atlantic. I could rename that function to log10, though
>> (that's also how it's called in Python). Or we could use log (x,b) or
>> log (b,x) for a logarithm with given base (but that would take away the
>> possibility to curry, which is pretty useful with your definition).
>> Opinions?
>>
>
> I'd say "customary" depends greatly on context.  Without a base, I
> think it should be natural, for consistency with C and my math profs.
>
> I really like the curried version, though.
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> pure-lang-users mailing list
> pur...@li...
> https://lists.sourceforge.net/lists/listinfo/pure-lang-users
> 

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

me22 wrote:
> I'd say "customary" depends greatly on context.

Customary in math I meant.

> I really like the curried version, though.

Me too. OTOH, as Libor pointed out, it's not a big deal to define this
yourself when you need it.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag