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