I just submitted a bug report (Bug 4455;
http://d.puremagic.com/issues/post_bug.cgi) because std.math doesn't let you
take the square root of an integer w/o an explicit cast.  This has been a
subtle annoyance to me for ages.  Is it ok if I just fix this, or is there
some reason I'm not aware of (i.e. other than a simple oversight) why sqrt()
doesn't already forward integers to sqrt(real)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100713/5bef6cb7/attachment.html>

A related question:  Why do we even have both an sqrt(float) and an
sqrt(real) in the first place?

On Tue, Jul 13, 2010 at 4:58 PM, David Simcha <dsimcha at gmail.com> wrote:

> I just submitted a bug report (Bug 4455;
> http://d.puremagic.com/issues/post_bug.cgi) because std.math doesn't let
> you take the square root of an integer w/o an explicit cast.  This has been
> a subtle annoyance to me for ages.  Is it ok if I just fix this, or is there
> some reason I'm not aware of (i.e. other than a simple oversight) why sqrt()
> doesn't already forward integers to sqrt(real)?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100713/7decde25/attachment.html>

On 13 July 2010 23:00, David Simcha <dsimcha at gmail.com> wrote:
> A related question:? Why do we even have both an sqrt(float) and an
> sqrt(real) in the first place?

Don't know. Originally there was only sqrt(real).
As long as both exist, I don't know how sqrt(int) can be fixed cleanly.

What's wrong w/ adding sqrt(long) and sqrt(ulong) overloads that just
forward to sqrt(real)?  Of course that assumes sqrt(float), which is causing
the problem in the first place, exists for a good reason.

On Tue, Jul 13, 2010 at 5:18 PM, Don Clugston <dclugston at googlemail.com>wrote:

> On 13 July 2010 23:00, David Simcha <dsimcha at gmail.com> wrote:
> > A related question:  Why do we even have both an sqrt(float) and an
> > sqrt(real) in the first place?
>
> Don't know. Originally there was only sqrt(real).
> As long as both exist, I don't know how sqrt(int) can be fixed cleanly.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100713/bc7aae7c/attachment.html>

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.

? Of course that assumes sqrt(float), which is causing
> the problem in the first place, exists for a good reason.


>
> On Tue, Jul 13, 2010 at 5:18 PM, Don Clugston <dclugston at googlemail.com> wrote:
>>
>> On 13 July 2010 23:00, David Simcha <dsimcha at gmail.com> wrote:
>> > A related question:? Why do we even have both an sqrt(float) and an
>> > sqrt(real) in the first place?
>>
>> Don't know. Originally there was only sqrt(real).
>> As long as both exist, I don't know how sqrt(int) can be fixed cleanly.
>> _______________________________________________
>> 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 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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100713/6af0f66b/attachment-0001.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100715/79ff2ab8/attachment.html>

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
>

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().

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?

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