sqrt(2) must go

[Steven Schveighoffer]

On Thu, 20 Oct 2011 03:55:51 -0400, Don <nospam at nospam.com> wrote:

> On 20.10.2011 05:01, Steven Schveighoffer 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?
>>
>> Although I agree, long should map to real, because obviously not all
>> longs fit into a double exactly.
>>
>> -Steve
>
> But ulong.max does NOT fit into an 80-bit real. And long won't fit into  
> real on anything other than x86, 68K, and Itanium.
>
> I don't think long and ulong should ever implicitly convert to floating  
> point types. Note that you can just do *1.0 or *1.0L if you want to  
> convert them.
>
> Currently long implicitly converts even to float. This seems quite bad,  
> it loses 60% of its bits!!
>
> Suppose we also banned implicit conversions int->float and uint->float  
> (since float only has 24 bits, these are lossy conversions, losing 25%  
> of the bits).
>
> Now that we've disallowed lossy integral conversions, it really seems  
> that we should disallow these ones as well.
>
> If that was all we did, it would also mean that things like short+short  
> wouldn't convert to float either, because C converts everything to int  
> whenever it gets an opportunity. But we could use range checking to  
> restore this (and to allow small longs to fit into doubles: allow  
> conversion to double if it's <= 53 bits, allow conversion to float if <=  
> 24 bits).

Would you disagree though, that if a literal can be accurately represented  
as a real or double, it should be allowed?

-Steve