More on semantics of opPow: return type

[Bill Baxter]

On Mon, Dec 7, 2009 at 4:04 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> 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?
>

Negative exponent values are the only ones with an issue.  You can't
even write square-root etc with pow using only integers.  The argument
would have to be a float to even express that, so there is no issue.
int^^float should be a float just like int/float is a float.

So the only things left are those of the form  x^^-y.  or 1/(x^^y).  I
don't see a reason to go any further than translating it to exactly
that.
And that's just division, so the %-like operator corresponding to that
is just % itself ( or rather 1%(x^^y) )

I think Don was creating a tempest in a teapot.  I don't think any of
his proposed alternatives besides treating it as integer division
really make sense.  They are inconsistent with the rest of D, and so
don't merit further consideration unless the behavior of 1/2 is also
on the table.

--bb