More on semantics of opPow: return type

[Andrei Alexandrescu]

Bill Baxter wrote:
> 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.

I understand where you're coming from. As an old math teacher would say, 
"this is true but uninteresting". You'd have to prove that that behavior 
of ^^ has some interesting math properties. For starters, you'd need a 
"remainder" for ^^. But then what kind of interesting things can you do 
with such a definition?

Anyway, maybe things could reach an inflection point. Maybe Don will 
find some type trickery for ^^ that's very ingenious and very 
compiler-y. In that case, there would be a strong justification to build 
special rules for ^^ in the compiler instead of building an imperfect 
approximation of it with pow() overloads.


Andrei