sqrt(2) must go

Robert Jacques sandford at jhu.edu
Wed Oct 19 20:45:37 PDT 2011


On Wed, 19 Oct 2011 23:01:34 -0400, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques <sandford at jhu.edu>
> wrote:
>
>> On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise <Marco.Leise at gmx.de>
>> wrote:
>>> Am 20.10.2011, 02:46 Uhr, schrieb dsimcha <dsimcha at yahoo.com>:
>>>
>>>> On 10/19/2011 6:25 PM, Alvaro wrote:
>>>>> El 19/10/2011 20:12, dsimcha escribió:
>>>>>> == Quote from Don (nospam at nospam.com)'s article
>>>>>>> The hack must go.
>>>>>>
>>>>>> No. Something as simple as sqrt(2) must work at all costs, period. A
>>>>>> language
>>>>>> that adds a bunch of silly complications to something this simple is
>>>>>> fundamentally
>>>>>> broken. I don't remember your post on implicit preferred conversions,
>>>>>> but IMHO
>>>>>> implicit conversions of integer to double is a no-brainer. Requiring
>>>>>> something
>>>>>> this simple to be explicit is Java/Pascal-like overkill on
>>>>>> explicitness.
>>>>>
>>>>> Completely agree.
>>>>>
>>>>> I call that uncluttered programming. No excessive explicitness should
>>>>> be
>>>>> necessary when what you mean is obvious (under some simple
>>>>> conventions).
>>>>> Leads to clearer code.
>>>>>
>>>>
>>>> Yes, and for the most part uncluttered programming is one of D's
>>>> biggest
>>>> strengths.  Let's not ruin it by complicating sqrt(2).
>>>
>>> What is the compiler to do with sqrt(5_000_000_000) ? It doesn't fit
>>> into
>>> an int, but it fits into a double.
>>
>> Simple, is a 5_000_000_000 long, and longs convert to reals. Also,
>> 5_000_000_000 does not fit, exactly inside a double.
>
> It doesn't?  I thought double could do 53 bits?

Yes. You're right. Sorry, my brain automatically skipped forward to 5_000_000_000 => long => real.

> Although I agree, long should map to real, because obviously not all longs
> fit into a double exactly.
>
> -Steve


More information about the Digitalmars-d mailing list