Bill Baxter wrote:
On Mon, Dec 7, 2009 at 2:56 PM, Andrei Alexandrescu
<[email protected]> wrote:
Bill Baxter wrote:
On Mon, Dec 7, 2009 at 2:30 PM, Andrei Alexandrescu
<[email protected]> 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
