Jon Lang wrote:
> Moritz Lenz wrote:
>> Jon Lang wrote:
>>> By the principle of least surprise, I'd recommend against this. Most
>>> programmers, when they see 'sqrt(1)', will expect a return value of 1,
>>
>> And that's what they get unless they write it as sqrt(1 + 0i).
>
> I suppose that you _could_ use the programmer's choice of whether or
> not to use complex numbers in the argument list as the indicator of
> whether to return one answer or a junction of them. Of course, this
> could lead to subtle bugs where the programmer assigns a complex value
> to $x and later takes the sqrt($x), but forgets that he assigned a
> complex number earlier. This may or may not be sufficient grounds for
> requiring an explicit declaration that you want junctions.
If the programmer errs on what he thinks is in a variable, it'll always
be a bug.
>>> and won't want to jump through the hurdles involved in picking '1' out
>>> of 'any(1, -1)'.
>>
>> 1 and -1 aren't just separated by a complex plane, they are really
>> distinct numbers
>
> True enough. I fail to see how that invalidates my point, though: if
> you're going to mess with multiple complex planes, why wouldn't you
> also address the issue of distinct numbers as well?
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) < 0.5 { do something }
I can see the big, fat WTF written in the face of programmer who tries
to debug that code, and doesn't know about junctions. It just won't DTRT.
> The latter issue
> is intimately connected to the former, as I demonstrate below.
>
>>> And even then, I'm concerned that it might very quickly get out of
>>> hand. Consider:
>>>
>>> pow(1, 1/pi() ) :any - 1
>>>
>>> (I think I got that right...)
>>
>> Not quite. Afaict the only functions that might return a junction are
>> Complex.angle and Complex.log.
>
> Why is that?
As I pointed out above it's insane to return a junction of logically
distinct values. It might even be insane to do it for Complex.log:
my $a = (Num::e * 1i).log.angle;
What do you expect $a to be?
Let's see, 1i can be written as exp(1i*(1/2 + 2 *$k) * pi), for Int $k.
So log(Nom::e * 1i) would
1 + any(..., -1.5 * pi, 0.5 * pi, 2.5 * pi, 4.5*pi)*1i
if you imagine this, all these values have re = 1, and lie on a straight
line. So their angle are discrete (but not dense) values between -pi and
+pi. There' no way you can represent that in finite space without a fair
bit of algebra, something we don't want to burden on our implementors.
And somehow I also don't think that meets the "principle of least
surprise" criterion.
I think that I don't have to comment on the rest of the mail to make
clear that Larry's proposal, although being quite interesting, is a very
bad idea to actually implement (and very hard to implement as well)
(unless somebody comes to its rescue with a really clever idea on how to
resolve all these weirdnesses).
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
