pure-lang-users — Discussion of the Pure programming language.

Re: [pure-lang-users] Debian (and Gentoo?) distribution

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

David Baird wrote:
> I am still planning to work on it

That would be great. As you can see nobody else has volunteered yet. :)

> I'm also not yet certain if I will run into complexities with LLVM
> (like, having to create a custom package for LLVM just to be
> compatible with Pure).  Hopefully not *crosses fingers*.

Building LLVM (the core libraries at least, and that is all that's 
needed for Pure) and Pure itself is rather simple and well-documented in 
Pure's INSTALL file. Also note that in fact LLVM 2.3 is only a build 
requirement (those LLVM libraries that Pure links against are all 
static). But of course if you do a Debian source package then you need 
to provide packages for all build requirements, too.

There's one small complication with LLVM on x86-64 bit systems only, it 
needs a patch there for making the LLVM libs link into libpure.so. But 
that's also described in Pure's INSTALL file and the patch is readily 
available from the Pure website.

Pure you just configure as './configure --prefix=/usr --enable-release', 
then run make and make install, that's it. (You can use 'make install 
DESTDIR=/my/staging/directory' to install into a build root as usual.)

There might be some smaller glitches if you compile with gcc 4.3, but 
they should be easy to fix.

If you have any additional questions about the build process just ask.

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 pilfered that definition from a paper I found on Internet.

Ah yes, I remember that now. But that definition just didn't work, I 
noticed that when testing some of the complex trig functions.

> However, why didn't you use Kahan's suggestion for sqrt?
> sqrt z = exp (0.5 * ln z);

In fact, if you look at the formulas, that's just what my definition 
does in the rectangular case, although it uses the real sqrt instead of 
exp(0.5*ln _) to compute the square root of abs z, which saves one 
expensive operation.

In the polar case, it's of course much faster to just halve arg z and 
take the real sqrt of abs z which are both readily available. That 
appears to have the branch cut in the right place, too.

 > Well, the Mathworld definition for actanh z didn't even give correct 
results comapred to the Common Lisp version.

The Mathworld definition of atanh *is* the one suggested by Kahan, which 
is also the one I use, and I can assure you that it works very well. :) 
I tested all of these functions quite extensively against my HP 50G, 
which supposedly still runs the numeric algorithms orginally designed by 
Kahan for HP. Maybe you accidentally tried the first, bogus formula for 
atanh given in the CL document?

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] Yet another quirk with MinGW

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

On Sat 23/08/08  9:41 PM , Albert Graef Dr....@t-... sent:
> Just a quick note: test020.pure fails on Windows due to broken pow()
> and 
> atan2() routines in the MS C library, which give nan's when they 
> shouldn't in a few cases (I've attached the diffs of the test log
> for 
> reference).
> Of course. What did I expect? :)

I guess they shoot from the hip kinda like I was last week :-( 
I promise to do better when I get on the GSL library! I just need to take my time and think things through.

e.r.
 

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

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

On Sat 23/08/08  8:27 AM , Albert Graef Dr....@t-... sent:
> Albert Graef wrote:
> Ok, I did some minor cosmetic surgery to the complex trigs and hyps, 
> actually most of my definitions (originally pilfered from Bronstein) 
> seemed to be pretty much in line with that document already. I also 
> fixed up my completely nonsensical complex sqrt definition, wonder how 
> that slipped in. ;-)

I pilfered that definition from a paper I found on Internet. It is actually the same definition as the one you
gave but they used the half angle identities cos (t/2) = +-sqrt (1+cos t) / 2 and sin (t/2) = +-sqrt (1-cos t) / 2
to derive it. As soon as I can find that link I again I will send it to you. I suspect I left out a 
sign function for the imaginary part.

However, why didn't you use Kahan's suggestion for sqrt?
sqrt z = exp (0.5 * ln z);
or even 
sqrt z = z ^ 0.5;

It's prettier to look at ;-)

> What still remains to be done is to add some type guards on the mixed 
> real/complex rules, so that we can later (when Eddie's GSL module 
> materializes) overload the common operators for scalar+vector/matrix 
> kind of stuff.

I'm going to act on this real soon.

> One thing that keeps me wondering is Kahan's suggestion for the acosh:
> 
> acosh z@(x+:y)	|
> acosh z@(r<:t)	= 2*ln (sqrt ((z+1)/2)+sqrt ((z-1)/2));
> 
> This is the definition I currently use (from Mathworld):
> 
> acosh z@(x+:y)	|
> acosh z@(r<:t)	= ln (z+sqrt (z-1)*sqrt (z+1));


> This has the same branch cut (-inf,1), and seems to yield the same 
> results AFAICT (up to rounding of course). Kahan's definition looks more
> complicated and requires more operations, but given that Kahan wrote it,
> I guess that there must be some reason he wrote it that way. ;-)
> 
> So can anyone think of a reason why one might prefer Kahan's definition?
> Numerical stability maybe?

Well, the Mathworld definition for actanh z didn't even give correct results comapred to the Common Lisp version.
 I'm just guessing here but as we well know the actual math definition is not always the best to use for floating 
point. I don't have the means to test it right now but I bet that sqrt ((z+1)/2)+sqrt ((z-1)/2 gives better results 
than z+sqrt (z-1)*sqrt (z+1) when either the real part or the imaginary part is either really small or really big.
Again, I'm just guessing.
 

Re: [pure-lang-users] Debian (and Gentoo?) distribution

[David B. <dh...@gm...>]

On Sun, Aug 24, 2008 at 3:39 PM, Albert Graef <Dr....@t-...> wrote:
> Albert Graef wrote:
>> David Baird wrote:
>>> It doesn't seem that anyone has yet taken up an effort to get Pure or
>>> Q into the official Debian package lists.  So, unless someone else has
>>> a special interest, I was thinking of volunteering to be a package
>>> maintainer and seek out a sponsor [1] to get the packages into Debian
>>> (and hopefully propagate into Ubuntu too...?).
>>
>> That would be much appreciated! (You'd probably need to get the LLVM
>> debs updated, too, IIRC they're quite old.)
>
> Did anything come out of this so far? Sorry to be so insistent, but now
> that with Pure 0.5 a reasonably bug-free and complete implementation is
> out, it would *really* be nice if someone would tackle the Debian
> packages. If David cannot do it, is there someone else here proficient
> enough with the Debian packaging system to pull it off? I cannot do it
> myself, since I don't run Debian.

I am still planning to work on it, but if someone else wants to take
it up, then that would be great too.  No problem about being
insistent.  Coaxing usually does for good to me than bad.

My current status is that I have got a Debian chroot up and running (I
need a chroot since I usually am running on Ubuntu and sometimes
Gentoo).  I think the next step (that I haven't done yet) is to start
mapping out the dependences, writing the Debian control files, and get
the build process figured out.  Then the next step after that is to
find a sponsor within Debian who will incorporate the package into
Debian.

I'm also not yet certain if I will run into complexities with LLVM
(like, having to create a custom package for LLVM just to be
compatible with Pure).  Hopefully not *crosses fingers*.

-David

Re: [pure-lang-users] Debian (and Gentoo?) distribution

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

Albert Graef wrote:
> David Baird wrote:
>> It doesn't seem that anyone has yet taken up an effort to get Pure or
>> Q into the official Debian package lists.  So, unless someone else has
>> a special interest, I was thinking of volunteering to be a package
>> maintainer and seek out a sponsor [1] to get the packages into Debian
>> (and hopefully propagate into Ubuntu too...?).
> 
> That would be much appreciated! (You'd probably need to get the LLVM 
> debs updated, too, IIRC they're quite old.)

Did anything come out of this so far? Sorry to be so insistent, but now 
that with Pure 0.5 a reasonably bug-free and complete implementation is 
out, it would *really* be nice if someone would tackle the Debian 
packages. If David cannot do it, is there someone else here proficient 
enough with the Debian packaging system to pull it off? I cannot do it 
myself, since I don't run Debian.

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] Prefix operator and -1

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

David Baird wrote:
> I have a quite Pure (0.4) question.  This is what I want, but in
> prefix-form not infix-form:
> 
>     > -1*A;
>     -1*A

I don't understand. Do you want "1 multiplied by A negated" or "1 
negated, multiplied by A"? -(1*A) will give you the former, (-1)*A the 
latter (in either Pure or Q). Or you can write it with an explicit 
application of the unary minus operator, which is available as the 'neg' 
function in Pure ('minus' in Q):

   > neg (1*A);
   -1*A
   > (neg 1)*A;
   (-1)*A

Note that in Pure unary minus always has the same precedence as binary 
minus, whereas in Q unary minus has higher precedence than all the infix 
operators. Therefore, -1*A is actually -(1*A) in Pure, whereas it 
denotes (-1)*A in Q.

Usually this difference doesn't really matter, but of course here it 
does. The rationale behind Pure's syntax is that unary minus has the 
right precedence no matter what the precedence of binary minus (which 
you can change freely in the prelude) happens to be. Also, it's 
compatible with mathematical notation, Haskell, Pascal and a bunch of 
other languages (not C though, C has the unary operators at a higher 
precedence level, like Q does).

HTH,
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

[pure-lang-users] Prefix operator and -1

[David B. <dh...@gm...>]

Hi,

I have a quite Pure (0.4) question.  This is what I want, but in
prefix-form not infix-form:

    > -1*A;
    -1*A

I tried a couple of other possibilities, but without success:

    > (*) (-1) A;
    (-1)*A

    > (*) -1 A;
    (*)-1 A

For comparison, this is what I get with Q:

    ==> -1 * A;
    -1*A

    Yay!
    ==> (*) (-1) A;
    -1*A

    ==> (*) -1 A;
    (*)-1 A

-David

[pure-lang-users] ANN: Pure 0.5 released

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

Hi everybody,

Pure 0.5 is out, grab it here while it's hot:
http://sourceforge.net/project/showfiles.php?group_id=226193

Also have a look at the release notes to find out what's new:
http://sourceforge.net/project/shownotes.php?group_id=226193&release_id=621635 


Executive summary: This release sports LLVM 2.3 support and a bunch of 
bug fixes and improvements in the language, the standard library and the 
code generator. I.e.: lots of good new stuff, a must have! :)

Special thanks are due to Jiri Spitz who ported the Q container data 
structures to Pure, and to Rooslan S. Khayrov for his patches to make 
Pure work with LLVM 2.3.

Thanks also to Alvaro Castro Castilla, Toni Graffy and Ryan Schmidt for 
maintaining the Gentoo, openSUSE and MacPorts packages, respectively. I 
hope you'll find the time to update the packages for the latest release 
asap. ;-)

More acknowledgments can be found in the release notes. Also, make sure 
you don't miss Libor Spacek's Mayan calendar counting the days until 
doomsday, err, end of the cycle, and his faster-than-light n-queens 
algorithm. (To be found in examples/libor in the sources.)

Last but not least, the new math.pure standard library module turns Pure 
into a useful desktop calculator. Thanks to Eddie Rucker for helping 
testing that beast, and to John Cowan for pointing me to the right bits 
of IEEE 754 arcana!

Enjoy!
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] Yet another quirk with MinGW

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

Albert Graef wrote:
> This is all in svn now, so I guess it's release time. :) A bit late 
> tonight, but tomorrow...

Just a quick note: test020.pure fails on Windows due to broken pow() and 
atan2() routines in the MS C library, which give nan's when they 
shouldn't in a few cases (I've attached the diffs of the test log for 
reference).

Of course. What did I expect? :)

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] Yet another quirk with MinGW

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

> Well, I had to fiddle with the output format some more, since 'make 
> check' would fail on this test due to (more or less) small rounding 
> discrepancies between systems. ("Almost zero" values are particularly 
> nasty.) Therefore I'm rounding floating point numbers to 3 significant 
> digits now, I hope that this is good enough. The latest log can be found 
> here:
> 
> http://pure-lang.svn.sourceforge.net/viewvc/pure-lang/pure/trunk/test/test020.log

If you want to give a helping hand checking some of the results, it's 
actually easier to just run test020.pure interactively yourself. That 
also gives you the opportunity to rerun the tests after changing the 
printed precision of results, like so:

let double_format = "%#0.6g"; tests;

In the meantime I also checked some of the complex operations manually 
against my HP-50G calculator, whose numeric algorithms are based on 
earlier HP calculator software designed by William Kahan, so they should 
be pretty much standard. ;-) All bad branch cuts I noticed are corrected 
now, so that math.pure now shows pretty much the same results as the 
calculator (up to rounding). That gives me some confidence that the 
definitions in math.pure actually work now. :)

I also added the type guards necessary to ensure that symbolic terms 
involving these operations are irreducible, so that all math.pure 
functions and operators can be extended as necessary later.

This is all in svn now, so I guess it's release time. :) A bit late 
tonight, but tomorrow...

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:
> John Cowan wrote:
>> Here is the Common Lisp discussion of where the branch cuts of the
>> transcendental functions are: http://tinyurl.com/5rbsng .
> 
> Thanks a bunch for that link, that should help me to revise the complex 
> stuff in math.pure.

Ok, I did some minor cosmetic surgery to the complex trigs and hyps, 
actually most of my definitions (originally pilfered from Bronstein) 
seemed to be pretty much in line with that document already. I also 
fixed up my completely nonsensical complex sqrt definition, wonder how 
that slipped in. ;-)

What still remains to be done is to add some type guards on the mixed 
real/complex rules, so that we can later (when Eddie's GSL module 
materializes) overload the common operators for scalar+vector/matrix 
kind of stuff.

One thing that keeps me wondering is Kahan's suggestion for the acosh:

acosh z@(x+:y)	|
acosh z@(r<:t)	= 2*ln (sqrt ((z+1)/2)+sqrt ((z-1)/2));

This is the definition I currently use (from Mathworld):

acosh z@(x+:y)	|
acosh z@(r<:t)	= ln (z+sqrt (z-1)*sqrt (z+1));

This has the same branch cut (-inf,1), and seems to yield the same 
results AFAICT (up to rounding of course). Kahan's definition looks more 
complicated and requires more operations, but given that Kahan wrote it, 
I guess that there must be some reason he wrote it that way. ;-)

So can anyone think of a reason why one might prefer Kahan's definition? 
Numerical stability maybe?

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:
> Well, my definition of complex (^) of course computes all powers in 
> polar representation (and then converts them back to rectangular if 
> needed).

This is actually overkill, so I'm just using the plain ol' x^y = exp(ln 
x*y) now (after converting x to complex if necessary), that works just 
fine, computes the principle values and also treats the corner cases 
correctly. Problem solved. :)

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

John Cowan wrote:
> Here is the Common Lisp discussion of where the branch cuts of the
> transcendental functions are: http://tinyurl.com/5rbsng .

Thanks a bunch for that link, that should help me to revise the complex 
stuff in math.pure.

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 have to go out of town this weekend but I'll definately get back with you on Monday. 

Don't bother, I should be able to figure that out on my own. :) I still 
have hopes that I can get Pure 0.5 out on the weekend, so that I can 
continue working on other stuff (macros etc.).

> No problem, although it might be nice for pow (0+:0) 0 => 1. Just wolfing don't throw tomatoes at me ;-)

Yes, but for reasons discussed earlier pow is only defined for integer 
and rational bases now. Those are the only cases for which I can readily 
compute exact results for all integer exponents. Of course everybody's 
free to extend pow as they see fit in their own programs.

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:
> LOL! I noticed atanh is not defined in mzscheme so had to look it up.
> (define (atanh x) (* .5 (log (/ (+ 1.0 x) (- 1.0 x)))))

Beware, that definition gives you a +nan.0+nan.0i for x = 1.0+0.0i. Pure 
gets this right:

   > atanh 1, atanh (-1);
   inf,-inf
   > atanh (1+:0), atanh (-1+:0);
   inf+:0.0,-inf+:0.0

It will also compute the required complex result for atanh (-2), but of 
course in the latest revision you have to tell it that you want a 
complex result:

   > atanh (-2);
   nan
   > atanh (-2+:0);
   -0.549306144334055+:1.5707963267949

> Very good point! Hmmm... I guess this is another good reason for not duplicating the functionality of ^ and pow.
> (-8+0i)^(1%3) = 1.0000000000000002+:1.7320508075688772

Well, my definition of complex (^) of course computes all powers in 
polar representation (and then converts them back to rectangular if 
needed). As the polar representation is normalized to the (-pi,pi] phase 
range automagically (see the constructor equations for (<:) in 
math.pure), it will always give you the principal roots without any ado.

In fact, the definition I have does work pretty well, it's just a few 
corner cases with integer exponents that are causing me grief. Well, if 
nothing else helps I'll just have to add a few special case rules, but I 
thought it would be nice to put it all in a closed formula. ;-)

> pow (-8) (1%3) = -2

You must be running an old revision there, pow is only defined for 
integer exponents now.

> I noticed in mzscheme,
>   > (expt -8 1/3)
>   1

I don't get that here (mzscheme v372, running on 32 bit Linux), it gives 
me the proper result:

   > (expt -8 1/3)
   1.0000000000000002+1.7320508075688772i

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

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

Eddie Rucker scripsit:

> LOL! I noticed atanh is not defined in mzscheme so had to look it up.
> (define (atanh x) (* .5 (log (/ (+ 1.0 x) (- 1.0 x)))))

Here is the Common Lisp discussion of where the branch cuts of the
transcendental functions are: http://tinyurl.com/5rbsng .  It claims
that the correct function is:

(define (atanh z) (log (* (+ 1 z) (sqrt (- 1 (/ 1 (expt z 2)))))))

Clisp reports #C(-0.54930615 1.5707964) for (atanh -2).

-- 
We pledge allegiance to the penguin             John Cowan
and to the intellectual property regime         co...@cc...
for which he stands, one world under            http://www.ccil.org/~cowan
Linux, with free music and open source
software for all.               --Julian Dibbell on Brazil, edited

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

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

On Fri 22/08/08  5:34 PM , John Cowan co...@cc... sent:
> Eddie Rucker scripsit:
> 
> > The user must determine the domain they are
> going work in. No different> than working with OCaml.
> 
> A running joke was an acceptance test for nascent Common Lisp
> implementations developed by Guy Steele. It was in three
> parts. First you type T; if it responds T, it passes part
> 1. Second, you define the factorial function and then calculate
> (/ (factorial 1000) (factorial 999)).  If it responds 1000,
> it passes part 2. Third, you try (atanh -2). If it returns
> a complex number, it passes; extra credit if it returns the
> correct complex number. It was a long time before any Common
> Lisp implementation passed the third part.
> --Steele and Gabriel, "The Evolution of Lisp"

LOL! I noticed atanh is not defined in mzscheme so had to look it up.
(define (atanh x) (* .5 (log (/ (+ 1.0 x) (- 1.0 x)))))

> Common Lisp: The Language lays down explicitly that (expt -8 1/3) must
> not return -2, as -2 is not the *principal* cube root of -8; instead it
> should return #C(1.0 1.7320508).

Very good point! Hmmm... I guess this is another good reason for not duplicating the functionality of ^ and pow.
(-8+0i)^(1%3) = 1.0000000000000002+:1.7320508075688772
pow (-8) (1%3) = -2

I noticed in mzscheme,
  > (expt -8 1/3)
  1
  > (expt (expt -8 1/3) 2)
  -1.9999999999999991+3.4641016151377553i
  > (expt (expt -8 1/3) 3)
  -8.0+3.1086244689504383e-015i

Compare with 1 + i sqrt(3), -2 + 2 sqrt 3, and -8.

e.r.
 

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

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

Eddie Rucker scripsit:

> The user must determine the domain they are going work in. No different
> than working with OCaml.

	A running joke was an acceptance test for nascent Common Lisp
	implementations developed by Guy Steele. It was in three
	parts. First you type T; if it responds T, it passes part
	1. Second, you define the factorial function and then calculate
	(/ (factorial 1000) (factorial 999)).  If it responds 1000,
	it passes part 2. Third, you try (atanh -2). If it returns
	a complex number, it passes; extra credit if it returns the
	correct complex number. It was a long time before any Common
	Lisp implementation passed the third part.
		--Steele and Gabriel, "The Evolution of Lisp"

Common Lisp: The Language lays down explicitly that (expt -8 1/3) must
not return -2, as -2 is not the *principal* cube root of -8; instead it
should return #C(1.0 1.7320508).

-- 
They tried to pierce your heart                 John Cowan
with a Morgul-knife that remains in the         http://www.ccil.org/~cowan
wound.  If they had succeeded, you would
become a wraith under the domination of the Dark Lord.         --Gandalf

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

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

On Fri 22/08/08  5:01 PM , Albert Graef Dr....@t-... sent:
> Eddie Rucker wrote:

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

The user must determine the domain they are going work in. No different than working with OCaml.

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

I have to go out of town this weekend but I'll definately get back with you on Monday. 

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

No problem, although it might be nice for pow (0+:0) 0 => 1. Just wolfing don't throw tomatoes at me ;-)

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:
> 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

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

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

e.r.