Moritz Lenz wrote:
> If the programmer errs on what he thinks is in a variable, it'll always
> be a bug.
Yes; but some bugs are easier to make, and harder to catch, than others.
> 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.
This is closely related to my original point. In particular, if
you're unwilling to have sqrt return junctions of distinct values, you
don't really want to mess with junctions of a single complex value on
different planes, either.
>>>> 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's only insane if the programmer isn't expecting it - which goes
back to my first point of making sure that the programmer explicitly
asked for it before giving it to him.
> It might even be insane to do it for Complex.log:
Agreed: if you are uncomfortable with sqrt(1) returning a junction of
distinct values, then Complex.log should likewise not return a
junction of distinct values.
> 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).
Well... yes and no. Remember, I started off by recommending against
Larry's proposal. I haven't changed my mind, although I think that
it's worth exploring whether or not an alternate treatment of complex
numbers is doable.
--
Jonathan "Dataweaver" Lang
