More on semantics of opPow: return type

[Bill Baxter]

On Mon, Dec 7, 2009 at 2:56 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Bill Baxter wrote:
>>
>> On Mon, Dec 7, 2009 at 2:30 PM, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>> Lars T. Kyllingstad wrote:
>>>>
>>>> The fundamental reason why I want opPow so badly is in fact not even how
>>>> often I use it. If that was the case, I'd want a special "writefln"
>>>> operator
>>>> as well. The main reason is that exponentiation is such a basic
>>>> mathematical
>>>> operation, right up there with addition and multiplication, that it
>>>> deserves
>>>> an operator of its own.
>>>
>>> Hmmm. Addition, subtraction, multiplication, and division with remainder
>>> are
>>> all closed over integers. Power isn't. It's not even closed over real
>>> numbers. That makes it quite special and quite non-basic.
>>
>> Uh, but a/b is not a "division with remainder" operator.  It's just
>> division-with-a-remainder-silently-ignored.
>
> The result of a/b is the quotient resulting from a division with remainder.
> If you want the remainder use a%b (the compiler will peephole-optimize
> that). I don't see anything wrong with what I said.
>
>> If you want to define pow in the same way as a "pow with remainder but
>> with the remainder ignored" then there's nothing stopping you.
>>
>>    1^^-1 == 1
>>    2^^-1 == 0
>>    4^^(1/2) == 2
>>    5^^(1/2) == 2
>>
>> Though I'd rather go the other direction and make the
>> remainder-dropping integer division use a different symbol a la
>> Python.
>
> You'd need to show that "power with remainder" as you just defined it is
> useful theoretically and/or practically. The usefulness of integral division
> is absolutely massive.
>
> Anyhow, all I did was to explain that a particular argument that was made is
> invalid. That doesn't mean other arguments are invalid. All I'd hope is that
> ^^ doesn't suddenly become a time sink when we have so much other stuff to
> worry about. Again: ^^ was a lot more attractive to me when it seemed like a
> slam dunk.

Seriously, I thought the above behavior would be what you'd get using
integer arguments with opPow by analogy with how opDiv behaves.  I
wasn't expecting there would be any debate about it.  I think the
feeling that 2^^-1 is not 0 is the same gut feeling that tells all
programming newbies that 1/2 should not be 0.  But truncating down to
the nearest int was the decision made long ago, so we stick with it.
But languages like python that cater to newbie programmers are now
trying to do something about it by making the difference between
truncated integer division and division explicit.  I don't really
think D is going to go down that route at this late date, so we should
just try to be self-consistent.  Which to me says  1/2 and 2^^-1
should give the same result.

--bb