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


Moritz Lenz |

Reply via email to