Code speed

[Lars T. Kyllingstad]

Don wrote:
> Lars T. Kyllingstad wrote:
>> Don wrote:
>>> bearophile wrote:
>>>> So far I've just given a light reading of the code. Notes:
>>>
>>>> - pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 (but 
>>>> you have to import std.math anyway, because of a bug).
>>>
>>> That's not a bug. It's intentional. x ^^ y will probably always 
>>> require import std.math, if y is a floating point number.
>>
>> Really?  Why is that?  I find that kind of disappointing, I always 
>> believed it to be a temporary solution.
>>
>> I think the inconsistency with the other operators will make this a 
>> major WTF for people new to the language.  Why should a^^b require an 
>> explicit import while a*b doesn't?
> 
> Because pow() for floating point, when implemented properly, is a HUGE 
> function, that ends up dragging almost all of std.math into the 
> executable. And I think it's deceptive to do that silently.
> To make it completely built-in, basically all of std.math would need to 
> be moved into druntime. Feel free to try to change my mind, of course.

Exponentiation is a built-in operation in FORTRAN, so I made this little 
program to check:

       program test

       implicit none
       real  :: base, expo, pow

       write (*,*) "Base:"
       read  (*,*) base
       write (*,*) "Exponent:"
       read  (*,*) expo

       pow = base**expo
       write (*,*) pow

       end program test

The produced executable is 11K.  If I replace exponentiation with 
multiplication, it is still 11K.  Why wouldn't the same be possible in D?

Note that I'm not trying to argue with you, I am sure you know what 
you're talking about.  I know very little of what's going on under the 
hood of either compiler, so I'm asking out of curiosity.


>> If the language made it possible to overload operators using free 
>> functions, I wouldn't mind if opBinary!"^^"(float, float) was 
>> implemented in std.math.  The way it is now, it's a halfway built-in, 
>> halfway library feature, and just seems halfway altogether.
> 
> You can expect the integration to become cleaner; still, it's a 
> compromise. It was a big fight to get it into the language at all, and 
> I've tried to minimize the cost of it. ^^ is basically syntax sugar, and 
> the price you pay for the additional tiny bit of syntax sugar (avoiding 
> import std.math) has an appalling cost-benefit ratio.
> 
> Raising to a float power is really a niche feature. Are there really 
> many uses for ^^ of floats, where std.math isn't imported already (for 
> example, where you don't even use abs()) ?

It's the inconsistency with the other operations on built-in types that 
bothers me, not the hassle of writing 'import std.math'.

But please don't get me wrong, I absolutely prefer the current solution 
over nothing.  Now that I've gotten used to it I'm never going back. :)

For fun I grepped my numerics library for uses of ^^, and found I've 
used it >65 times (65 is the line count, and it's used twice in some 
lines).  And let it be known that the majority of the cases are 
float^^float! ;)

-Lars