I think it should work. If the signature changes it just won't be recognized as an intrinsic any more, right?

Sent from my iPhone

On Jul 15, 2010, at 6:22 PM, Don Clugston <dclugston at googlemail.com> wrote:

> On 16 July 2010 01:04, David Simcha <dsimcha at gmail.com> wrote:
>> So is everyone on board for this?  If not, please say something.  Otherwise I'll make the changes.
> 
> It won't work. sqrt is a compiler intrinsic, and can't be changed to a template without modifying the compiler.
> 
>> 
>> On 7/13/2010 6:12 PM, David Simcha wrote:
>> 
>> This is probably the way to go, though I really wish the bug that prevents overloading functions against templates would get fixed so it wouldn't mean that the floating point case would have to be templated, too.
>> 
>> On Tue, Jul 13, 2010 at 5:48 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
>>> 
>>> On 07/13/2010 04:46 PM, Don Clugston wrote:
>>>> 
>>>> On 13 July 2010 23:25, David Simcha<dsimcha at gmail.com>  wrote:
>>>>> 
>>>>> What's wrong w/ adding sqrt(long) and sqrt(ulong) overloads that just
>>>>> forward to sqrt(real)?
>>>> 
>>>> Doesn't work -- it's ambiguous for ints.
>>>>  You need an explicit specialisation for every type: byte, ubyte,
>>>> short, ushort, int, uint, long, ulong.
>>>> Yuck.
>>> 
>>> Or templates that dispatch using constraints.
>>> 
>>> Andrei
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> 
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 7/15/2010 11:04 PM, Sean Kelly wrote:
> I think it should work. If the signature changes it just won't be recognized as an intrinsic any more, right?
> 

But how do you forward to the intrinsic?  I assume it's hard-coded in the compiler that this has to be named sqrt(), so you need to have a function called sqrt() around, and you can't overload functions against templates.

On Jul 15, 2010, at 8:56 PM, David Simcha wrote:

> On 7/15/2010 11:04 PM, Sean Kelly wrote:
>> I think it should work. If the signature changes it just won't be recognized as an intrinsic any more, right?
>> 
> 
> But how do you forward to the intrinsic?  I assume it's hard-coded in the compiler that this has to be named sqrt(), so you need to have a function called sqrt() around, and you can't overload functions against templates.
> 

Oh, I see.  That's what I get for not reading the entire thread.

On 16 July 2010 04:16, David Simcha <dsimcha at gmail.com> wrote:
> On 7/15/2010 9:22 PM, Don Clugston wrote:
>>
>> On 16 July 2010 01:04, David Simcha<dsimcha at gmail.com> ?wrote:
>>
>>>
>>> So is everyone on board for this? ?If not, please say something.
>>> ?Otherwise
>>> I'll make the changes.
>>>
>>
>> It won't work. sqrt is a compiler intrinsic, and can't be changed to a template without modifying the compiler.
>
> (Smacks hand against forehead.) ?I realized that right after I sent that message. ?I guess the options are, then:
>
> 1. ?Modify the compiler. ?I guess the easiest way would be to rename the
> sqrt() intrinsic to sqrtImpl() and have a function called sqrt() in std.math
> that forwards to sqrtImpl().

I think __sqrt() would be a better name. I'd recommend renaming sin()
and cos() at the same time, since the intrinsics are hopelessly
inaccurate for large arguments.

>
> 2. ?Live with it for now. ?It's an extremely annoying bug in that math-heavy code runs into it constantly, but it's an easy bug to work around.
>
> 3. ?Get rid of sqrt(float). ?Walter, or whoever put it there in the first place: ?Why is it there? ?Do we really need it?

It makes no difference to the generated x87 code. It does affect type inference, but it's not adding much value.

>
> 4. ?Make explicit overloads for every single numeric type. ?This is ugly but do-able and would definitely be a 100% solution.

Note that the same issue applies to all std.math functions, although sqrt() might be the only one that is truly annoying.

On Fri, 2010-07-16 at 07:32 +0200, Don Clugston wrote:
> On 16 July 2010 04:16, David Simcha <dsimcha at gmail.com> wrote:
> > On 7/15/2010 9:22 PM, Don Clugston wrote:
> >>
> >> On 16 July 2010 01:04, David Simcha<dsimcha at gmail.com>  wrote:
> >>
> >>>
> >>> So is everyone on board for this?  If not, please say something.
> >>>  Otherwise
> >>> I'll make the changes.
> >>>
> >>
> >> It won't work. sqrt is a compiler intrinsic, and can't be changed to a template without modifying the compiler.
> >
> > (Smacks hand against forehead.)  I realized that right after I sent that message.  I guess the options are, then:
> >
> > 1.  Modify the compiler.  I guess the easiest way would be to rename the
> > sqrt() intrinsic to sqrtImpl() and have a function called sqrt() in std.math
> > that forwards to sqrtImpl().
> 
> I think __sqrt() would be a better name. I'd recommend renaming sin()
> and cos() at the same time, since the intrinsics are hopelessly
> inaccurate for large arguments.
> 
> >
> > 2.  Live with it for now.  It's an extremely annoying bug in that math-heavy code runs into it constantly, but it's an easy bug to work around.
> >
> > 3.  Get rid of sqrt(float).  Walter, or whoever put it there in the first place:  Why is it there?  Do we really need it?
> 
> It makes no difference to the generated x87 code. It does affect type inference, but it's not adding much value.
> 
> >
> > 4.  Make explicit overloads for every single numeric type.  This is ugly but do-able and would definitely be a 100% solution.
> 
> Note that the same issue applies to all std.math functions, although sqrt() might be the only one that is truly annoying.


The math functions are all evaluated at maximum precision anyway, aren't they?  Wouldn't it then make sense to remove all overloads except the ones that take real arguments?  That would have the added benefit of making said fact (provided it is a fact) very explicit.

-Lars