phobos commit, revision 1833


user: dsimcha

msg:
Bug 4455:  Taking the sqrt of an integer shouldn't require an explicit cast.

http://www.dsource.org/projects/phobos/changeset/1833

Do we really want the sqrt of a integer to return a real?
I would expect it to return floor(sqrt(n)), in the same way that integer
division does.
What do other people think/expect?

Daniel.

On Thu, Aug 12, 2010 at 12:43 PM, dsource.org <noreply at dsource.org> wrote:

> phobos commit, revision 1833
>
>
> user: dsimcha
>
> msg:
> Bug 4455:  Taking the sqrt of an integer shouldn't require an explicit
> cast.
>
> http://www.dsource.org/projects/phobos/changeset/1833
>
> _______________________________________________
> 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/20100812/4b4d5fe5/attachment.html>

On Wednesday 11 August 2010 23:40:17 Daniel Murphy wrote:
> Do we really want the sqrt of a integer to return a real?
> I would expect it to return floor(sqrt(n)), in the same way that integer
> division does.
> What do other people think/expect?


That seems rather limiting. Don't you usually want a floating point value from sqrt? If you want an int, you can just cast the result. Otherwise, you're going to have to cast the ints that you pass to sqrt() in order to get a floating value result, which would tend to be even more annoying - particularly since I would expect the programmer to want a floating point result normally anyway. On top of that, because an int value can be held just fine in a floating point, making sqrt() return an int could easily cause bugs where someone expects it to return a floating value and assigns it to a floating value. The assignment works just fine, but they never get the result that they expect, and they may have a hard time tracking down such a bug.

If it returns a real, then it does what I would expect most people to want, and if you want an int, you have to cast it. It's nice and clear, and you don't have errors due to something being a type that you don't expect.

- Jonathan MDavis

I would be very disappointed if I type sqrt(2) and get 1.

-Lars


On Thu, 2010-08-12 at 16:40 +1000, Daniel Murphy wrote:
> Do we really want the sqrt of a integer to return a real?
> I would expect it to return floor(sqrt(n)), in the same way that
> integer division does.
> What do other people think/expect?
> 
> 
> Daniel.
> 
> On Thu, Aug 12, 2010 at 12:43 PM, dsource.org <noreply at dsource.org>
> wrote:
>         phobos commit, revision 1833
> 
> 
>         user: dsimcha
> 
>         msg:
>         Bug 4455:  Taking the sqrt of an integer shouldn't require an
>         explicit cast.
> 
>         http://www.dsource.org/projects/phobos/changeset/1833
> 
>         _______________________________________________
>         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

The logic here was that, really, the cast to real should be implicit, but using implicit casts would be ambiguous, so I created an explicit sqrt() for every integer type that explicitly casts to real.

On 8/12/2010 3:39 AM, Jonathan M Davis wrote:
> On Wednesday 11 August 2010 23:40:17 Daniel Murphy wrote:
> 
>> Do we really want the sqrt of a integer to return a real?
>> I would expect it to return floor(sqrt(n)), in the same way that integer
>> division does.
>> What do other people think/expect?
>> 
>
> That seems rather limiting. Don't you usually want a floating point value from sqrt? If you want an int, you can just cast the result. Otherwise, you're going to have to cast the ints that you pass to sqrt() in order to get a floating value result, which would tend to be even more annoying - particularly since I would expect the programmer to want a floating point result normally anyway. On top of that, because an int value can be held just fine in a floating point, making sqrt() return an int could easily cause bugs where someone expects it to return a floating value and assigns it to a floating value. The assignment works just fine, but they never get the result that they expect, and they may have a hard time tracking down such a bug.
>
> If it returns a real, then it does what I would expect most people to want, and if you want an int, you have to cast it. It's nice and clear, and you don't have errors due to something being a type that you don't expect.
>
> - Jonathan MDavis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
> 

Daniel Murphy wrote:
> Do we really want the sqrt of a integer to return a real?
> I would expect it to return floor(sqrt(n)), in the same way that
> integer division does.
> What do other people think/expect?
>
> Daniel.
>

I don't think x86 has an int sqrt op so under the covers, int->int is going to end up being "cast(int)sqrt(cast(real)a)" Asking the user to tack in the first cast should have no perf issues and I expect would be what people want more often than the reverse.