pure-lang-users

[pure-lang-users] math.pure

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

I got tired of importing math functions from the C library so I made a
wrapper for them.

If it sux just let me know and I'll try to make unsuck.

Notes
log b x - means log base b of x
ln x    - C's log x

I did not implement
 frexp - decomposes a number into scientific notation
 ldexp - computes a number in scientific notation
 modf  - decomposes a number into integer and fractional parts
 log10 - common logarithm (to base 10)
         Equivalent to log 10 x

e.r.

[pure-lang-users] math.pure

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

Albert,
While testing, I looked over some of the logs and here are my
suggestions:

Add the rules
sqrt inf = inf;
sqrt nan = nan;
ln inf = inf;
ln nan = nan;

Both of these rules also fix
acosh and atanh of nan and inf

I think cis is broken for complex numbers. I've got to run give another
test.

e.r.

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

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

Should we have the following rules?
_+:nan = nan;
nan+:_ = nan;
nan<:_ = nan;
_<:nan = nan;

My thinking is that if any part of a complex number is nan then the
whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you
might want to keep that way for either further processing or to let the
user know the result is a complex number. What does everyone think about
this?

e.r.

On Wed, 2008-08-20 at 13:31 -0500, Eddie Rucker wrote:
> Albert,
> While testing, I looked over some of the logs and here are my
> suggestions:
> 
> Add the rules
> sqrt inf = inf;
> sqrt nan = nan;
> ln inf = inf;
> ln nan = nan;
> 
> Both of these rules also fix
> acosh and atanh of nan and inf
> 
> I think cis is broken for complex numbers. I've got to run give another
> test.
> 
> e.r.
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> pure-lang-users mailing list
> pur...@li...
> https://lists.sourceforge.net/lists/listinfo/pure-lang-users

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

[John C. <co...@cc...>]

Eddie Rucker scripsit:
> Should we have the following rules?
> _+:nan = nan;
> nan+:_ = nan;
> nan<:_ = nan;
> _<:nan = nan;
> 
> My thinking is that if any part of a complex number is nan then the
> whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you
> might want to keep that way for either further processing or to let the
> user know the result is a complex number. What does everyone think about
> this?

I'd avoid this: it's easy enough to add a post-processing ruleset
to make the change.  Just because the real side of a computation has
lost significance doesn't mean the imaginary side doesn't still contain
useful data (or vice versa).  The whole point of inf and nan is to allow
computation to continue, postponing the check for significance to the end.

-- 
John Cowan     http://ccil.org/~cowan    co...@cc...
Monday we watch-a Firefly's house, but he no come out.  He wasn't home.
Tuesday we go to the ball game, but he fool us.  He no show up.  Wednesday he
go to the ball game, and we fool him.  We no show up.  Thursday was a
double-header.  Nobody show up.  Friday it rained all day.  There was no ball
game, so we stayed home and we listened to it on-a the radio.  --Chicolini

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

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

On Wed, 2008-08-20 at 17:32 -0400, John Cowan wrote:
> Eddie Rucker scripsit:
> > Should we have the following rules?
> > _+:nan = nan;
> > nan+:_ = nan;
> > nan<:_ = nan;
> > _<:nan = nan;
> > 
> > My thinking is that if any part of a complex number is nan then the
> > whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you
> > might want to keep that way for either further processing or to let the
> > user know the result is a complex number. What does everyone think about
> > this?
> 
> I'd avoid this: it's easy enough to add a post-processing ruleset
> to make the change.  Just because the real side of a computation has
> lost significance doesn't mean the imaginary side doesn't still contain
> useful data (or vice versa).  The whole point of inf and nan is to allow
> computation to continue, postponing the check for significance to the end.
> 

Thanks John! You and Albert keep it coming.

e.r.

[pure-lang-users] Bug with list comprehensions

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

 > using math;
 > let x = [1+:2, 1%4];
 > [(i,j); i=x; j=x];
 [(0+:1,1+:2),(0+:1,1L%4L),(0+:1,1+:2),(0+:1,1L%4L)]

As if this weren't weird enough, if you type this in right after 

 > let y = [1%2, 3%4];
 > [(i,j); i=y; j=y]
 [(0+:1,1L%2L),(0+:1,3L%4L),(0+:1,1L%2L),(0+:1,3L%4L)]

Note that 
 > let x = [1%2, 3%4];
 > [(j,k); j=x; k=x];
 [(1L%2L,1L%2L),(1L%2L,3L%4L),(3L%4L,1L%2L),(3L%4L,3L%4L)]

Works. So my guess is that the constant i defined in math.pure is
getting mixed up with the i in [(i,j); i=x; j=x];

e.r.

Re: [pure-lang-users] Bug with list comprehensions

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

Eddie Rucker wrote:
>  > using math;
>  > let x = [1+:2, 1%4];
>  > [(i,j); i=x; j=x];
>  [(0+:1,1+:2),(0+:1,1L%4L),(0+:1,1+:2),(0+:1,1L%4L)]

Yeah, that's certainly a bug. List comprehensions get processed like 
some kind of macro internally, and it looks like there's some bad name 
capturing going on there. Thanks for the report, I will have to look 
into this.

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] Bug with list comprehensions

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

Eddie Rucker wrote:
>  > using math;
>  > let x = [1+:2, 1%4];
>  > [(i,j); i=x; j=x];
>  [(0+:1,1+:2),(0+:1,1L%4L),(0+:1,1+:2),(0+:1,1L%4L)]

Fixed (r555).

-- 
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-...>]

>> I'd avoid this: it's easy enough to add a post-processing ruleset
>> to make the change.  Just because the real side of a computation has
>> lost significance doesn't mean the imaginary side doesn't still contain
>> useful data (or vice versa).  The whole point of inf and nan is to allow
>> computation to continue, postponing the check for significance to the end.

Spot on.

> Thanks John! You and Albert keep it coming.

That's rather remarkable, since I didn't even comment yet. ;-) Sorry, 
I'm still catching up on the flood of messages in this thread. It's 
getting late over here, so I think I'll have to reply tomorrow. A brief 
look indicates that probably some bugfixes in math.pure are in order, so 
I'm going to postpone the release until that stuff is sorted out.

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

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

If atan is defined for complex numbers, shouldn't atan2 ? 

e.r.

On Wed, 2008-08-20 at 15:49 -0500, Eddie Rucker wrote:
> Should we have the following rules?
> _+:nan = nan;
> nan+:_ = nan;
> nan<:_ = nan;
> _<:nan = nan;
> 
> My thinking is that if any part of a complex number is nan then the
> whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you
> might want to keep that way for either further processing or to let the
> user know the result is a complex number. What does everyone think about
> this?
> 
> e.r.
> 
> On Wed, 2008-08-20 at 13:31 -0500, Eddie Rucker wrote:
> > Albert,
> > While testing, I looked over some of the logs and here are my
> > suggestions:
> > 
> > Add the rules
> > sqrt inf = inf;
> > sqrt nan = nan;
> > ln inf = inf;
> > ln nan = nan;
> > 
> > Both of these rules also fix
> > acosh and atanh of nan and inf
> > 
> > I think cis is broken for complex numbers. I've got to run give another
> > test.
> > 
> > e.r.
> > 
> > 
> > 
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > pure-lang-users mailing list
> > pur...@li...
> > https://lists.sourceforge.net/lists/listinfo/pure-lang-users
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> pure-lang-users mailing list
> pur...@li...
> https://lists.sourceforge.net/lists/listinfo/pure-lang-users

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

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

On Wed, 2008-08-20 at 16:05 -0500, Eddie Rucker wrote:
> If atan is defined for complex numbers, shouldn't atan2 ? 

Nope. Forget that.

e.r.

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

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

Eddie Rucker wrote:
> While testing, I looked over some of the logs and here are my
> suggestions:

sqrt, ln and the hyp functions should all propely deal with nan and 
+/-inf arguments now. (r557)

> I think cis is broken for complex numbers. I've got to run give another
> test.

cis was never meant to be used with complex arguments. It properly 
checks the type of its argument now (r558).

BTW, Eddie you make my day. Please keep those bug reports rolling. :)

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 Thu, 2008-08-21 at 15:54 +0200, Albert Graef wrote:
> BTW, Eddie you make my day. Please keep those bug reports rolling. :)

About Yesterday. I had to give test after test and I didn't have any reference except my calculator (which doesn't do complex numbers) and what I 
got from the emails to go on when I was checking the test.log on the math libraries. During the time I was giving the test I could look at the logs.
I was in such a hurry checking my mail between tests that I thought you and John were both sending them. The Academic Dean and I didn't even get a 
lunch break yesterday.

I've been in faculty meetings all day today so I haven't had any time to look over anything but I see you've got the main things done. I've got another
in about 20 minutes. I did notice one other thing yesterday but I couldn't track it down without being at my computer,

^ was bombing out somewhere for valid numbers. 

I think 

_^nan = nan;
nan^_ = nan;
inf^inf=inf;
x^inf=inf if x!===nan;
inf^x=inf if x!==nan

needs to be implemented. After, faculty meetings I hope to be able to look for the error with ^.

e.r.

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

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

What about

pow (1+2i) 3;

Sorry, cannot finish my email have to go.

e.r.

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

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

Eddie Rucker wrote:
> What about
> 
> pow (1+2i) 3;

I really shouldn't have opened that can of worms by wrapping the C pow() 
function with Pure's pow. ;-)

I must rethink the purpose of the pow function. It would be silly to 
replicate all functionality we already have with the ^ operator.

In Q pow is just a wrapper for the GMP mpz_pow_ui function, which is 
then extended in rational.q to exact powers of rationals and integers 
with integer exponent. Maybe we should stick to that.

Of course, one can extend that to exact integer powers of complex 
rationals in *polar* notation quite easily, but in rectangular notation 
AFAICS the best you can do is addition-chain exponentiation which only 
works with nonnegative integer exponents and even that needs Theta(log 
n) additions.

That's why I think pow should actually be restricted to the exact 
rational and integer cases, with ^ covering all inexact powers, and 
leave it up to the programmer to extend the former in any manner he 
needs it. At least that was the conclusion we reached when discussing 
this issue in the context of Q.

Comments?

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 Thu, 2008-08-21 at 12:51 -0500, Eddie Rucker wrote:

> ^ was bombing out somewhere for valid numbers. 

After the update not bombing anymore :) 

However, pow does:
 > pow 0 (-1);
 <stdin>:2.0-13: unhandled exception 'signal 8' while evaluating 'pow 0
(-1)'

Did you want to leave this unevaluated or throw an error?
Also, x div 0 throws and error as well?

Should we add the following?

nan^nan = nan;
nan^inf = nan;
pow nan nan = nan;
pow nan inf = nan;

e.r.

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

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

On Thu, 2008-08-21 at 22:37 +0200, Albert Graef wrote:
> That's why I think pow should actually be restricted to the exact 
> rational and integer cases, with ^ covering all inexact powers, and 

> Comments?

Can you believe I actually agree for once? If you wanted to stick with just integers that would be fine with me since ^ deals with everything else.

e.r.

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

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

Eddie Rucker wrote:
> On Thu, 2008-08-21 at 22:37 +0200, Albert Graef wrote:
>> That's why I think pow should actually be restricted to the exact 
>> rational and integer cases, with ^ covering all inexact powers, and 
> 
>> Comments?
> 
> Can you believe I actually agree for once?

Uh oh, I have to mark that date on my calendar. :-P

> If you wanted to stick with just integers that would be fine with me since ^ deals with everything else.

It's useful to have the rational definition as well, because it deals 
with all integer exponents (not just nonnegative ones).

Ok, I committed this now (r561).

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've been in faculty meetings all day today

Oh dear, that sucks. This silly ritual called "meetings" must have been 
invented long ago by non-creative people to terrorize the rest of us, or 
to pretend that they are actually doing something. ;-)

> ^ was bombing out somewhere for valid numbers. 

Yeah, part of that surely is the same issue as with sqrt et al (missing 
nanp check). That should be fixed now (r560).

> _^nan = nan;
> nan^_ = nan;
> inf^inf=inf;
> x^inf=inf if x!===nan;
> inf^x=inf if x!==nan

You surely mean inf^x=inf unless x<0 in which case inf^x=0.0. These 
should all work now, also the -inf cases, except that C pow() insists on 
setting 1.0^x = 1.0 no matter what x is. Also, x^0.0 will always be 1.0. 
I guess that's POSIX behavior, so it should be ok.

Not sure about the complex cases x^(+/-inf) where x<0, but I think that 
these will always return nan+:nan right now. I'm open to suggestions 
there. For finite, non-integral y, (-inf)^y gives inf+:inf or 0+:0, 
depending on whether y>0 or y<0, which looks good to me.

> After, faculty meetings I hope to be able to look for the error with ^.

Please do. Your help with this is really appreciated!

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-...>]

Albert Graef wrote:
> Yeah, part of that surely is the same issue as with sqrt et al (missing 
> nanp check). That should be fixed now (r560).

I should mention that r560 also moves inf, nan and the correpsonding 
predicates to primitives.pure, so that they are available without having 
to load math.pure now.

-- 
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:
>  > pow 0 (-1);
>  <stdin>:2.0-13: unhandled exception 'signal 8' while evaluating 'pow 0
> (-1)'

Yeah, that's just 1 div 0 in disguise there, so it's handled the same 
(see below). Note that GMP's mpz_pow_ui actually raises a SIGFPE in this 
case.

> Did you want to leave this unevaluated or throw an error?
> Also, x div 0 throws and error as well?

Yes, all integer divisions by zero throw a 'signal SIGFPE' exception 
now. In previous releases these would just crap out with an unhandled 
SIGFPE signal generated by the cpu, so this is definitely an improvement. :)

In Q, these return a normal form instead, which gives you the 
opportunity to add your own equations to handle division by zero. But 
this is not possible in Pure (at least not without sacrificing most of 
Pure's arithmetic performance), because integer arithmetic compiles to 
actual machine instructions there.

NB: It would be possible to implement this for the bigint operations as 
these are implemented as calls into the runtime, but I'd rather like 
these to work consistently with the machine int operations. Also, this 
is one of the cases where I think it's not really worth the effort, 
because integer division by 0 almost invariably indicates a serious 
program bug. Finally, note that you can still define x div 0 any way you 
want as long as you're doing symbolic calculations (i.e., x is not an 
integer).

> Should we add the following?
> 
> nan^nan = nan;
> nan^inf = nan;

This already works as of r560.

> pow nan nan = nan;
> pow nan inf = nan;

I'm about to remove the definition of pow on double, it just duplicates 
the functionality of the ^ operator anyway.

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 00:50 +0200, Albert Graef wrote:
> Eddie Rucker wrote:
> > I've been in faculty meetings all day today
> 
> Oh dear, that sucks. This silly ritual called "meetings" must have been 
> invented long ago by non-creative people to terrorize the rest of us, or 
> to pretend that they are actually doing something. ;-)

LOL. I agree completely! The only other thing I might add, It's the
administrator's way of making us pay for summers and holidays ;-)

> You surely mean inf^x=inf unless x<0 in which case inf^x=0.0. These 
> should all work now, also the -inf cases, except that C pow() insists on 
> setting 1.0^x = 1.0 no matter what x is. Also, x^0.0 will always be 1.0. 
> I guess that's POSIX behavior, so it should be ok.

What a moron :-O I'm totally embarrassed? Oh shame shame. If I reached
up right now, I would be too short to touch bottom.

> Not sure about the complex cases x^(+/-inf) where x<0, but I think that 
> these will always return nan+:nan right now. I'm open to suggestions 
> there. For finite, non-integral y, (-inf)^y gives inf+:inf or 0+:0, 
> depending on whether y>0 or y<0, which looks good to me.

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

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

e.r.

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

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

On Fri, 2008-08-22 at 01:42 +0200, Albert Graef wrote:
> Eddie Rucker wrote:

> NB: It would be possible to implement this for the bigint operations as 
> these are implemented as calls into the runtime, but I'd rather like 
> these to work consistently with the machine int operations. Also, this 
> is one of the cases where I think it's not really worth the effort, 
> because integer division by 0 almost invariably indicates a serious 
> program bug. Finally, note that you can still define x div 0 any way you 
> want as long as you're doing symbolic calculations (i.e., x is not an 
> integer).

My judgment sucks as of late, but I say err on the side of consistency.
If 1 div 0 is an error then 1L div 0L should be an error

> I'm about to remove the definition of pow on double, it just duplicates 
> the functionality of the ^ operator anyway.

Yes, there is no reason for duplicated functionality.

e.r.

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

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

Could we move test020 into test014 at a later date as some of this
overlaps.

e.r.

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

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

Eddie Rucker wrote:
> Could we move test020 into test014 at a later date as some of this
> overlaps.

I totally forgot about that one. Actually, I made that from some of Rob 
Hubbard's examples from his Q+Q manual. It's very cursory anyway. I 
think it's ok to just keep them both.

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